On this page
About
Learn about the benefits, feature status, and FAQs of Gloo Portal.
Secure, bundle, and share your APIs in a developer portal that you can customize with Gloo Portal for Gloo Mesh Gateway.
Gloo Portal is available as an alpha feature in Gloo Mesh Gateway version 2.3. Alpha features are likely to change, are not fully tested, and are not supported for production. For more information, see Gloo feature maturity.
In other sections of the docs, you learned how Gloo Mesh Gateway lets you set up ingress gateways and networking policies to control traffic to the workloads in your cluster environment. Now, you can use those same Gloo resources to set up a developer portal so that your apps’ end users can securely access your API services.
Overview
Check out the following video for an overview of Gloo Portal.
Challenges of API portals
Some of the key challenges of API management that Portal helps address are as follows:
- Self-service API registration: Any developer portal needs a way to discover the APIs to include. Ideally, the portal can automatically discover APIs in a way that does not disrupt your current app deployment and DevOps processes. Your portal admins should not have to help onboard each API.
- Flexible API products: Especially in microservice architectures, you might have hundreds of APIs. Exposing all of these APIs together might not be helpful for your users. Instead, you need a way to bundle APIs into different products. An API might be part of several different products.
- Usage plans for API products: Usage plans control how your API products can be used, such as the number of times an API can be called within a certain timeframe. Often, your usage plans are tied to billing concerns, such as different prices for different plans.
- Flexible portal deployments: Just as you have different API products and usage plans, you might need different developer portals. For example, you might have separate internal and external portals, regional portals, or partner vs. end-user portals.
- Audience management: As a portal administrator, you have several audiences. First, you might work with internal teams of developers and operators who help set up the developer portal, your “backend” audiences. Second, you might have several different sorts of end-users, such as internal teams that consume your APIs, external partners, or general consumers. These end-users might be thought of as “frontend” audiences. Your portal solution must be able to secure access for both backend and frontend audiences appropriately.
- Portal web UI and branding: Your end-users need a way to find, review, and use your API products. As such, you must be able to customize the developer portal’s web UI so that your company style, logos, and other branding elements are consistent.
- API documentation: API documentation is at the heart of how end-users interact with your APIs. The best API documentation is not only automatically generated from your apps, but also appears seamlessly in the branded web UI of your developer portal.
- Observability: With many APIs comes the challenge of observability. You need a way to quickly find and check the health of all the resources that support your developer portals. This way, you can better manage and troubleshoot any issues that occur.
Benefits
Review the following table to learn more about Gloo’s unique approach to solving the key challenges of API management.
| Feature | Gloo resources | Benefit |
|---|---|---|
| Self-service API registration | Kubernetes labels on deployments, ApiDocs, RouteTables | Your developers continue to deploy their apps in Kubernetes as they normally do. They can choose to label their services so that Gloo automatically detects and creates an ApiDoc for their service. Or, if they do not want to change their app configuration, they can manually create an ApiDoc. Similarly, the team can set up the route tables either to automatically include new services as routes via labels or by manually adding the routes. This flexibility lets your team take the best approach for your internal DevOps processes. For more information, see Create your APIs. |
| Flexible API products | RouteTables | By separating the API product from the apps, your developers do not necessarily have to know or select which products their apps belong to. Instead, the product owner or portal admin can decide to bundle several apps into one or many API products. By using a Gloo route table, you can automatically add apps via Kubernetes labels or specify them at more fine-grained levels. You also get more advanced networking control, such as matching, redirect, rewrite, direct response, and forwarding actions. This way, you can set up complex rules for how your API products behave under different circumstances. For more information, see Bundle your APIs into API products. |
| Usage plans for your API products | ExtAuthPolicies, RateLimitPolicies, RouteTable, Portal | Instead of creating separate usage plan resources, Gloo takes a more flexible approach. You create the same external auth and rate limiting policies that you do to secure your apps in general. Then, you apply these policies to the routes that are in the route table for your API products. You name these usage plans in the Portal resource. This way, you can reuse policies for many plans and portals as needed. Plus, each portal can set its own names and descriptions for the usage plans. This way, even if you reuse the same policies across many usage plans, the usage plans can have their own unique names that fit your portal’s use case. For more information, see Prepare usage plans. |
| Flexible portal deployments | Portal | You can use the Portal custom resource to create a developer portal that you can share with your users. Each developer portal can be set up to serve only the APIs and usage plans that you want to expose to your users. For more information, see Create a developer portal. |
| Audience management | Portal groups | Portal provides multiple layers of authentication to manage your audiences. You might have usage plans that include a free tier that allows unauthorized access to a limited number of APIs. In addition, you can secure the APIs in the developer portal that your users consume by marking APIs as private, and setting up external authentication and authorization for your users. For more information, see Secure the developer portal. |
| API documentation | ApiDocs, sample React app | The ApiDoc resource has the OpenAPI spec for your apps. This spec can be used to automatically render your API documentation. You can reuse and customize the sample React app that Gloo provides to display your API documentation in the developer portal. The docs automatically appear when you add new APIs to your portal environment. |
| Portal web UI and branding | Sample React app, Portal metadata | You control how your developer portal is displayed to users. Gloo provides a sample React app that you can use as a starting point. Additionally, you can configure metadata in the Portal CR about your API products that shows up in the developer portal. This way, you don’t have to update the developer portal app as often after the initial setup. For more information, see Build a developer portal frontend. |
| API usage analytics | Gloo UI, OTel telemetry pipeline, Clickhouse log storage | Review usage information about the API products that are exposed in your portal. You can review information such as total requests, total users, total services, and error rates. For more information, see Review API usage analytics. |
| Observability | Gloo UI, statuses, logs | Because Portal is implemented as any other Gloo resource, you get all of the Gloo Platform observability benefits. For example, you can review the backing Gloo portal, routing, and policy for each developer portal in the Gloo UI. Resource statuses are shown globally, for each individual resource, and for related resources. You can also check the management server, agent, and portal server logs for even more detail. For more information, see Monitor health. |
Frequent asked questions (FAQs)
Review the following FAQs to understand more about the Gloo Portal product.
What are the Portal components and who configures them?
See the Setup overview.
How many portals can I have?
You can have as many developer portals as you want. You create a separate Portal custom resource for each portal, but you might choose to reuse different combinations of ApiDocs and RouteTables.
Example uses cases for multiple portals:
- Internal vs. external developer portals
- Domain boundaries for customers, partners, and end-users
- Regional boundaries
What product is this Gloo Portal compatible with?
| Product | Gateway API | Compatible portal |
|---|---|---|
| Gloo Gateway | Kubernetes Gateway API | Gloo Gateway’s Portal, which shares an architecture with Gloo Mesh Gateway Portal, but has several important differences. |
| Gloo Gateway | Classic Edge API | Classic Gloo Portal, which is maintained as a separate product and doc set. |
| Gloo Mesh Gateway | Istio Gateway API | Gloo Mesh Gateway’s Portal, which shares an architecture with Gloo Gateway Portal, but has several important differences. If you deploy Portal in a Mesh-only environment, the portal would be internal-only. To expose your portal to external end-users, you must also have a Gloo Mesh Gateway license. |
How is this Gloo Portal different from previous Portal offerings from Solo?
This Gloo Portal for Gloo Mesh Gateway is based on a completely refreshed API design from classic Gloo Portal. As such, these Portals are different products with different custom resources, capabilities, and deployment patterns.
The Gloo Portal offerings for both Gloo Mesh Gateway and Gloo Gateway with the Kubernetes Gateway API share a backend codebase and similar architecture. However, because Gloo Gateway uses Kubernetes-native routing resources such as the Kubernetes Gateway API and HTTPRoute, the implementation details differ. In particular, the following areas are different across these portals for different Gloo products.
| Portal area | Portal for Gloo Gateway | Portal for Gloo Mesh |
|---|---|---|
| Gateway that the portal is exposed on | Kubernetes Gateway API | Gloo VirtualGateway that selects an Istio gateway |
| Routing configuration to the portal and APIs | Kubernetes HTTPRoute and RouteOptions | Gloo RouteTables |
| API products | Gloo ApiDocs and ApiProducts | Gloo ApiDocs and RouteTable portal metadata |
Known issues
Gloo Portal for Gloo Mesh Gateway has the following known issues:
- The portal can become unavailable when misconfigured, such as if a usage plan name does not match the usage plan names in the rate limit server config.
- Routes that are exposed in a portal do not support regular expression path rewrites.
- When you upgrade or install the portal server, the portal does not regenerate ApiDocs for APIs that are marked with service annotations for automatic discovery. You can edit the service to retrigger discovery and generation of the ApiDocs.