3. Architecture
3. Architecture
← Previous: 2. Requirements | Index | Next: 4. Components →
3.1 System Overview
The architecture has two planes. The Azure plane decides whether a person may log in to a host and whether they are root: Entra groups, two Azure RBAC roles, PIM, all declared in Terraform. The host plane decides what a non-root person may do: Linux groups, an allow-listed sudo policy and a wrapped deploy action, delivered by Ansible and kept in agreement with Entra by a synchronisation agent that authenticates with the host's own Arc managed identity. Evidence from both planes lands in Sentinel.
3.2 Two Planes, One Source
| Question | Decided by | Declared in | Enforced by |
|---|---|---|---|
| May this person log in to this class? | Entra group → VM User Login | Terraform (arc-config map) | AADSSHLoginForLinux at connection time |
| Is this person root right now? | PIM activation on pn-host-admin → VM Administrator Login | Terraform (eligible assignment) + PIM policy | Extension places active admins in aad_admins |
May this person sudo a routine admin command? | Entra pn-host-operator → Linux pn_operator | Ansible (sudoers.d allow-list) | sudo |
| May this person write in the project tree? | Entra pn-host-editor-<class> → Linux deploy | Ansible (group + tree ownership) | filesystem permissions |
| May this person deploy? | Entra editor/deployer groups → Linux pn_deployer | Ansible (sudoers.d rule for pn-deploy as deploy) | sudo + wrapper validation |
| Does the host agree with Entra? | pn-access agent, every 5 minutes | Ansible (agent + map) | agent; drift reported to Sentinel |
The single source of truth for who is Entra; for what a group means, Git.
3.3 Authority Domains
| Domain | Authority | Controller | Change path |
|---|---|---|---|
| Person exists / is enabled | Entra ID | IT / identity admins | Entra |
| Person's tiers and classes | Entra group membership | Platform Lead (STD-IDENT-001 RACI "A"), Security owner | Entra group edit (PIM for admin eligibility) |
| Which groups get which Azure role on which class | Terraform map in ovh-infra | Platform Lead via PR (CODEOWNERS) | Git PR → Terraform apply |
| What a tier may do on a host | Ansible roles in ovh-infra | Platform Lead via PR | Git PR → Ansible run |
| Which projects the deploy action may touch | Root-owned allow-list, Ansible-managed | Platform Lead via PR | Git PR |
| Break-glass keys | Azure Key Vault | Security owner | Key Vault, rotation SOP |
| Evidence and alerts | Sentinel | Security owner | Sentinel analytics rules (in Git where possible) |
No authority is exercised by editing a host directly. Section 11 makes this the definition of "done".
3.4 Trust Boundaries
| Boundary | What crosses | Trust basis | What must never cross |
|---|---|---|---|
| 1. Person → Entra | Identity assertion | Password + MFA under Conditional Access | Unverified identity |
| 2. Entra → Arc/host | Login decision, root decision | Token validation against the two Azure roles, evaluated per connection | Cached authority after group removal (certificates are minutes-lived) |
| 3. Host → Graph | Group membership facts | Arc managed identity, read-only application permission | Any write to Entra; any secret on the host |
| 4. Human → root / Docker | Allow-listed commands; wrapped deploy | sudo policy with Runas root only; wrapper validating project/verb/service | Shells, editors, su, arbitrary Docker arguments |
3.5 Data Flow — Login and Elevation
3.6 Data Flow — Synchronisation and Decommissioning
Document Navigation
| Previous | Index | Next |
|---|---|---|
| ← 2. Requirements | Table of Contents | 4. Components → |
End of Section 3