SCENARIO 14 Azure Managed Identity NHI Key Vault

Azure Managed Identity & NHI Governance

Azure workloads relied on static client secrets stored in config files and environment variables — no expiration enforcement, no workload binding, no per-operation audit trail. Managed Identity deployed on IDS-NHI-VM eliminates all stored credentials. VM pulls Key Vault secrets via IMDS bearer token, RBAC scoped to Key Vault Secrets User, 403 break/fix evidence confirms platform-enforced authorization boundary. Extends the cross-cloud NHI narrative from Scenario 09.

Azure Managed Identity Azure Key Vault IMDS Azure RBAC Log Analytics SOC 2 CC6.1/CC6.3/CC6.6

Business Problem

IDSentinel Solutions operated Azure workloads using service principal client secrets stored in application configuration files and environment variables. These static credentials were manually rotated on an ad hoc basis, had no expiration enforcement, and were shared across multiple pipeline stages. When a developer left the organization, there was no reliable process to determine which workloads held copies of credentials they had originally provisioned. The security team had no audit trail showing which workload accessed which secret and when.

This was the same class of problem documented in Scenario 09 — AWS IAM Least Privilege, where AWS workloads relied on long-lived access keys rather than role assumption. Scenario 14 extends the non-human identity governance narrative to Azure, using the platform-native credential elimination mechanism: Managed Identity.

Risk

  • Static client secrets decoupled from the workload — a secret provisioned for a VM could be copied into a pipeline, retained by a departing developer, or stored in config files with no workload binding
  • No resource-scoped authorization boundary — a single secret granted access to every resource the principal was assigned to, regardless of which workload legitimately needed it
  • Legacy vault-level access policies could not restrict access to individual secrets and did not produce per-operation audit events consumable by the SIEM
  • SOC 2 CC6.1 non-compliant — shared static credentials with no workload binding, no expiration policy, and no per-operation audit trail

Scope

ComponentDetail
Cloud PlatformMicrosoft Azure
Workload VMIDS-NHI-VM (Ubuntu Server 24.04 LTS, South Central US)
Identity MechanismAzure Managed Identity — System-Assigned and User-Assigned
Target ResourceAzure Key Vault — kv-idsentinel-azureuser (RBAC authorization mode)
Authentication ProtocolOAuth 2.0 bearer token via Instance Metadata Service (IMDS)
Authorization ModelAzure RBAC — Key Vault Secrets User role
Audit DestinationKey Vault diagnostic logs → Log Analytics (law-idsentinel-nhi)
Compliance TargetSOC 2 CC6.1, CC6.3, CC6.6
Cross-Cloud ReferenceScenario 09 — AWS IAM Least Privilege (STS role assumption pattern)

Solution Design — 3 Workstreams

WS 1

Managed Identity Configuration

System-assigned Managed Identity enabled on IDS-NHI-VM — Azure creates a corresponding Entra ID service principal with no credentials. Lifecycle tied to the VM; identity deleted automatically on deprovisioning. User-assigned managed identity also provisioned to document decision criteria between the two types.

WS 2

Key Vault RBAC Authorization

Key Vault provisioned with Azure RBAC permission model — role assignments can be scoped to individual secrets, integrates with PIM, and all data-plane operations produce audit events. Key Vault Secrets User role assigned to the VM's managed identity — read access to secret values only, no write or management permissions.

WS 3

Audit Trail and Lifecycle Validation

Key Vault diagnostic settings forward AuditEvent logs to Log Analytics. Audit log captures each retrieval event with managed identity Object ID, operation type, HTTP status, and timestamp. Break/fix evidence captured before and after role assignment — confirms authorization boundary enforced at platform layer independently of workload code.

// diagrams/azure-managed-identity.png — IMDS token acquisition flow and cross-cloud NHI architecture expand
IMDS token acquisition flow and cross-cloud NHI architecture

