run_7c8bb9897c325b56

input

{
  "request": "Triage Jira ticket SREIN-1612: Org policy: disable GKE cluster creation in the webservices folder (with project allow-list)",
  "references": [
    "https://mozilla-hub.atlassian.net/browse/SREIN-1612"
  ],
  "sourceContext": {
    "issue": "SREIN-1612"
  }
}

summary

SREIN-1612 is a Backlog-status engineering task to add an org policy (via Terraform in global-platform-admin/org/tf/policies.tf) that disables GKE cluster creation in the "webservices" GCP folder (folders/154881367248) by default, with a per-project allow-list override. The ticket is well-scoped with a concrete Terraform example, design alternatives, and explicit acceptance criteria, but has several open decisions that block implementation: (1) whether to use the broad gcp.restrictServiceUsage constraint (disables the whole container.googleapis.com API) vs. a narrower custom org policy constraint scoped to Cluster CREATE only, (2) confirmation of the allow-list mechanism/granularity, (3) confirmation of the actual allow-listed projects with the webservices/websre teams, and (4) a broader follow-up audit of other GCP APIs to lock down. The only existing comment is an automated "Reduced Support for CloudEng work week" notice (through July 24, 2026) with no substantive triage from a human yet, and no urgency/priority has been asserted. No linked Confluence runbook/design doc was found in the ticket description to pull additional context from.

findings

• none

proposed actions

tool calls

[
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "SREIN-1612"
    },
    "result": {
      "key": "SREIN-1612",
      "summary": "Org policy: disable GKE cluster creation in the webservices folder (with project allow-list)",
      "status": "Backlog",
      "description_text": "Goal Prevent new GKE cluster creation in the  webservices  GCP folder by default, while allowing an explicit allow-list of projects to keep using GKE. Implemented via org policy in  org/tf/policies.tf  in the  global-platform-admin  repo. Org:   organizations/442341870013 Target folder:   webservices  =  folders/154881367248 Approach Use the managed  gcp.restrictServiceUsage  org policy constraint to deny the GKE API ( container.googleapis.com ) at the  webservices  folder, and override it per-project for allow-listed projects. This follows the existing folder-enforce + per-project-exemption patterns already in  policies.tf  (SSH firewall rules, workload identity pool providers, automatic IAM grants). Barebones example # Disable use of the GKE (container) API in the webservices folder to prevent\n# new GKE cluster creation. Allow-listed projects override this below.\nlocals {\n  webservices_folder_id = \"154881367248\"\n\n  # Projects permitted to use the GKE API within the webservices folder.\n  gke_allowed_projects = [\n    # \"moz-fx-example-prod-1234\",\n  ]\n}\n\nresource \"google_org_policy_policy\" \"restrict_gke_api_webservices\" {\n  name   = \"folders/${local.webservices_folder_id}/policies/gcp.restrictServiceUsage\"\n  parent = \"folders/${local.webservices_folder_id}\"\n\n  spec {\n    rules {\n      values {\n        denied_values = [\"container.googleapis.com\"]\n      }\n    }\n  }\n}\n\n# Per-project exemptions: re-allow the GKE API for allow-listed projects.\nresource \"google_org_policy_policy\" \"allow_gke_api_for_project\" {\n  for_each = toset(local.gke_allowed_projects)\n\n  name   = \"projects/${each.value}/policies/gcp.restrictServiceUsage\"\n  parent = \"projects/${each.value}\"\n\n  spec {\n    rules {\n      allow_all = \"TRUE\"\n    }\n  }\n} Design notes / decisions gcp.restrictServiceUsage  (chosen) disables the whole  container.googleapis.com  API in the folder \u2014 broader than just cluster creation, and lines up with the \"disable APIs / audit which else to disable\" goal below. Alternative (narrower):  a  google_org_policy_custom_constraint  on  container.googleapis.com/Cluster  with  method_types = [\"CREATE\"]  +  action_type = \"DENY\" , exempted per-project via a policy with  enforce = \"FALSE\" . Blocks  cluster creation  specifically but leaves the API usable. Decide which scope we actually want. Allow-list mechanism:  per-project override with  allow_all = \"TRUE\"  stops the project inheriting the folder deny. Confirm this is the desired granularity (vs. only re-allowing  container.googleapis.com ). Rollout:  stage with a  dry_run_spec  first (as done for the GCS public-label constraint in  policies.tf ) to surface any project in  webservices  already using GKE before we enforce, so we don't break existing clusters. Confirm the final allow-list of projects with the webservices/websre teams before enforcing. Follow-up: audit other APIs As part of this work, audit which other GCP APIs should be denied via  gcp.restrictServiceUsage  (org-wide or per-folder) \u2014 i.e. services not used/wanted in the webservices folder (or more broadly) that we can lock down to reduce attack surface and Wiz findings. Produce a shortlist of candidate APIs and where to scope each, and fold the agreed ones into the same policy. Acceptance criteria [ ] Decision recorded:  gcp.restrictServiceUsage  vs. custom Cluster-CREATE constraint. [ ] Policy added to  org/tf/policies.tf , dry-run validated, then enforced on  webservices . [ ] Allow-list projects confirmed and exempted; verified they can still create clusters. [ ] Verified a non-allow-listed project in  webservices  is denied GKE cluster creation. [ ] Audit of other candidate APIs to disable completed and documented.",
      "comment_count": 1,
      "comments": [
        {
          "author": "Automation for Jira",
          "body": "Reduced Support for CloudEng work week: Expect delays for customer support requests. Non-urgent requests may get pushed off until after July 24th, 2026. If this is an incident, please follow the Incident Process.  https://mozilla-hub.atlassian.net/wiki/spaces/MIR/overview?homepageId=20512772 If this is a security incident, please follow the Security Incident Response process.  https://mozilla-hub.atlassian.net/wiki/spaces/SECURITY/pages/27165574/Security+Incident+Response If your request can't wait until after July 24th, please let us know when you need it by and why in a comment in this Jira issue."
        }
      ]
    }
  }
]

log