Static Rate Limiting
Overview
When exposing an API to the public, it is critical to protect it from potential abuse by heavy hitters and malicious users. This ensures that the API remains available and performs optimally for all users. Aperture's rate limiter identifies users in the traffic using labels in the request. Distributed token buckets are maintained for each user, ensuring that each user stays within the assigned limits. The token bucket is configured with a fill rate that determines the maximum request rate in steady state. The bucket's capacity determines the magnitude of momentary surge allowed in request rates.
Configuration
This policy is based on the
Rate Limiting blueprint. It
applies a rate limiter to the ingress
control point on the service
catalog-service.prod.svc.cluster.local
and identifies unique users by
referencing the user_id
header present in the HTTP traffic. Provided by
the Envoy proxy, this header can be located under the label key
http.request.header.user_id
(see Flow Labels
for more information).
Each user is allowed 2
requests every 1s
(1 second) period. A burst
of up to 40
requests is allowed. This means that the user can send up to
40
requests in the first second, and then 2
requests every second
after that. The bucket gets replenished at the rate of 2
requests per
second (the fill rate).
The below values.yaml
file can be generated by following the steps in the
Installation section.
- aperturectl values.yaml
# yaml-language-server: $schema=../../../../../../blueprints/rate-limiting/base/gen/definitions.json
policy:
policy_name: "static-rate-limiting"
rate_limiter:
bucket_capacity: 40
fill_amount: 2
selectors:
- service: "catalog-service.prod.svc.cluster.local"
control_point: "ingress"
agent_group: "default"
parameters:
label_key: "http.request.header.user_id"
interval: 1s
Generated Policy
apiVersion: fluxninja.com/v1alpha1
kind: Policy
metadata:
labels:
fluxninja.com/validate: "true"
name: static-rate-limiting
spec:
circuit:
components:
- flow_control:
rate_limiter:
in_ports:
bucket_capacity:
constant_signal:
value: 40
fill_amount:
constant_signal:
value: 2
parameters:
interval: 1s
label_key: http.request.header.user_id
selectors:
- agent_group: default
control_point: ingress
service: catalog-service.prod.svc.cluster.local
evaluation_interval: 1s
resources:
flow_control:
classifiers: []
Circuit Diagram for this policy.
Installation
Generate a values file specific to the policy. This can be achieved using the command provided below.
aperturectl blueprints values --name=rate-limiting/base --version=v2.8.0 --output-file=values.yaml
Adjust the values to match the application requirements. Use the following command to generate the policy.
aperturectl blueprints generate --name=rate-limiting/base --values-file=values.yaml --output-dir=policy-gen --version=v2.8.0
Apply the policy using the aperturectl
CLI or kubectl
.
- aperturectl
- kubectl
Pass the --kube
flag with aperturectl
to directly apply the generated policy
on a Kubernetes cluster in the namespace where the Aperture Controller is
installed.
aperturectl apply policy --file=policy-gen/policies/rate-limiting.yaml --kube
Apply the policy YAML generated (Kubernetes Custom Resource) using the above
example with kubectl
.
kubectl apply -f policy-gen/configuration/rate-limiting-cr.yaml -n aperture-controller
Policy in Action
When the policy is applied at a service, no more than 2 requests per second period (after an initial burst of 40 requests) are accepted for a user.