SSO Mandate, Break-Glass Accounts, and a CI Pipeline on Prism APIs

Split the problem into three identity classes and treat them differently.

Class	Mechanism	Reasoning
Humans	Okta SAML on Prism Central, MFA at the IdP	PC is the control plane for managed clusters, so one integration covers the estate; centralised deprovisioning is the real security win
Break-glass	Two local Prism accounts, non-AD, unique long passwords in the vault, source-IP restricted management plane, login alerting	SAML has external dependencies (IdP, DNS, routing). The 40-minute outage proved the estate needs a path that survives IdP failure
Automation	Dedicated service accounts with API keys, one per pipeline, not SAML, no shared human account	A machine identity cannot satisfy MFA, and a shared account destroys non-repudiation in the audit log

Why disabling local authentication was the wrong fix. It converts an IdP outage into a total estate outage. The correct control is not 'no local accounts' but 'very few, heavily constrained, monitored local accounts'.

Supporting decisions:

• Rename or disable the default admin account; require break-glass accounts to be created deliberately and documented.
• Constrain the management plane (jump host or management VLAN) so a break-glass credential alone is not sufficient from an arbitrary network.
• Confirm directory service configuration exists at Prism Central for managed clusters, and check whether any standalone cluster still has its own local users outside that model.
• Alert on any local-account authentication; legitimate break-glass use should be rare and loud.
• Test the break-glass path on a schedule. An untested fallback is equivalent to having none.

Start from the job, not the tool. Enumerate who actually needs which verbs: platform team (lifecycle, upgrades), NOC (visibility only), app teams (VM operations inside their own scope), backup team (protection and restore only), pipeline (a narrow, scripted set of calls).

Proposed assignment:

• 2–3 Cluster Admin equivalents, one of which is the break-glass identity. Everyone else is reduced.
• NOC → Prism Viewer. Read-only; fixes the largest single source of privilege sprawl.
• App teams → Prism Self-Service Admin scoped by projects/categories so one team's scope cannot reach another's workloads.
• Backup team → Backup Admin style role: create, protect, restore - explicitly not VM delete or cluster configuration.
• Pipeline → a custom role containing only the API calls the pipeline makes (inventory read, power operations on a named set), bound to its own account, with source-IP restriction and key rotation.

Why not 'give everyone Project Admin and move on': broad project roles still permit destructive verbs, and the access review then cannot distinguish intent. The value here is that each AD group maps to a named, defensible function.

Access review evidence: exported role-to-AD-group mapping with member counts, list of identities holding Cluster Admin with justification and expiry, last-login data for dormant accounts, the custom role's permission list next to the pipeline's actual API calls, and a record of the previous review's actions closed out.

Recognise the mismatch: MFA is a control for humans; the pipeline is a machine. Forcing it onto a shared human-shaped account either breaks automation or pushes someone to store an MFA seed next to the password - which is worse than no MFA because it creates false assurance.

Resolution:

1. Retire the shared svc-prism identity. Create one service identity per pipeline, owned by a named team, with a documented purpose.
2. Authenticate with Prism API keys scoped to a least-privilege custom role, not a human SSO session.
3. Restrict the key to known source addresses (build agents/proxy), rotate on a schedule and immediately on owner change.
4. Exclude only these machine identities from the SAML/MFA policy, explicitly and by name - not by turning off SSO broadly.

Residual risk accepted and how it is bounded: API keys are bearer secrets, so compromise gives the holder whatever the role allows. Bound it with the narrow role, the IP restriction, rotation, and alerting on API calls outside the expected pattern (for example, a delete verb the pipeline has never issued). Monitor with the same audit pipeline as human logins so a stolen key looks different from normal behaviour.