The Gloo Portal is deployed on Kubernetes using native constructs like pods, services, and custom resource definitions. The Gloo Portal complements and enhances the functionality of Istio or Gloo Edge by adding features like external authentication and rate limiting.
The primary components of Gloo Portal are listed below by resource type.
- Gloo Portal operator - Monitors Custom Resources and modifies Istio/Gloo Edge and Envoy configurations.
- Admin server - Backend for Gloo Portal administrator UI.
- ExtAuth - Extends the underlying gateway to include external authentication sources.
- Rate Limiting - Extends the underlying gateway to allow for rate-limiting of API consumption.
- Redis - Data store for rate limiting
Custom Resource Definitions
apidocs- An APIDoc tells the DevPortal controller how to load an API Specification Document. APIDocs define the operations which are bundled and exposed in API Products.
apiproducts- API Products define a group of API Operations (endpoints) as a version to be published through an Environment. An API Product version entry declares which APIs are bundled together as well as how to route to the backends serving those APIs.
environment- Environments define one or more API Product versions to bundle together and present in the portal and developers. Also defined in an environment are the domain, usage plans, and authentication.
portals- A PortalSpec tells the Gloo Portal Operator to fetch and serve static assets which are used by the Gloo Portal UI. Each portal can publish one or more Environments.
users- A User defines an entity which can authenticate to the Portal App. Users are members of Groups, which determines which ApiDocs they can see.
groups- A Group can be use to define access levels for a set of users.
routes- Routes define how an API Product connects to a service described by an API Doc. There can be multiple routes defined in an API Product.
The admin dashboard is served up by the Admin server service of type ClusterIP on port 8080. You can access the admin dashboard by updating the service to use a NodePort or Load Balancer ServiceType, or by using port-forwarding with kubectl. An example command would be the following:
kubectl port-forward -n gloo-portal svc/gloo-portal-admin-server 8080
Currently the admin dashboard does not have an authentication layer in front of it, so it would be best to restrict namespace access to Gloo Portal or port-forwarding permissions to administrators only.