Vault Azure Secrets Engine: Ephemeral Service Principals in Practice

Handing out long-lived client secrets to workloads that need Azure permissions is risky. With the Vault Azure secrets engine, you can mint short-lived Service Principals on demand and let them expire automatically when the TTL elapses or the lease is revoked.

This article walks through least-privilege permission design, setup, issuance and revocation, and the operational pitfalls — all end to end. It also calls out the points that come up on the Associate and Ops certifications.

What the Azure Secrets Engine Does, and When to Choose It

The Vault Azure secrets engine registers an application in Azure AD with a matching Service Principal, assigns the configured Azure RBAC at the target scope, and then returns the client ID and client secret. Every issued credential carries a lease, and it is automatically invalidated when the TTL elapses or the lease is explicitly revoked.

The main operational benefits are minimizing exposure through short-lived credentials, automatic RBAC grant and revoke, and traceability via Vault audit logs. Unlike Key Vault, which is a storage-oriented service, this engine is purpose-built for issuance and lifecycle management.

• Key paths: azure/config, azure/roles/<name>, azure/creds/<name>
• Define role_name and scope in a role to automate RBAC assignment
• Leases and TTLs drive automatic expiry; vault lease revoke handles immediate revocation
• Audit: every issuance is recorded by Vault audit devices

Prerequisites and Least-Privilege Permissions

Because Vault performs app registration, Service Principal creation, and role assignments on the Azure side, the configuration credential it uses needs both directory and RBAC permissions. You also need a network environment where Vault can reach Microsoft Graph and Azure Resource Manager.

In practice, the key is to minimize the creation and assignment permissions and tightly scope them. Exams also frequently ask which permission is required for which operation.

• App/Service Principal creation: directory-side permissions such as Application Administrator
• Role assignment: Owner or User Access Administrator at the assignment scope
• Required endpoint reachability: login.microsoftonline.com, Microsoft Graph, and the management API
• Vault side: control paths through an appropriate auth method (AppRole, OIDC/JWT, etc.) and policy

Setup: Enabling the Engine and Writing the Config

Start by enabling the secrets engine and saving the tenant_id along with the client_id/client_secret used for configuration. Specifying the environment (such as AzurePublicCloud) lets Vault pick the right endpoints. Then tune the TTL policy.

Role definition and issuance are covered in the next section. Here we show the fastest path to a working setup via CLI/HTTP API, along with an example Terraform definition for operational automation.

• Enable: vault secrets enable azure
• Configure: vault write azure/config tenant_id, client_id, client_secret, environment
• TTL settings: tune default TTL and max TTL via azure/config/lease

Initial setup and smoke test using CLI/HTTP and Terraform

#!/usr/bin/env bash
set -euo pipefail

# 1) 有効化と Azure クレデンシャル設定
vault secrets enable azure || true
vault write azure/config \
  tenant_id="$AZURE_TENANT_ID" \
  client_id="$AZURE_CLIENT_ID" \
  client_secret="$AZURE_CLIENT_SECRET" \
  environment="AzurePublicCloud"

# （任意）デフォルトのリース設定
vault write azure/config/lease ttl=1h max_ttl=24h

# 2) ロール定義（resource group 範囲に Contributor を付与する例）
cat > role-dev.json <<'JSON'
{
  "azure_roles": [
    {
      "role_name": "Contributor",
      "scope": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/app-rg"
    }
  ],
  "ttl": "1h",
  "max_ttl": "24h"
}
JSON

curl \
  --silent \
  --header "X-Vault-Token: $VAULT_TOKEN" \
  --request POST \
  --data @role-dev.json \
  "$VAULT_ADDR/v1/azure/roles/dev" | jq '.'

# 3) 認証情報の発行（出力に client_id, client_secret, tenant_id, lease_id など）
vault read -format=json azure/creds/dev | jq '.'

# 4) 取り消し（即時失効）
# vault lease revoke <lease_id>

# ------------------------------
# Terraform 例（抜粋）
# ------------------------------
# provider "vault" {}
# resource "vault_azure_secret_backend" "az" {
#   path          = "azure"
#   tenant_id     = var.tenant_id
#   client_id     = var.client_id
#   client_secret = var.client_secret
#   environment   = "AzurePublicCloud"
# }
# resource "vault_azure_secret_backend_role" "dev" {
#   backend  = vault_azure_secret_backend.az.path
#   role     = "dev"
#   ttl      = "1h"
#   max_ttl  = "24h"
#   azure_roles = [{
#     role_name = "Contributor"
#     scope     = "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/app-rg"
#   }]
# }

Role Design and the Issuance Flow

A role defines which Azure RBAC to grant to the issued Service Principal at which scope, along with TTL and Max TTL. Scopes can be narrowed down to a subscription, a resource group, or even a specific resource. A single role can include multiple role_name/scope pairs, but following the principle of least privilege and splitting roles by environment and use case keeps operations stable.

Issuance is just a read on azure/creds/<role>: Vault registers the app and Service Principal in Azure AD and applies the role assignments at the defined scope. The response contains client_id, client_secret, tenant_id, and lease information, and it expires automatically when the TTL is exceeded. To revoke explicitly, pass the lease_id to the revoke command.

• Example scopes: /subscriptions/<subId>/resourceGroups/<rg>, or a specific resource ID
• Keep TTL short and allow renewal aligned with job runtime
• azure/creds/<role> is a read operation — watch out for confusing it with write on the exam

Service Principal issuance flow through Vault

Operations: TTL/Renewal, Revocation, Auditing, and SRE-Side Pitfalls

Manage TTL via per-role configuration or the default lease setting. For long-running jobs, design the client to renew the lease. On failure, revoke immediately to invalidate and then re-issue. Always enable a Vault audit device to ensure traceability of every issuance and revocation.

Common operational pitfalls include overly broad role-assignment scopes, Graph API rate limits, and creation failures due to insufficient permissions. When using this from CI, make the mapping between the Vault auth method (AppRole/OIDC) and the role explicit to prevent misuse.

• Decide the lease renewal strategy together with job control
• Minimize scopes and split roles per environment
• Regularly review and emit metrics based on audit logs
• Throttle batch executions to deal with rate limits

Troubleshooting and Exam-Prep Highlights

The typical cause of creation or assignment failures is insufficient permissions. App registration and SP creation need directory permissions, while role assignment needs Owner or User Access Administrator at the target scope. When you see an Insufficient privileges message, check permissions and scope first.

On the exam, the key paths of the engine, the relationship between roles and scopes, and the lease concept come up frequently. Remember that azure/creds/<role> is a read operation and that revocation is done via lease revoke.

• Insufficient privileges: check both directory permissions and scope permissions
• 429 Too Many Requests: retry with jitter between executions
• Bad scope format: always use the full resource ID
• Exam keywords: azure/config, azure/roles/<name>, azure/creds/<name>, TTL/lease, least privilege

Check Yourself with a Question

Frequently Asked Questions