Navigation :

Portal server

Review how the Gloo portal server backs up data and your setup options to make the backing database more resilient. For more information about the feature, see Portal in the Gloo Gateway docs.

What data gets stored

The portal server stores the following data in the backing database. For an example of how to check the data that gets stored, see Review data in Redis.

API keys that end users can use to authenticate to destinations and routes that are protected by an external auth policy that the external auth server enforces.

How the portal and external auth servers share backing storage

To use Gloo Platform Portal, you must configure both the portal and external auth servers to use the same backing storage. Review the following diagram for more information.

Portal and external auth shared backing database

As the portal admin, you configure the backing storage database for both the external auth and portal servers. For more information, see Backing storage options.
As an end user, you use the developer portal to generate an API key. Then, the Gloo portal server writes this API key to the shared backing storage database, such as Redis.
As an end user, you include the API key in subsequent requests to the API products that you want to access. The Gloo ingress gateway receives your requests and checks the API's route for external auth policies. The Gloo external auth server reads the API key value from the shared backing storage database, such as Redis. If the API key matches a valid value, then the Gloo gateway sends the request to the API product and you get back a successful response.

For steps to try out this process yourself, see Verify that external auth works with API keys in a backing storage database.

Backing storage options

Review the following options for setting up backing storage.

Option	Use case	Benefits	Drawbacks
Default (no backing storage)	Local testing in single clusters	Easy setup, no maintenance required Updatable via Gloo Platform Helm chart	Data is not stored anywhere by default No support for external auth policies until a backing storage is configured (e.g. Kubernetes secrets) Manual creation, error-prone Not scalable, highly available, or recoverable
Built-in local Redis	Proof of concept and staging environments in single clusters	The Redis instance is deployed for you as part of the default Gloo Gateway installation Fast read/write speed as the database is local to the management server Updatable via Gloo Platform Helm chart Redis GUI- and CLI-based tools help you monitor data	Only as highly available as your cluster setup Has the same disaster recovery as your cluster setup Might not meet your organization's compliance requirements
Bring your own Redis	Production-level, multicluster environments	Enhanced high availability and disaster recovery (HA/DR) Service level agreement (SLA) from your provider Meet your organization's compliance requirements Redis GUI- and CLI-based tools help you monitor data	More complicated setup Not covered by Solo support (contact your external Redis provider)

Default (no backing storage)

By default, no backing storage is configured for the portal server. For testing purposes, you can manually create backing storage, such as saving an API key's details in a Kubernetes secret. For example steps, see Require API key external auth for Gloo Platform Portal.

Built-in local Redis

When you install Gloo Platform, a local Redis instance redis is set up in the gloo-mesh-addons namespace of the workload cluster. The rate limiting server automatically reads and writes to this Redis instance. However, you must manually configure the Gloo external auth and Gloo portal servers to read from and write data to this Redis instance.

Using a local Redis instance is not a recommended practice for production. To achieve higher availability, disaster recovery and add other security features, bring your own Redis instance instead.

Include the same local Redis settings for the external auth and portal servers when you install or upgrade Gloo Platform. Review the following table to understand the matching settings. For more information, check the Helm reference.

Ext auth setting	Portal setting	Description
extAuthService.extAuth.apiKeyStorage.name, .enabled	glooPortalServer.apiKeyStorage.redis.enabled	Use Redis as the backing storage for API keys.
extAuthService.extAuth.apiKeyStorage.secretKey	glooPortalServer.apiKeyStorage.secretKey	The string value that you want to use to hash API keys before they are stored in the Redis database.
N/A	glooPortalServer.apiKeyStorage.configPath	The path to the Redis configuration file.
extAuthService.extAuth.apiKeyStorage.config.host	glooPortalServer.apiKeyStorage.redis.address	The host that the Redis instance is available on. When using the built-in local Redis, this value is set to the local `redis` service in the `gloo-mesh-addons` namespace: `redis.gloo-mesh-addons:6379`.
extAuthService.extAuth.apiKeyStorage.config.db	glooPortalServer.apiKeyStorage.redis.db	The Redis database to use. The default value for the portal server is `0`, so the external auth server must set this value, too.

