External auth server

Review how the Gloo external authentication server backs up data and your setup options to make the backing database more resilient. For more information about the feature, see External authentication and authorization.

Planning to use the external auth server with Gloo Platform Portal? The details for the backing storage database must match for both components. For more information, see Portal server in the Gloo Gateway docs.

What data gets stored

Review data in Redis

To review the data, you can connect to the Redis instance. The following examples use the default local Redis instance (redis deployment) that is installed for you in the gloo-mesh-addons namespace. If you bring your own Redis, you must use those connection values.

You can use the Redis CLI built into your deployment to review the data in your database.

  1. From your terminal, log in to the Redis pod and open a Redis CLI shell.
    kubectl exec -n gloo-mesh-addons deploy/redis -it -- redis-cli
    
  2. Run Redis CLI commands, such as monitor. For more information, see the Redis docs.
    monitor
    OK
    1681223733.198361 [0 10.xxx.x.x:xxxxx] "zrange" "relation#clusters#list" "0" "-1"
    

RedisInsights is a desktop application that you can install for GUI- and CLI-based interactions. For more information, see the Redis docs.

  1. Download RedisInsights.
  2. Enable port forwarding on the Redis deployment.
    kubectl port-forward -n gloo-mesh-addons deploy/redis 6379
    
  3. Launch the RedisInsights app.
  4. Click + Add Redis Database and enter in your localhost and port details, which by default are 127.0.0.1:6379.
  5. Click the database that you just added.
  6. Use the GUI or CLI to explore the data. For example, you can click the Browser tab (the key icon) and toggle the Key view to explore all of the keys in the database instance, as shown in the following screenshot.

RedisInsights view of all keys in the 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
  • Complete control of where data is stored
  • Fast read/write speed as the database is local to the management server
  • Updatable via Gloo Platform Helm chart
  • Data is not stored anywhere by default
  • 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 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 external auth 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.

Otherwise, set up one of the backing storage options.

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 server 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.

  1. 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 settings. For more information, check the Helm reference.

    Ext auth setting Description
    extAuthService.extAuth.apiKeyStorage.name Use Redis as the backing storage for API keys.
    extAuthService.extAuth.apiKeyStorage.secretKey Replace with a random string to use to generate hash values for other keys
    extAuthService.extAuth.apiKeyStorage.config.connection.host The host that the Redis instance is available on, set to the local redis service in the gloo-mesh-addons namespace: redis.gloo-mesh-addons:6379.
    extAuthService.extAuth.apiKeyStorage.config.connection.db The Redis database to use. The default value is 0.
    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 extAuthService.extAuth.apiKeyStorage.name=redis \
       --set extAuthService.extAuth.apiKeyStorage.config.connection.host="redis.gloo-mesh-addons:6379" \
       --set extAuthService.extAuth.apiKeyStorage.config.connection.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
          config:
            connection:
              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"
    
  2. 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. This external Redis cluster is hosted outside your cluster, such as by using a cloud provider service like AWS ElastiCache. 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.

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.

  1. Create or use an existing Redis cluster, such as AWS ElastiCache or Google Cloud Memorystore.

  2. 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.

  3. Include the external Redis settings for the external auth server 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 Description
    extAuthService.extAuth.apiKeyStorage.name Use Redis as the backing storage for API keys.
    extAuthService.extAuth.apiKeyStorage.secretKey Replace with a random string to use to generate hash values for other keys
    extAuthService.extAuth.apiKeyStorage.config.connection.host 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.connection.db The Redis database to use. The default value is 0.
    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 extAuthService.extAuth.apiKeyStorage.config.connection.host="$REDIS_HOST" \
       --set extAuthService.extAuth.apiKeyStorage.config.connection.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 an external Redis database for backing storage
          name: redis
          config:
            connection:
              # 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"
    
  4. Continue with the Install or Upgrade guides for more instructions to finish your installation or upgrade.

  5. Optional: Verify that the external auth server is 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
      
    2. Log in to the external auth server pod, and verify that the host information is stored along the config path that you set.

      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.