run_1455c1420c958fd7

input

{
  "request": "Triage Jira ticket SREIN-1653: Grant roles/oauthconfig.editor to Den admin entitlement for OAuth client creation (moz-fx-den-nonprod / moz-fx-den-prod)",
  "references": [
    "https://mozilla-hub.atlassian.net/browse/SREIN-1653"
  ],
  "sourceContext": {
    "issue": "SREIN-1653"
  }
}

summary

SREIN-1653 requests that MozCloud grant roles/oauthconfig.editor to Den's admin-entitlement-01 IAM entitlement in moz-fx-den-nonprod and moz-fx-den-prod so the Den team can create an Internal OAuth consent screen and web client (needed to export docs to Google Drive via the drive.file scope, already security-approved under SA-780). Ticket is in Backlog with no comments yet. Key open items before granting: (1) confirm whether OAuth consent-screen creation is restricted at the org-policy level for webservices tenants — if so, an org policy exception may be needed in addition to the IAM role; (2) decide the mechanism for granting the role (Den-authored Terraform PR to their entitlement repo, using the existing secretmanager.admin grant as precedent, vs. MozCloud making the change directly); (3) verify least-privilege scope — whether project-level roles/oauthconfig.editor is appropriate or if a narrower/custom role suffices. I could not pull the linked Service Desk ticket (SDD-44721) or security approval ticket (SA-780) due to access-policy restrictions limiting reads to the triage subject issue, so those should be verified manually by the assignee.

findings

• none

proposed actions

Thanks for the detailed writeup. Before we grant roles/oauthconfig.editor to Den's admin-entitlement-01 in moz-fx-den-nonprod/prod, a few things to confirm:

1) Org policy check: Please confirm (or we'll check) whether OAuth consent-screen creation is restricted at the org level for webservices tenants. If there's a constraint (e.g. constraints/iam.allowedPolicyMemberDomains or a brand/consent-screen restriction), we may need an exception request in addition to the IAM grant.
2) Security approval: Can you link/attach the SA-780 approval directly on this ticket for our records? We don't have visibility into that ticket from here.
3) Path forward: We're fine with Den submitting a Terraform PR to add roles/oauthconfig.editor to the admin-entitlement-01 module, following the same pattern as the existing secretmanager.admin grant — please tag MozCloud reviewers on that PR (rather than us provisioning it directly) so it goes through normal entitlement-repo review.
4) Scope: Please confirm roles/oauthconfig.editor (broad project-level OAuth config editing) is actually the minimum needed vs. any narrower custom role, since this grants ability to manage the OAuth consent screen and clients broadly, not just create one client.

Once org-policy is confirmed clear and the PR is up, we can review/approve promptly. Moving this out of Backlog into 'Needs Info' pending your response.

tool calls

[
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "SREIN-1653"
    },
    "result": {
      "key": "SREIN-1653",
      "summary": "Grant roles/oauthconfig.editor to Den admin entitlement for OAuth client creation (moz-fx-den-nonprod / moz-fx-den-prod)",
      "status": "Backlog",
      "description_text": "Hi \u2014 we picked this up in a Service Desk ticket ( SDD-44721 ) and I think it lands with  your team.   Den (the Firefox Program Management Dashboard) needs to export docs to Google Drive,  which means creating an Internal OAuth consent screen and a web client in moz-fx-den-nonprod and moz-fx-den-prod. Security has already reviewed and approved the drive.file scope (SA-780), and the Workspace-side allowlisting is ours to do once  the client IDs exist.   The holdup is permissions: creating the consent screen and client needs roles/oauthconfig.editor, which isn't in Den's admin-entitlement-01 or secret-access entitlements. We don't have IAM access in the moz-fx projects, so we can't set it up  on their behalf.   Is this something MozCloud can help with? Abinathab Bennet (abennet@mozilla.com) owns Den and is happy to send a terraform PR to add the role if that's the right path \u2014 they pointed to the existing secretmanager.admin grant as precedent. They also asked whether consent-screen creation is restricted at the org level for webservices tenants, which would be worth confirming first. Thanks!",
      "comment_count": 0,
      "comments": []
    }
  },
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "SDD-44721"
    },
    "result": {
      "error": "read blocked by policy: resource not in run subject",
      "args": {
        "key": "SDD-44721"
      }
    },
    "blocked": true
  },
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "SA-780"
    },
    "result": {
      "error": "read blocked by policy: resource not in run subject",
      "args": {
        "key": "SA-780"
      }
    },
    "blocked": true
  }
]

log