Helm command
Helm values file

helm upgrade --install gloo-agent-addons gloo-platform/gloo-platform \
   --namespace gloo-mesh-addons \
   --create-namespace \
   --version $GLOO_VERSION \
   --set common.cluster=$CLUSTER_NAME \
   --set extAuthService.enabled=true \
   --set rateLimiter.enabled=true \
   --set glooPortalServer.enabled=true \
   --set glooPortalServer.apiKeyStorage.redis.enabled=true \
   --set glooPortalServer.apiKeyStorage.secretKey="ThisIsSecret" \
   --set glooPortalServer.apiKeyStorage.configPath="/etc/redis-client-config/config.yaml" \
   --set glooPortalServer.apiKeyStorage.redis.address="redis.gloo-mesh-addons:6379" \
   --set extAuthService.extAuth.apiKeyStorage.name=redis \
   --set extAuthService.extAuth.apiKeyStorage.enabled=true \
   --set extAuthService.extAuth.apiKeyStorage.config.host="redis.gloo-mesh-addons:6379" \
   --set extAuthService.extAuth.apiKeyStorage.config.db=0 \
   --set extAuthService.extAuth.apiKeyStorage.secretKey="ThisIsSecret"

If you use a Helm values file, make sure that the following settings are enabled.

extAuthService:
  enabled: true
  extAuth:
    apiKeyStorage:
      # Use the local gloo-mesh-addons Redis for backing storage
      name: redis
      enabled: true
      config:
        host: "redis.gloo-mesh-addons:6379"
        # Set to 0 to match the default database for the 'glooPortalServer.apiKeyStorage' configuration
        db: 0
      # Replace with a random string to use to generate hash values for other keys
      secretKey: "ThisIsSecret"
      # Optionally enable authentication for Redis with the username and password in the referenced secret.
      redis:
        auth:
          enabled: true
          secretName: extauth-redis-auth-secret
glooPortalServer:
  enabled: true
  apiKeyStorage:
    # Use the local gloo-mesh-addons Redis for backing storage
    redis:
      enabled: true
      address: redis.gloo-mesh-addons:6379
      # Optionally enable authentication for Redis with the username and password in the referenced secret.
      auth:
        enabled: true
        secretName: portal-redis-auth-secret
    # Path for API key storage config file in the gloo-mesh-addons backing Redis
    configPath: /etc/redis-client-config/config.yaml
    # Replace with a random string to use to generate hash values for other keys
    secretKey: "ThisIsSecret"
rateLimiter:
  enabled: true
# Configuration for the managed north-south (ingress) gateway. Requires a Gloo Gateway license.
northSouthGateways:
- # Install the gateway in the cluster.
  enabled: true

Continue with the Install or Upgrade guides for more instructions to finish your installation or upgrade.

Bring your own Redis

Instead of using the built-in local Redis instance, you can achieve higher availability, disaster recovery, and enhanced control and security by bringing your own Redis cluster. Unlike for the Gloo management server or UI, do not install a local instance of Redis. Instead, create an instance outside your cluster environment, such as Redis Enterprise or a cloud provider service like AWS ElastiCache. Then, you include the settings for your external Redis instance when you install or upgrade your Gloo Helm chart. This way, you can support multicluster use cases to use the same external Redis for the API keys shared by the Gloo external auth and portal servers.

Using a Redis or AWS ElastiCache instance in cluster mode is currently not supported.

When you bring your own Redis cluster, you can also customize the following aspects:

Authentication: To authenticate with your Redis instance, you can configure Gloo Gateway to use a username and password when connecting to Redis. Depending on your Redis provider, you might only need to specify a password to authenticate with Redis. You store these credentials in a Kubernetes secret in the same namespace as the portal server deployment.

Keep in mind that your external Redis database usually must be in the same cloud provider as your Gloo cluster, such as AWS ElastiCache and EC2 instances. Also, you must configure both the Gloo external auth and Gloo portal servers in your cluster to read from and write to the same Redis database. Any settings for your Redis instance, such as the maximum number of retries, are shared between these components.

