run_bee3fc7783a2bd1e

input

{
  "request": "Triage Jira ticket SREIN-1699: Enable WAF on services.addons.mozilla.org",
  "references": [
    "https://mozilla-hub.atlassian.net/browse/SREIN-1699"
  ],
  "sourceContext": {
    "issue": "SREIN-1699"
  }
}

summary

SREIN-1699 is a backlog request from the AMO (addons.mozilla.org) team asking Mozilla Cloud Engineering (SRE-IN/MozCloud) to review and help enable Fastly NGWAF (WAF) on services.addons.mozilla.org, the API domain that serves Firefox client requests. AMO's main domain has had NGWAF enabled since last year; this ticket extends that same protection to the API subdomain. A PR has already been opened by the requester that enables the WAF on the staging environment in logging-only mode. The requester is explicitly asking for a MozCloud review because the underlying Fastly service configuration for AMO predates Mozilla's standardized Fastly setup (it was custom-built by a former engineer, Wei, before Fastly config was generalized org-wide), making it more complex/idiosyncratic than typical services. The requester also mentions having asked colleagues who worked on last year's WAF rollout for AMO's main domain to review, and that a manager (Brett) suggested formally filing this ticket with SRE-IN. There are no comments yet, and the ticket is still sitting in Backlog with no assignee/priority indicated in the pulled data, and no linked runbook or Confluence design doc was referenced in the description to pull additional context from.

findings

• Ticket requests a config review + rollout support, not a full implementation ask
• This mirrors a precedent: AMO's apex domain already has NGWAF enabled, so there is prior art/config to reference
• AMO's Fastly setup is nonstandard/legacy relative to current Mozilla-wide Fastly conventions, increasing review complexity and risk of misconfiguration
• Reviewers with relevant context already identified by the requester (engineers who worked on the prior AMO WAF rollout), which should shorten review time if looped in
• No PR link, staging test plan, or rollout/monitoring criteria (e.g., how long to soak in logging mode before flipping to blocking mode) is included in the ticket body — this should be requested before work begins
• Ticket has zero comments and is unassigned/unscoped in Backlog, indicating it needs initial triage: confirm reviewer assignment, priority, and link the PR

proposed actions

Thanks for filing this. To triage: could you (1) attach/link the staging PR that enables NGWAF logging mode for services.addons.mozilla.org so we can review the Fastly config changes directly, and (2) loop in the engineers who worked on last year's WAF rollout for the AMO apex domain as reviewers, since they'll have the most context on AMO's legacy (pre-standardization) Fastly setup? It would also help to note a proposed soak period for logging mode and the criteria/owner for flipping to blocking mode once validated. Once the PR is linked we'll assign a MozCloud reviewer and move this out of Backlog.

tool calls

[
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "SREIN-1699"
    },
    "result": {
      "key": "SREIN-1699",
      "summary": "Enable WAF on services.addons.mozilla.org",
      "status": "Backlog",
      "description_text": "AMO has had Fastly NGWAF enabled on its main domain since last year. At the time we didn\u2019t do  services.addons.mozilla.org , which serves API requests for Firefox. We\u2019d like to do that now. I created a PR    to do that, enabling it on stage in logging mode, and would like a review from MozCloud as AMO\u2019s fastly configuration is a bit involved (it was made by Wei before fastly was generalized across Mozilla - AMO was an early adopter). recommended I asked    for a review (both of them worked on enabling the WAF for AMO last year), and Brett then suggested I filed this.",
      "comment_count": 0,
      "comments": []
    }
  }
]

log