agentplat▸control runs deployments agents metering + agent
← runs

run_f9816e734013bdfc

AWAITING_APPROVAL retrigger →
jira-triage v1 · jira-triage-k8s · owner ingest:jira-new-ticket (api) · via jira-new-ticket · cloud-engineering

input

{
  "request": "Triage Jira ticket MZCLD-3783: Add gh_access_mozilla to every GitHub orgs allowed SAML groups",
  "references": [
    "https://mozilla-hub.atlassian.net/browse/MZCLD-3783"
  ],
  "sourceContext": {
    "issue": "MZCLD-3783"
  }
}

summary

MZCLD-3783 requests adding the `gh_access_mozilla` SAML/SSO group to the allowed-groups list for every GitHub organization under Mozilla's umbrella, so that any Mozilla staff member in that group can authenticate into any GitHub org via SAML SSO without first needing to be provisioned into the org-specific `people.m.o` (person-and-groups) mapping. The ticket is currently in Backlog with no description of scope, acceptance criteria, org inventory, or security review, and has zero comments. No runbook or design doc is linked in the ticket, so no Confluence context was available to pull.

findings

  • none

proposed actions

jira.comment.postrisk low - this is a clarifying/triage comment only, no ticket state change; however the underlying request itself is a security-sensitive access-control change that should not be implemented without explicit sign-off, which this comment aims to surface.
MZCLD-3783
Thanks for filing this. Before moving this out of Backlog, could we clarify a few things:

1. **Scope**: Can we get an explicit list of the GitHub orgs this should apply to (or confirm it truly means *all* orgs under Mozilla's GitHub org umbrella, including any newer/less common ones)?
2. **Security review**: Adding `gh_access_mozilla` to every org's allowed SAML groups effectively removes the current per-org gating via `people.m.o`. Has this been reviewed with IAM/security, particularly for orgs holding sensitive or restricted-access repos? We'd like to confirm this is an intentional access-control change and not just a convenience change.
3. **Acceptance criteria / verification plan**: How should we confirm the change was applied correctly per org (e.g., spot-check SSO login for a staff member not currently in an org's people.m.o list)? Is there a rollback plan if this grants unintended access to a sensitive org?
4. **Runbook/reference**: Is there an existing runbook or Confluence doc describing how SAML allowed-groups are managed per GitHub org (e.g., via Terraform/IaC) that we should follow, so this can be applied consistently and be auditable?

Once we have these details we can size and schedule the work.

tool calls

[
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3783"
    },
    "result": {
      "key": "MZCLD-3783",
      "summary": "Add gh_access_mozilla to every GitHub orgs allowed SAML groups",
      "status": "Backlog",
      "description_text": "This will allow Mozilla staff to login to other GitHub orgs without needing to be added to the people.m.o group",
      "comment_count": 0,
      "comments": []
    }
  }
]

usage

{
  "model": "claude-sonnet-5",
  "input_tokens": 3066,
  "output_tokens": 1481,
  "estimated_cost_usd": 0.031413
}

approvals

[]

log

launched k8s job run-run-f9816e734013bdfc in ns/mzcld-demo-dev image=us-docker.pkg.dev/moz-fx-mzcld-demo-prod/mzcld-demo-prod/agentplat:latest
runner started
live reasoning model=claude-sonnet-5
awaiting approval for 1 action(s)