Create or use an existing Redis cluster, such as AWS ElastiCache or Google Cloud Memorystore.
Make sure that you can connect to your instance from the Gloo management cluster. For example, your cloud provider might require for the cluster and Redis instance to share the same virtual private network (VPC). For more information, consult your cloud provider documentation, such as AWS ElastiCache or Google Cloud Memorystore.
Choose how to authenticate with your Redis cluster. Depending on your Redis provider, you might be required to use a specific authentication method, such as a username and password.

Create a Kubernetes secret to store your Redis auth credentials. You must create separate secrets with the same credentials for the portal and external auth servers.

Portal server
External auth


kubectl create secret generic portal-redis-credentials -n gloo-mesh-addons --from-literal=password=<password> --from-literal=username=<username>


kubectl create secret generic extauth-redis-auth-secret -n gloo-mesh-addons --from-literal=password=<password> --from-literal=username=<username>

Setting	Description
name	The name for the secret. For portal, the name must be `portal-redis-credentials`. For external auth, the name must match what you use to install the external auth server later.
namespace	Create the secret in the same namespace as the server that the secret is for, such as `gloo-mesh-addons`.
password	The password of your Redis credentials.
username	The username of your Redis credentials. If your instance does not have a username, you can leave this field empty such as by entering `''`.

Include the same external Redis settings for the external auth and portal servers when you install or upgrade Gloo Platform. Review the following table to understand the matching settings. For more information, check the Helm reference.

Ext auth setting	Portal setting	Description
extAuthService.extAuth.apiKeyStorage.name, .enabled	glooPortalServer.apiKeyStorage.redis.enabled	Use Redis as the backing storage for API keys.
extAuthService.extAuth.apiKeyStorage.secretKey	glooPortalServer.apiKeyStorage.secretKey	The string value that you want to use to hash API keys before they are stored in the Redis database.
N/A	glooPortalServer.apiKeyStorage.configPath	The path to the Redis configuration file.
extAuthService.extAuth.apiKeyStorage.config.host	glooPortalServer.apiKeyStorage.redis.address	Replace `$REDIS_HOST` with the host and port that the Redis instance is available on. This host might need to be on the same virtual private network as your cluster or need to have a VPN connection. An example Amazon ElastiCache host might look like `redis-cluster.ameaqx.0001.use1.cache.amazonaws.com`. For more information, see the Amazon ElastiCache docs. An example Google Cloud Memorystore host might look like `10.xxx.xx.xx:6379` in the same VPC as your cluster. For more information, see the Google Cloud Memorystore docs.
extAuthService.extAuth.apiKeyStorage.config.db	glooPortalServer.apiKeyStorage.config.db	The Redis database to use. The default value for the portal server is `0`, so the external auth server must set this value, too.
extAuthService.extAuth.apiKeyStorage.redis.auth.enabled	glooPortalServer.apiKeyStorage.redis.auth.enabled	Optionally add this section to authenticate with your Redis cluster by using a username and password.
extAuthService.extAuth.apiKeyStorage.redis.auth.secretName	N/A	Specify the name of the secret that is in the same namespace as the external auth or portal server deployment, such as `gloo-mesh-addons`. For portal, the secret name is automatically set to `portal-redis-credentials`. For external auth, the name must match what you named the secret in the previous step.

Helm command
Helm values file

