RFC-PAM-0002                                                    Section 1
Category: Standards Track                                    Introduction

ProficientNow runs a small server estate across four providers: OVH dedicated servers (Proxmox), Contabo VPS (Kubernetes workers, data services, the compose-based application hosts for uat and production), an on-prem Proxmox cluster in Hyderabad, and an Azure witness node. Every Linux host is connected to Azure Arc. A handful of engineers — three or four — perform server work; the wider developer group does not.

Between April and September 2026 the platform team (ovh-infra) introduced Arc SSH with Entra ID (AADSSHLoginForLinux) as the login method for the infrastructure hosts and documented it (docs/ssh-access.md, docs/arc-ssh-quickstart.md, STD-IDENT-001). In parallel, RFC-PAM-0001 (February 2026) had proposed a Teleport-based privileged-access broker; Teleport was trialled and shelved, and its Sentinel connector was decommissioned on 2026-09-11 after 90+ days without data. The estate therefore has an implemented Arc design and an aspirational Teleport design that were never reconciled. This RFC reconciles them in favour of Arc, and completes what Arc alone leaves open.

1.2 Current State Analysis (verified 2026-09-17)

1.2.1 Hosts and Arc coverage

State	Count	Hosts
Arc-connected, Entra-SSH extension Succeeded + Arc SSH endpoint	13	uat `u.cnt.ap-south-1a.xxl.01`; ERP `e.cnt.ap-south-1a.l.01`; Contabo k8s/data `n.cnt.ap-south-1a.{s.01–s.05,l.01}`; Proxmox `pnats-mum-pve-01/02`, `h.onp.ap-south-2a.{l.01,xl.01,xl.02}`
Arc-connected, no extension, no SSH endpoint	3	production pair `n.cnt.ap-south-1a.xl.01` (vmi3392449), `n.cnt.ap-south-1a.xxl.01` (vmi3392412); `syslog-collector-01`
Arc SSH endpoint only (no Entra extension)	1	witness `n.azr.ap-south-3a.xs.01`
Windows servers (out of scope)	4	DC02, DC03, DCNOW, DS01

Only 3 of the 13 extension-bearing hosts are declared in Terraform (terraform/modules/arc-config, arc_machines); the other 10 were enabled by Ansible or by hand.

1.2.2 The shared-account problem (identity)

On the compose-based application hosts (uat and the production pair), engineers log in as the shared local account mfaizan using a shared SSH key. Deploy projects live in /srv/pnats/{apps,pnow-ats-v2} (owner root:deploy, setgid), with /home/mfaizan/* as symlinks; .env files are group-readable by deploy. Consequences: every action is attributed to one name; a leaver can only be removed by rotating the key for everyone; there is no MFA; and sudo is unrestricted for whoever holds the key.

1.2.3 The authorization problem

Where Arc SSH is in place, authorization is a single rule: the Entra group POL-Developer (7 members) holds Virtual Machine Administrator Login at resource-group scope on both Arc resource groups — full, password-less sudo on every host for every developer, whether or not they do server work. The Virtual Machine User Login role (login without sudo) is used nowhere. There is no just-in-time elevation. A per-machine, least-privilege pattern exists in one file (dataservers-rbac.tf, group POL-DataServers) but is the exception. Direct user→role assignments exist on uat and ERP, contrary to STD-IDENT-001.

Deploying requires membership of the docker group. Because the Docker daemon runs as root, docker group membership is equivalent to root — so "can deploy" has silently meant "is root".

1.2.4 The decommissioning problem

Removing a person today requires: rotating the shared key, editing authorized_keys on each host, removing them from Entra groups, and remembering which secrets they could read. STD-IDENT-001 itself records the residual: "the PVE sso role's lack of stale-user pruning at the HOST layer (open gap)". Standing root SSH keys (ovh_key, contabo_key, per-node keys in Key Vault) exist on every host as break-glass and are not use-logged.

1.2.5 What already works and is kept

Arc SSH login with MFA and short-lived certificates; Entra as the identity root; Terraform-declared role assignments (partial); Ansible as the host-configuration channel; Key Vault as the break-glass store; Sentinel as the audit sink; the /srv/pnats + deploy-group project layout.

1.3 Motivation

Attribution and revocation — every session must belong to a named person and end when their access ends. (Problem 1; largely solved by Arc, completed here.)
Least privilege with real boundaries — "deploy but cannot write" must be enforceable, not aspirational. Azure RBAC offers only login and root; the tiers in between must be built on the host and driven from Entra. (Problem 2.)
Zero-touch decommissioning — one Entra action, nothing per host, evidence that it happened. (Problem 3.)
No new infrastructure — the estate is run by a very small team; the design must use Arc, Entra, PIM, Terraform, Ansible and Sentinel, which already exist, rather than introduce a broker to operate.
Honesty about limits — Arc provides login attribution but not session replay; the design says so and compensates deliberately (Section 10).

1.4 Scope Statement

This RFC covers interactive human access to Linux hosts under Azure Arc: how a person logs in, what they may do, how that is decided and delivered, how it is evidenced, and how it ends. It defines the host-access group taxonomy that STD-IDENT-001 delegated to a not-yet-written STD-RBAC-001. It does not redesign automation identities, Kubernetes deploys, Windows hosts, or web-application SSO.

Previous	Index	Next
← Index	Table of Contents	2. Requirements →

End of Section 1

1. Introduction