6. Authorization Model
6. Authorization Model
← Previous: 5. Identity and Login | Index | Next: 7. Deploy Action →
6.1 Principle
Azure decides whether you may log in and whether you are root; the host decides what a non-root person may do. Both are driven by the same Entra groups and both are declared in Git. This section is the host-access group taxonomy that STD-IDENT-001 delegated to STD-RBAC-001.
6.2 Machine Classes
Every Arc machine carries a tag pn_class. All grants are made per class, never per person-per-host.
| Class | Hosts | Deploy tree? |
|---|---|---|
uat | u.cnt.ap-south-1a.xxl.01 | yes (/srv/pnats) |
prod | n.cnt.ap-south-1a.xl.01, n.cnt.ap-south-1a.xxl.01 | yes |
erp | e.cnt.ap-south-1a.l.01 | yes |
data | n.cnt.ap-south-1a.l.01, n.cnt.ap-south-1a.s.01 | no |
k8s | n.cnt.ap-south-1a.s.02–s.05, n.azr.ap-south-3a.xs.01 | no (GitOps) |
pve | pnats-mum-pve-01/02, h.onp.ap-south-2a.{l.01,xl.01,xl.02} | no |
infra | syslog-collector-01 | no |
6.3 The Five Tiers
| Entra group | Azure role | Linux effect on the host | Standing or JIT |
|---|---|---|---|
pn-host-admin | Administrator Login — PIM-eligible only (approver on prod) | active admin placed in aad_admins → full sudo for that session | JIT ≤4h |
pn-host-operator | User Login | pn_operator → allow-listed NOPASSWD sudo, Runas root only | Standing |
pn-host-editor-<class> | User Login | deploy group → write in the class's managed tree; may run the deploy action | Standing |
pn-host-deployer-<class> | User Login | pn_deployer → may run the deploy action only, executed as the deploy service user | Standing |
pn-host-viewer-<class> | User Login | nothing extra | Standing |
Membership in none of these means no login. Editor implies Deployer. On classes without a deploy tree (data, k8s, pve, infra) the Editor tier confers nothing — Operator and Admin cover them; this is how "editor on every host" resolves without inventing write targets on GitOps-managed hosts.
6.4 The Access Matrix (as of this RFC)
| Person | uat | prod | erp | data | k8s | pve / infra |
|---|---|---|---|---|---|---|
| Mohammed Faizan | Admin-eligible · Operator · Editor | Admin-eligible · Operator · Editor | Admin-eligible · Operator · Editor | Admin-eligible · Operator | Admin-eligible · Operator | Admin-eligible · Operator |
| Shaik Noorullah | same | same | same | same | same | same |
| Saif Ullah | same | same | same | same | same | same |
| Syed Mujahid | Deployer | Deployer | — | — | — | — |
| all other developers | — | — | — | — | — | — |
Server access is opt-in by name. Being in POL-Developer grants nothing on hosts. The matrix lives as one Terraform map (class → group → role) plus Entra membership; changing it is a PR or a group edit, never a host edit.
6.5 Operator — What It Can and Cannot Do
Operator is the standing daily level for the three administrators: routine sudo without prompts and without becoming root-for-everything.
| Operator can (positive allow-list, run as root) | Operator cannot |
|---|---|
Install / remove / update packages (apt, dpkg, system pip, npm -g) | su to anyone — blocked for all accounts by pam_wheel |
Start / stop / restart / inspect services (systemctl) | sudo -u <anyone> — Runas is root-only, so switching into another engineer's Arc account is refused |
Read all logs (journalctl, /var/log) | obtain a root shell or root editor — no shell or editor is in the list |
Edit allow-listed configuration paths via sudoedit | modify /etc/sudoers*, PAM, or the pn-access map |
| Run the deploy action (as Editor) | read another person's home directory |
| Restart Arc / monitoring agents | pass arbitrary arguments that spawn a shell |
Every Operator sudo session is I/O-logged (Section 10). Residual, stated openly: a package manager running as root can be abused by a crafted package. Accepted for this tier because its members are the same three people who are Admin-eligible; the log makes it visible.
Why not "ALL except su": sudoers negation is bypassable (sudo bash, sudo vim then a shell escape, copying a shell binary). A positive allow-list is the only enforceable form (Invariant 5; Section 12).
6.6 Deployer — The Boundary (Mujahid's case)
A Deployer runs one wrapped action that operates an allow-listed project as the deploy service user. A Deployer cannot write files, cannot read .env (the deploy user reads it), cannot choose arbitrary compose files, and cannot reach Docker (Invariant 4). They see the deploy output and nothing else.
6.7 Editor — And Why It Requires Admin Eligibility
Editors write in /srv/pnats and run the deploy action. Because the deploy action drives Docker (root-equivalent), anyone who can edit compose/deploy definitions can reach root through a deploy. Today every Editor is also Admin-eligible, so nothing is gained by pretending otherwise. Invariant 6 keeps the tier honest as the team grows: Editor MUST only be granted to a person who is Admin-eligible on that class, unless deploy definitions are root-owned and Git-controlled.
6.8 Viewer
Login with no additional capability. Empty today; reserved for auditors or read-only roles so that a future need does not become a new Operator.
6.9 Where It Lives
| Artefact | Repository | Reviewed by |
|---|---|---|
| Class → group → role map (Terraform) | ovh-infra terraform/ (extends arc-config, replaces dataservers-rbac.tf) | Platform Lead (CODEOWNER) |
Tier semantics on host (sudoers.d, pam_wheel, groups) | ovh-infra ansible/roles/ | Platform Lead |
| Membership | Entra | Platform Lead / Security owner; PIM for admin |
| Access-map (who has what, where; break-glass locations) | ovh-infra docs/runbooks/onprem-pve-access-map.md — required by STD-IDENT-001, created by this work | Security owner, 30-day audit |
Document Navigation
| Previous | Index | Next |
|---|---|---|
| ← 5. Identity and Login | Table of Contents | 7. Deploy Action → |
End of Section 6