{
"request": "Triage Jira ticket MZCLD-3842: Add Cloud Armor rate-based bans to the ArgoCD external backends as an interim mitigation",
"references": [
"https://mozilla-hub.atlassian.net/browse/MZCLD-3842"
],
"sourceContext": {
"issue": "MZCLD-3842"
}
}MZCLD-3842 is a well-specified, backlog interim mitigation ticket to add a Cloud Armor rate-based ban policy to the ArgoCD external `server` backend across all three realms (sandbox, dataservices, webservices), as defense-in-depth ahead of the (gated/spiked) Fastly work in MZCLD-3841. The ticket already contains concrete traffic baselines, sequencing guidance, and explicit constraints (don't touch internal gateway backends, use rate-based IP ban, consider preview mode, ensure diagnosability). There are no comments yet and status is still Backlog, so this needs prioritization/assignment and a few implementation details confirmed before work starts.
[
{
"capability": "jira.issue.read",
"args": {
"key": "MZCLD-3842"
},
"result": {
"key": "MZCLD-3842",
"summary": "Add Cloud Armor rate-based bans to the ArgoCD external backends as an interim mitigation",
"status": "Backlog",
"description_text": "Why this is worth doing on its own The Fastly work ( MZCLD-3841 ) is gated on a spike and will take a while. This closes the specific gap from the stale-session incident in days, and it does not become wasted work if Fastly lands later: a rate limit at the load balancer is still useful defense in depth behind an edge. Two things make it cheap right now: GCPBackendPolicy already exposes a securityPolicy field for external services ( argo/k8s/argocd-bootstrap/templates/backend-policies.yaml ), and the values schema already carries it per service. The /api/webhook service uses it today for argocd-webhook-policy , so the wiring is proven; the server service simply has no policy attached. Nothing fronts the load balancers, so Cloud Armor still sees real client IPs . Per-IP rate limiting works correctly today in a way it will not once Fastly is in the path. This is the window in which the simple fix is also the effective one. Work Add a Cloud Armor security policy with a rate-based ban rule and attach it to the external server backend on all three realms ( sandbox , webservices , dataservices ). Define the policy in argo/tf alongside the existing argocd-webhook-policy and the per-realm internal policies, following those conventions. Use a rate-based ban keyed on client IP: a request threshold over an interval, then a ban for a fixed duration. Pick numbers from observed traffic rather than intuition. For scale, the whole webservices realm runs a median of roughly 1.7 req/s with a p90 near 31 req/s, so a single client sustaining hundreds of req/s is unambiguous. Leave real headroom above a busy legitimate session, which opens several concurrent streams. Do not rate limit the internal gateway backends; those already have subnet-restricted policies and different traffic characteristics. Consider starting in preview mode if Cloud Armor supports it for the chosen rule shape, so we can see what would have been banned before enforcing. Make sure a ban produces a diagnosable signal. A user who trips this should be able to find out why without guessing, and a responder should be able to see bans happening. Note the throttled response is what the browser sees, so pick a status code the UI handles sanely. Notes Sequence: land in sandbox first per the Admin Guide's rule, confirm the UI and CLI are unaffected, then dataservices and webservices . The underlying trigger was an ArgoCD UI session whose IAP auth had gone stale and which then retried without backoff. This ticket damps the blast radius; the client-side behaviour is worth reporting upstream separately. If the spike ( MZCLD-3840 ) concludes Fastly cannot front IAP, this becomes the primary control rather than the interim one, and the thresholds deserve a second look in that light.",
"comment_count": 0,
"comments": []
}
}
]{
"model": "claude-sonnet-5",
"input_tokens": 4005,
"output_tokens": 2121,
"estimated_cost_usd": 0.04383
}[]