Control objective
Rate and quota controls limit resource use, abuse, accidental loops, and unfair consumption. Identity awareness lets the system distinguish subjects, clients, tenants, resources, actions, and request cost instead of relying only on source addresses.
Keys and budgets
Choose keys that attackers cannot select freely. Separate burst rate, sustained rate, concurrency, daily quota, and expensive-operation budget. Apply global safety limits in addition to per-identity fairness. Do not merge unrelated tenants behind one network address.
Response and evidence
Return a defined limit result, protect limit-state integrity, and record subject, client, resource, action, policy, cost, current budget, and retry guidance without exposing other tenants. Test distributed consistency and failure behavior.
Failure and residual risk
Rate limits are not authorization. A slow attacker can remain under the limit. Identity rotation can evade per-subject limits. Shared keys can let one user deny service to others. Central state can become a latency or availability dependency.
Pomerium boundary
Pomerium can establish identity and route context for protected requests. Application-specific cost, object quotas, and final rate enforcement can require upstream controls. Operators must not treat a Pomerium allow as proof that an application budget remains.
Evaluation checklist
- Which subject, client, tenant, resource, action, and cost define the budget?
- Are burst, sustained, concurrency, quota, and global safety limits distinct?
- Can identity rotation or a shared address evade or amplify the limit?
- What happens when distributed limit state is stale or unavailable?
- Does authorization remain separate from rate and quota decisions?
