Azure Authentication: Securely Use Vault with Managed Identity (Associate Level)

With Azure Managed Identity, apps and VMs can authenticate to Vault without storing any secrets. You reduce leak risk while cutting operational overhead at the same time.

This article covers the official-doc-aligned concepts you need for the Vault Associate exam, along with a minimal setup procedure you can drop straight into a real environment.

Why Authenticate to Vault with Managed Identity

A Managed Identity (MI) is an identity managed automatically by Azure AD — you do not create, store, or rotate any credentials yourself. Combined with Vault's Azure Auth Method, the workload logs into Vault using an access token obtained from Azure AD.

From an exam perspective, common topics include the separation between authentication (Auth Method) and authorization (Policy), role-level bind conditions (which MI or resource the request originates from), and the basics of token TTL, Max TTL, and re-authentication.

• Target workloads: VM/VMSS, App Service, Functions, and AKS nodes or Pods (via Workload Identity)
• Benefits: secret-less, no rotation needed, RBAC design that scales cleanly
• On the Vault side: token validation via the Azure Auth Method, plus least-privilege grants through Policy

Architecture and Flow

Vault's Azure Auth Method accepts an access token signed by Azure AD (obtained via an MI or Service Principal) and performs signature validation and claim inspection. When the role's bind conditions — such as subscription ID, resource group, or VM/VMSS name — are satisfied, Vault issues a client token with the associated policies attached.

The key requirements are: a matching Audience (resource), a token within its validity period, and the role's bind constraints being satisfied.

• Obtain the MI's token from Azure IMDS (resource is typically https://management.azure.com/)
• Vault validates the signature with Azure AD's public key and matches the claims (xms_mirid, etc.) against resource attributes
• Authorization is controlled by Vault Policy (least privilege at the path level)

Vault authentication flow with Managed Identity

Vault-Side Setup (Azure Auth Method + Policy)

First, enable the Azure Auth Method and configure the tenant information and resource (audience). Next, define which Azure resources are allowed to present tokens via a role, and finally attach the Vault policy that grants the actual access.

The example below is a minimal configuration. Replace constraints — subscription, resource group, VM name, etc. — with your real resource IDs to match your environment and requirements.

• auth/azure/config: set tenant_id and resource (typically https://management.azure.com/)
• auth/azure/role/<name>: set bind conditions (subscription / resource group / VM / VMSS, etc.) along with token_policies
• Policy: least-privilege path permissions (only the read/list/write you absolutely need)

Vault configuration example (CLI and HTTP API)

# 1) Azure 認証メソッドの有効化
vault auth enable azure

# 2) テナントと audience(resource) の設定
vault write auth/azure/config \
  tenant_id="00000000-0000-0000-0000-000000000000" \
  resource="https://management.azure.com/"

# 3) ロール定義（例）
#   - 実運用では、サブスクリプション/リソースグループ/VM(SS)名などで厳格に縛る
#   - token_policies で付与するポリシーを指定
vault write auth/azure/role/app-role \
  bound_subscription_ids="11111111-1111-1111-1111-111111111111" \
  bound_resource_groups="rg-app-prod" \
  # 必要に応じて VM/VMSS 名、スケールセット、SPN ID などの制約を追加 \
  token_policies="app-kv-read" \
  token_ttl=1h token_max_ttl=4h

# 4) 最小権限ポリシー例（読み取りのみ）
tee /tmp/app-kv-read.hcl <<'POLICY'
path "kv/data/app/*" {
  capabilities = ["read"]
}
POLICY
vault policy write app-kv-read /tmp/app-kv-read.hcl

# 参考: HTTP API でのログイン例（後述のワークロード側で実行）
# curl --request POST \
#   --data '{"role":"app-role","jwt":"<AAD_access_token>"}' \
#   http://<vault_addr>/v1/auth/azure/login

Azure / Workload-Side Setup (Obtain Token via MI and Log Into Vault)

The workload obtains an Azure AD access token via Azure IMDS. The resource must match the value configured in Vault's auth/azure/config (typically https://management.azure.com/). If it does not match, the request fails with an Audience mismatch.

For a System-assigned MI, no extra parameters are needed. For a User-assigned MI, supply client_id to IMDS to fetch that specific MI's token. Then send the resulting jwt to Vault's /auth/azure/login to receive a Vault token, which you use to retrieve secrets from kv/ or other secrets engines.

• IMDS endpoint: http://169.254.169.254/metadata/identity/oauth2/token
• Required header: Metadata: true
• Query parameters: api-version, resource (and client_id when needed)
• Verify that the audience (resource) matches what Vault expects

Role Design and Least-Privilege Policy Tips

A role is the boundary for who is allowed into Vault, while a policy defines what they can do once they get in. Keeping these two concerns clearly separated is the key to stable operations.

Even for the same application, split roles and policies per environment (dev/stg/prd) to shrink the attack surface and blast radius.

• Default to one role per workload, and bind tightly by resource group or VM/VMSS name
• Keep policy paths fine-grained (e.g., read-only on kv/data/app/prod/*)
• Keep TTLs short and assume periodic re-authentication (understand the difference between token_ttl and token_max_ttl)
• Enable audit devices so you can cross-reference role_name and path for post-incident analysis

Troubleshooting and Common Exam Points

Audience mismatch: the resource of the token obtained from IMDS does not match the resource in Vault's auth/azure/config. The safest approach is to align both to https://management.azure.com/.

User-assigned MI: failing to specify client_id when fetching the token from IMDS results in a 403. Use the correct client_id for the intended MI.

Clock skew: AAD token validation is strict about expiry and issuance time. Keep NTP healthy.

• Check logs: review Vault server audit logs and raise the log level for auth/azure
• Minimal repro: confirm connectivity first with a policy limited to a simple kv read
• Cloud environments: watch for endpoint differences across Public, China, and Gov clouds

Check Your Understanding

Frequently Asked Questions