helm upgrade --install gloo-agent-addons gloo-platform/gloo-platform \
   --namespace gloo-mesh-addons \
   --create-namespace \
   --version $GLOO_VERSION \
   --set common.cluster=$CLUSTER_NAME \
   --set extAuthService.enabled=true \
   --set rateLimiter.enabled=true \
   --set glooPortalServer.enabled=true \
   --set glooPortalServer.apiKeyStorage.redis.enabled=true \
   --set glooPortalServer.apiKeyStorage.secretKey="ThisIsSecret" \
   --set glooPortalServer.apiKeyStorage.configPath="/etc/redis-client-config/config.yaml" \
   --set glooPortalServer.apiKeyStorage.redis.address="$REDIS_HOST" \
   --set glooPortalServer.apiKeyStorage.redis.auth.enabled=true \
   --set extAuthService.extAuth.apiKeyStorage.name=redis \
   --set extAuthService.extAuth.apiKeyStorage.enabled=true \
   --set extAuthService.extAuth.apiKeyStorage.config.host="$REDIS_HOST" \
   --set extAuthService.extAuth.apiKeyStorage.config.db=0 \
   --set extAuthService.extAuth.apiKeyStorage.secretKey="ThisIsSecret" \
   --set extAuthService.extAuth.apiKeyStorage.redis.auth.enabled=true \
   --set extAuthService.extAuth.apiKeyStorage.redis.auth.secretName=extauth-redis-auth-secret

If you use a Helm values file, make sure that the following settings are enabled.

extAuthService
  enabled: true
  extAuth:
    apiKeyStorage:
      # Use an external Redis database for backing storage
      name: redis
      enabled: true
      config:
        # Provide the host to your external Redis database, such as AWS ElastiCache or Google Cloud Memorystore
        host: "$REDIS_HOST"
        # Set to 0 to match the default database for the 'glooPortalServer.apiKeyStorage' configuration
        db: 0
      # Replace with a random string to use to generate hash values for other keys
      secretKey: "ThisIsSecret"
      # Optionally enable authentication for Redis with the username and password in the referenced secret.
      redis:
        auth:
          enabled: true
          secretName: extauth-redis-auth-secret
glooPortalServer:
  enabled: true
  apiKeyStorage:
    # Path for API key storage config file in the gloo-mesh-addons backing Redis
    configPath: /etc/redis-client-config/config.yaml
    # Replace with a random string to use to generate hash values for other keys
    secretKey: "ThisIsSecret"
    # Use an external Redis database for backing storage
    redis:
      enabled: true
      # Provide the host to your external Redis database, such as AWS ElastiCache or Google Cloud Memorystore
      address: "$REDIS_HOST"
      # Optionally enable authentication for Redis with the username and password in the referenced secret.
      auth:
        enabled: true
rateLimiter
  enabled: true
# Configuration for the managed north-south (ingress) gateway. Requires a Gloo Gateway license.
northSouthGateways:
- # Install the gateway in the cluster.
  enabled: true

Continue with the Install or Upgrade guides for more instructions to finish your installation or upgrade.
Optional: Verify that the external auth and portal server are configured with your external Redis database details.
1. Verify that the secrets are created.
```
kubectl get secrets -n gloo-mesh-addons
```
  Example output:
```
NAME                                      TYPE                    DATA   AGE
ext-auth-service-api-key-secret-key       Opaque                  1      47s
ext-auth-service-api-key-storage          Opaque                  1      47s
ext-auth-service-signing-key              Opaque                  1      47s
portal-storage-config                     Opaque                  1      47s
```
2. Log in to the portal and external auth server pods, and verify that the host information is stored along the config path that you set.
  - Portal server
  - External auth server
  1. Log in to the portal server pod.
    kubectl exec -it -n gloo-mesh-addons pods/$(kubectl get pod -l app=gloo-mesh-portal-server -A -o jsonpath='{.items[0].metadata.name}') -- /bin/sh
  2. Check the file contents at the config path that you set, such as /etc/redis-client-config/config.yaml.
    cat /etc/redis-client-config/config.yaml
  3. Confirm that the value matches the host address for your external Redis database ($REDIS_HOST).
  4. To log out of the pod, enter exit.
  1. Log in to the external auth server pod.
    kubectl exec -it -n gloo-mesh-addons pods/$(kubectl get pod -l app=ext-auth-service -A -o jsonpath='{.items[0].metadata.name}') -- /bin/sh
  2. Check the file contents at the config path that you set, such as /etc/apikeys/storage-config.yaml.
    cat /etc/apikeys/storage-config.yaml
  3. Confirm that the value matches the host address for your external Redis database ($REDIS_HOST).
  4. To log out of the pod, enter exit.
Optional: Verify that API keys are stored in your external Redis database.