Per User Rate LimitingSecurity
If your site is attacked by a malicious user are you prepared?
If you notice users who are abusing their limitless permissions and overwhelming the
httpbin endpoint, you can ensure fairness and protect your site from vulnerabilities by enabling rate limiting based off the incoming client IP address. We do this with the
remote_address field that Envoy configures on each request.
Install Ambassador Pro
Ambassador Pro is a commercial version of Ambassador that includes integrated Single Sign-On, powerful rate limiting, custom filters, and more. Ambassador Pro also uses a certified version of Ambassador OSS that undergoes additional testing and validation.
Clone the Ambassador Pro configuration repository
Ambassador Pro consists of a series of modules that communicate with Ambassador. The core Pro module is typically deployed as a sidecar to Ambassador. This means it is an additional process that runs on the same pod as Ambassador. Ambassador communicates with the Pro sidecar locally. Pro thus scales in parallel with Ambassador. Ambassador Pro also relies on a Redis instance for its rate limit service and several Custom Resource Definitions (CRDs) for configuration.
For this installation, we'll start with a standard set of Ambassador Pro configuration files.
git clone https://github.com/datawire/pro-ref-arch
env.sh, and add your specific license key to the
env.shfile. If you don’t have a license key, you can request a free 14-day trial key now.
Note: Ambassador Pro will not start without a valid license key.
Deploy Ambassador Pro
If you're on GKE, first, create the following
kubectl create clusterrolebinding my-cluster-admin-binding \ --clusterrole=cluster-admin \ --user=$(gcloud info --format="value(config.account)")
Then, deploy Ambassador Pro:
makecommand will use
kubectlto deploy Ambassador Pro and a basic test configuration to the cluster.
Verify that Ambassador Pro is running:
kubectl get pods | grep ambassador ambassador-79494c799f-vj2dv 2/2 Running 0 1h ambassador-pro-redis-dff565f78-88bl2 1/1 Running 0 1h
Note: If you are not deploying in a cloud environment that supports the
LoadBalancertype, you will need to change the
ambassador/ambassador-service.yamlto a different service type (e.g.,
By default, Ambassador Pro uses ports 8081 and 8082 for rate-limiting and filtering, respectively. If for whatever reason those assignments are problematic (perhaps you set service_port to one of those), you can set adjust these by setting environment variables:
GRPC_PORT: Which port to serve the RateLimitService on;
APRO_AUTH_PORT: Which port to serve the filtering AuthService on;
Configure the label in the
pro-ref-arch, observe the
ambassador/04-httpbin.yamlwe deployed earlier. You will see a
labelapplied that labels requests to
/httpbin/with the requests
remote_address. Ambassador Pro's rate limiting service will use this label to identify the client IP of the request.
--- apiVersion: ambassador/v1 kind: Mapping name: httpbin_mapping prefix: /httpbin/ service: httpbin.org:80 host_rewrite: httpbin.org labels: ambassador: - request_label_group: - remote_address
kubectl apply -f ratelimit/rl-per-user.yaml
This will tell Ambassador Pro's rate limiting service to limit the number of requests from each user to 20 requests per minute. This will stop our greedy users from issuing too many requests while not impacting the performance of our more considerate users.
Test The rate limit
We provide a simple way to test that this rate limit is working. By running the
ratelimit-test.shscript in "local-user" mode you will see that your local machine is issuing a lot of request to the system and Ambassador is responding with a 429 after 20 requests.
Now, from another terminal, run the
ratelimit-test.shscript in "remote-user" mode to verify that only your local machine is being rate limited. This will issue a
kubectl execcommand to issue curl requests from Ambassador running inside your cluster. You will see these requests are allowed through even though your local machine is locked out.