Navigation :

Rate limiting server

Review how the Gloo rate limiting server backs up data and your setup options to make the backing database more resilient. For more information about the feature, see Rate limit.

What data gets stored

The rate limiter stores information for limiting requests in the backing database, including the following information. For an example of how to check the data that gets stored, see Review data in Redis.

The generated unique key for the request
The associated count against the rate limit

The configuration data of the Gloo custom resources are stored by the management server in its backing database.

Backing storage options

Review the following options for setting up backing storage.

Option	Use case	Benefits	Drawbacks
Default: 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 Platform 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 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.

The default setup is equivalent to setting the rateLimiter.redis.enabled Helm value to true.

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.

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. You can choose between installing the Redis cluster within your Gloo workload cluster to run it alongside the rate limiter server, or to use a Redis cluster that is hosted outside the management cluster, such as by using a cloud provider service like AWS ElastiCache.

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

Authentication: To authenticate with your Redis instance, you can configure Gloo Platform 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 on the management cluster.
TLS certificates: For enhanced security, you can use TLS certificates to authenticate with your Redis cluster. Note that your Redis instance must be configured to accept TLS connections. You store the certificate that you want to use in a Kubernetes secret on the management cluster.
Connection: You can optionally set connection parameters, such as the maximum number of active connections, retries, or number of idle connections.
Database: You can optionally specify the database instance within your Redis cluster that you want to connect to.

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 TLS certificates or a username and password.

Create a Kubernetes secret to store your Redis authentication credentials. If you apply a YAML configuration file, make sure to encode the values in base64.

Username and password: If your Redis auth doesn't have an explicit username, specify default. For the password, specify your auth string.

kubectl
YAML file

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

kubectl apply -f- <<EOF
apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: redis-secrets
  namespace: gloo-mesh-addons
data:
  #If Redis doesn't have an explicit username, specify ‘default’.
  username: "<username>"
  password: "<password>"
EOF

TLS certificates:

kubectl apply -f- <<EOF
apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: redis-certs-keys
  namespace: gloo-mesh-addons
data:
  redis.crt: "<TLS_certificate>"
EOF

Follow the Upgrade guide to get your Gloo Platform Helm installation configuration file.

In your Helm values file, add the following information. For more information, see the Helm reference docs.

Helm setting	Description
`extAuthService.enabled`	Enable this value to deploy the external auth server alongside the rate limiter server. For more backing database options, see External auth server If you do not include this value, any existing external auth service is removed.
`rateLimiter.enabled`	Enable this value to deploy the rate limiter server.
`rateLimiter.redis.enabled`	Set this option to `false` to disable the built-in local Redis deployment.
`rateLimiter.redis.hostname`	Replace `$REDIS_HOST` with the host 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` in the same VPC as your cluster. Note: If you use an IP address, do not include the port `6379`, which is appended for you. For more information, see the Google Cloud Memorystore docs.
`rateLimiter.redis.auth.enabled`	Add this section if you want to authenticate with your Redis cluster by using a username and password. For the password, specify your auth string. To authenticate by using TLS certificates, remove this section and configure `redis.certs` instead.
`rateLimiter.redis.certs.enabled`	Add this section if you want to authenticate with your Redis cluster by using TLS certificates. To authenticate by using a username and password, remove this section and configure `redis.auth` instead.
`rateLimiter.redis.service.socket`	If you enable authentication via TLS certificates, set this value to `tls`.

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 rateLimiter.redis.enabled=false \
   --set rateLimiter.redis.hostname="$REDIS_HOST" \
   --set rateLimiter.redis.auth.enabled=true \
   --set rateLimiter.redis.certs.enabled=true \
   --set rateLimiter.redis.service.socket=tls

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

# Enable the external auth server.
extAuthService:
  enabled: true
# Enable the rate limiter server.
rateLimiter:
  enabled: true
  redis:
    # Disable the default local Redis instance.
    enabled: false
    # Provide the host to your external Redis database, such as AWS ElastiCache or Google Cloud Memorystore.
    hostname: "$REDIS_HOST"
    # Optionally set to true if your Redis instance runs in clustered mode.
    clustered: false
    # Optionally enable authentication for Redis with the username and password in the referenced secret.
    # The 'secretName', 'passwordKey', and 'usernameKey' are set to the default values,
    # which you must update if you changed these in your secret.
    auth:
      enabled: true
      secretName: redis-secrets
      # The name of the data fields in your secret.
      passwordKey: password
      usernameKey: username
   # Optionally enable TLS connections to the Redis instance with the CA cert that you provide.
   # The 'mountPoint', 'caCert', 'signingKey', and 'secretName' are set to the default values, 
   # which you must update if you changed these in your secret.
   certs:
     enabled: true
     mountPoint: "/etc/tls"
     caCert: "redis.crt"
     signingKey: "redis.key"
     secretName: "redis-certs-keys"
    # Optionally configure the Redis service to use a TLS connection with the TLS certs that you provide.
    service:
      socket: tls

Continue with the Upgrade guide to reinstall the Gloo Platform rate limiter add-on with your own Redis instance.
Optional: Verify that the rate limiter server is configured with your external Redis database details.
1. Verify that the secrets are created.
```
kubectl get secrets -n gloo-mesh-addons
```
2. Apply a basic rate limit policy and send a test request that gets rate limited.
3. Review the rate limiting data in Redis.