Choose Role And Permissions

Build a minimum-privilege access model that still allows teams to move changes end-to-end.

Task Outcome

By the end of this guide, each team has the permissions required for daily work, and no team has accidental broad access.

When To Use This Guide

New organization setup before first project onboarding.
Permission cleanup after repeated "action disabled" incidents.
Governance hardening before production go-live.

Prerequisites

At least one organization owner can edit governance.
Team structure is decided (Platform, DevOps, SRE, Developer).
Approval ownership for production actions is known.

UI Route Map

Open Organization and Governance.
Go to Members + Teams to confirm team ownership.
Go to Permissions + Service Accounts to assign role/grant boundaries.
Open Policy and Approvals to verify approver eligibility.

Step-By-Step Execution

Create or validate teams and assign clear owners for each team.

Apply baseline org role per user first, then narrow or extend using resource-level grants.

Grant project and cluster permissions only where operationally needed.

Confirm service accounts are scoped to automation responsibilities, not human workflows.

Validate one real action per role (for example release create, approval review, rollback preview).

Open approval queue and verify only expected users can approve production-risk actions.

Review break-glass eligibility and keep emergency rights narrow and time-bound.

Document the final ownership map and approval chain in team runbooks.

Recommended Baseline By Team

Owns org governance, grants, policy assignment, and break-glass design.
Should be the smallest privileged group in the organization.

Needs project-level execution permissions for release, promotion, and rollback.
Should not own global governance mutation by default.

Needs diagnostics visibility and controlled recovery capabilities.
Should keep governance edits separate from incident response duties.

Needs safe authoring and preview paths for workloads/variables.
Usually requests production actions instead of directly executing them.

Validation Checklist

Every team can open only its required module set.
Production deploy request is approval-gated as designed.
Requester self-approval restrictions are visibly enforced.
Break-glass ownership is explicit and limited.

Common Failure Modes

Action is hidden: missing effective permission at project/cluster scope.
Action is visible but blocked: approval gate or freeze policy applies.
Approver cannot approve: role/team eligibility mismatch.
Too many users can approve: grant spread is broader than intended.

Access Review Note Template

Access review date:
Organization:
Reviewed by:

Team: Platform
Allowed actions:
Restricted actions:

Team: DevOps
Allowed actions:
Restricted actions:

Team: SRE
Allowed actions:
Restricted actions:

Team: Developer
Allowed actions:
Restricted actions:

Approval ownership summary:
Break-glass ownership summary:
Next review date: