Authorization
Authorization decides which systems we secure, which identities may change them, and who may approve movement toward production. In ATO, access control and change control are connected: the same role model that governs GitHub, ArgoCD, AWS, and Grafana also governs PR approval, branch bypass, and environment promotion.
Use this page whenever a change raises one of these questions:
- “Who is allowed to approve this?”
- “Can this person promote to production?”
- “Is this access request too broad?”
- “Can a vendor, bot, or service account do this?”
- “What evidence proves the right person approved it?”
Boundary
| Inside Platform Engineering boundary | Inherited or external |
|---|---|
| GitHub org settings, repositories, CODEOWNERS, workflows | GitHub hosted platform |
| Terraform modules, state workflows, and Atlantis gates | Cloud Services AWS account foundation |
| ArgoCD, Helm, namespaces, and EKS workload configuration | AWS physical infrastructure and base networking |
| 1Password references, External Secrets, service-account config | Cloudflare edge and WAF |
| Kyverno, Falco, Grafana, ArgoCD audit logs | Wiz and other SaaS security tooling |
Platform Engineering can configure, patch, monitor, and audit the left column. The right column is used or inherited but not directly administered by this team.
Role matrix
| Role | GitHub | ArgoCD | AWS | Grafana |
|---|---|---|---|---|
| Technical Owner | Full Admin | Full Admin | Super Admin | Full Admin |
| Technical Admin | Admin | Admin | Conditional | Admin |
| Developer | Contributor | Read-only | None | Read-only |
| Security Engineer | Read-only | Read-only | None | Read-only |
| Site Reliability Engineer | Contributor | Read-only | Conditional | Maintainer |
| QA Engineer | Read-only | Read-only | None | Read-only |
| Content Administrator | None | None | None | None |
Production access is limited to Technical Owners and Technical Admins. Conditional AWS access is granted case by case with Technical Owner approval; it is not standing access.
Review and promotion authority
| Decision | Authorized role | Evidence |
|---|---|---|
Merge to main | Non-author reviewer, with CODEOWNERS when configured | PR approval, resolved threads, required checks |
| Bypass a review or gate | Technical Owner, emergency only | Incident or ticket reference, bypass audit log, follow-up review |
| Promote to staging | Release Manager or Technical Admin | Workflow run, approving actor, tag or image digest |
| Promote to production | Technical Owner or Technical Admin, with protected environment approval | Production environment approval, ArgoCD sync, release record |
| Grant elevated access | Technical Owner or Technical Admin | Access request, approval, expiry or review date |
What to notice: the action and the evidence are paired. If the evidence is missing, the authority path is incomplete.
Separation of duties
Separation of duties means one person should not be able to write a production-affecting change, approve it, and promote it alone. The control is not about slowing people down; it is about making sure a second accountable person sees the risk before it reaches production.
| Situation | Acceptable path | Why |
|---|---|---|
| Developer opens a feature PR | Another engineer reviews and approves | The author does not approve their own work |
| Technical Admin promotes a release | PR was already reviewed by a non-author, and production approval is recorded | Build approval and production movement are separate |
| Emergency fix is needed | Emergency PR, Technical Owner bypass if required, incident reference, follow-up review | Urgency is documented instead of hidden |
| Bot opens a dependency PR | Human reviewer approves after checks pass | Automation proposes change; a human accepts risk |
| Vendor opens a PR | Engineering reviewer approves before merge | Platform accountability stays with Engineering |
If you are unsure whether the same person is wearing too many hats, ask: “Could this one account move unreviewed code into production?” If the answer is yes, the access path is too broad.
Role intent
- Technical Owner is a permanent employee accountable for platform governance, security, and risk.
- Technical Admin operates maintenance, pipelines, and emergency override paths.
- Developer builds and tests application code without production infrastructure access.
- Security Engineer reviews vulnerability and compliance posture with read-only access.
- SRE owns observability and reliability work with limited operational permissions.
- QA validates deployments and stability with read-only access.
- Content Administrator manages Drupal content only, not code or infrastructure.
Access principles
- Separation of duties: author, reviewer, and promoter roles are distinct.
- Least privilege: read-only is the default below Technical Admin.
- SSO first: all human access is centrally authenticated and auditable.
- Employee accountability: Technical Owner cannot be delegated to vendors or contractors.
- GitOps control: production change authority is merge and promotion authority, not server access.
- Quarterly review: roles and grants are reviewed against this matrix.
Access request pattern
Access should be requested in writing, approved by the right owner, scoped to the job, and reviewed later. A request that only says “needs admin” is not enough.
Every access request should include:
- the person, bot, or service account receiving access
- the system and environment involved
- the minimum role needed
- the reason access is needed
- the approver
- the expiration date or review cadence
- the ticket, incident, or project reference
Use time-limited access when the need is temporary. Standing production access should be rare and tied to an ongoing operational responsibility, not convenience.
Branch and bypass rules
main is the only long-lived code branch. Work happens on short-lived branches, merges through PR review, and promotes through release tags and environment values. Direct writes to main, force pushes, branch deletion, and unreviewed production movement are not normal authority paths.
| Rule | Why it exists |
|---|---|
Protect main | Keeps the deployment baseline controlled |
| Block direct pushes | Forces review, checks, and audit metadata |
| Require at least one approval | Creates separation of duties |
| Dismiss stale reviews | Prevents old approvals from covering new code |
| Require conversation resolution | Keeps review concerns visible |
| Enforce squash-only linear history | Makes one PR equal one revertible commit |
| Require code-owner review where configured | Routes owned areas to accountable reviewers |
| Restrict production environment approval | Keeps production promotion separate from authorship |
Emergency bypass is narrow by design. technical-owners may bypass selected review, workflow, restricted-data, deploy-gate, or release-tag rules only when delay creates greater risk than the bypass. They cannot bypass direct mainline write protections, branch naming, or commit-message rules. Every bypass needs an incident or ticket reference and a follow-up review.
Common mistakes
| Mistake | Safer path |
|---|---|
| Giving admin because the exact permission is unclear | Start read-only, then add the narrow permission that unblocks the task |
| Letting the author approve their own PR | Request a non-author reviewer |
| Promoting from a personal token | Use the protected environment workflow |
| Leaving temporary access in place | Add an expiry or review date to the request |
| Treating a bypass as invisible cleanup | Record incident, approver, reason, and follow-up |
Enforcement
Access is enforced through IAM and service accounts, GitHub teams, branch protection, GitHub environment reviewers, ArgoCD RBAC, centralized SSO, account lifecycle tickets, and quarterly access reviews. Offboarding disables SSO first, then removes GitHub, ArgoCD, AWS, and Grafana grants.
Branch policy is enforced by organization rulesets:
branch-protectionstargets default branches, blocks deletion and force-pushes, requires linear history, and allows only squash merges.code-reviewrequires PRs, code-owner review where configured, stale review dismissal, and conversation resolution.conventional-branch-namesrequires the approved prefix plus lowercase slug.release-tagsallows only approved SemVer, beta, and release-candidate tag shapes.
ATO evidence
| Evidence | Supports |
|---|---|
| Boundary diagram and role matrix | AC-3, AC-6 |
| Quarterly access review | AC-2, AC-6 |
| Account disablement or offboarding record | AC-2, IA-2 |
| Author, reviewer, and promoter separation | AC-5 |
| SSO and MFA policy export | IA-2 |
| Default-branch ruleset export and CODEOWNERS routing | AC-5, CM-3, CM-5 |
| Bypass audit log with incident or ticket reference | CM-3, CM-5 |