Implementation

  • 01

    Enable System-Assigned Managed Identity

    System-assigned Managed Identity enabled on IDS-NHI-VM via the Azure portal Identity blade. Enabling the identity created a corresponding service principal in Entra ID with no credentials attached. The principal's Object ID was recorded for use in the role assignment and for correlating audit log entries back to the workload.

    // 01-managed-identity-enabled expand
    Identity blade — Status On, Object ID recorded
  • 02

    Provision Key Vault in RBAC Mode

    Azure Key Vault kv-idsentinel-azureuser provisioned with the Azure RBAC permission model selected at creation. This authorization model cannot be changed after vault creation without reprovisioning. RBAC mode chosen over legacy access policies for secret-level scoping, PIM integration, and per-operation audit event generation. A test secret was added as the target resource for validation.

    // 02-keyvault-rbac-mode expand
    Key Vault Properties — Permission model: Azure role-based access control
  • 03

    Break/Fix — 403 Before Role Assignment

    Before any role assignment was made, a Python script was executed on IDS-NHI-VM via Azure Serial Console. The script called the IMDS endpoint to acquire a bearer token scoped to Key Vault, then attempted to retrieve the secret. The request returned 403 Forbidden.

    • Finding: Token acquisition via IMDS succeeded — managed identity authenticated correctly to Entra ID — but the authorization check at the vault failed because no role assignment existed
    • Key principle: Authentication and authorization are independent controls. A valid Entra ID token does not confer access to a resource without a corresponding RBAC assignment on that resource
    // 03-403-before-role-assignment expand
    Token acquired via IMDS — HTTP 403 on Key Vault retrieval before role assignment
  • 04

    Assign Key Vault Secrets User Role

    Key Vault Secrets User role assigned to the VM's managed identity principal in the Key Vault Access Control (IAM) blade, scoped to the vault level. The built-in role grants Get and List operations on secret values only — no write, delete, or management permissions, and no access to keys or certificates in the same vault.

    // 04-role-assignment expand
    Key Vault IAM — Key Vault Secrets User assigned to managed identity principal
  • 05

    Validation — Credential-Free Secret Retrieval

    After role assignment propagation, the same Python script was executed again on IDS-NHI-VM. The script called the IMDS endpoint, received a scoped bearer token, and presented it to Key Vault. The secret value was returned successfully. No client ID, client secret, certificate, or stored credential appeared anywhere in the script — the only authentication material was the short-lived IMDS token, scoped to the target resource and never written to disk.

    // 05-successful-retrieval expand
    HTTP 200 — masked secret value returned, no credentials in script
  • 06

    Audit Trail Validation — Log Analytics

    Key Vault diagnostic settings configured to forward AuditEvent logs to Log Analytics workspace law-idsentinel-nhi. A KQL query against the AzureDiagnostics table confirmed the SecretGet event with the managed identity Object ID as the caller, operation type, HTTP 200 result code, and timestamp — providing the workload-attributable access trail that was missing under the static credential model.

    // 06-keyvault-audit-log expand
    Log Analytics — SecretGet event, managed identity Object ID as CallerIdentity, HTTP 200
  • 07

    System-Assigned vs. User-Assigned Managed Identity

    User-assigned managed identity id-idsentinel-shared provisioned as a standalone Azure resource and assigned to IDS-NHI-VM to demonstrate that a single VM can carry both identity types simultaneously. Key distinction: a user-assigned identity persists independently of any single resource — it can span multiple VMs and survives resource replacement, making it the correct pattern for scale sets or blue-green deployments where the replacement VM must inherit existing role assignments without manual reassignment.

    // 07-user-assigned-identity expand
    User-assigned managed identity id-idsentinel-shared — standalone Entra ID principal
    // 08-both-identity-types expand
    IDS-NHI-VM Identity blade — both system-assigned and user-assigned identities active

Outcome

Stored credentials eliminated — no client secrets, certificates, or access keys in workload configuration
Break/fix evidence captured — 403 before role assignment, 200 after, authorization boundary confirmed at platform layer
Identity lifecycle automated — system-assigned identity deleted automatically on VM deprovisioning, no manual IAM cleanup
Authorization scoped to least privilege — Key Vault Secrets User grants read-only secret access only
Audit trail established — per-operation log entries with managed identity Object ID, operation type, and HTTP result code
Cross-cloud NHI pattern complete — Azure managed identity (SCN-14) paired with AWS STS + ExternalId (SCN-09)

Control Coverage

ControlFrameworkEvidence
CC6.1 — Logical Access ControlsSOC 2Managed identity eliminates shared static credentials; RBAC enforces least privilege scoped to the vault
CC6.3 — Access RemovalSOC 2System-assigned identity deleted automatically on VM deprovisioning; no orphaned principal risk
CC6.6 — Logical Access BoundariesSOC 2IMDS endpoint non-routable from outside the VM; token scoped to target resource only
CC6.8 — Unauthorized Access PreventionSOC 2No extractable credential exists; 403 break/fix evidence demonstrates platform-enforced access boundary
AC-2 — Account ManagementNIST 800-53Managed identity lifecycle tied to resource lifecycle; no separate deprovisioning process required
AC-6 — Least PrivilegeNIST 800-53Key Vault Secrets User role scoped to read operations only; no write or management permissions granted

Files