Share via

Best practice to centrally manage and rotate auto-generated API/access keys for Azure resources?

Yu-Jeong Seo 270 Reputation points
2025-10-27T01:11:47.8233333+00:00

I’m looking for a practical, Azure-native way to centrally discover, store, and rotate the API/access keys that many Azure services generate automatically (e.g., Storage account keys, Cosmos DB keys, Azure AI Search admin/query keys, Cognitive Services/AOAI keys, etc.).

What I’m doing today: When a new resource is created, I manually check whether it has an API/access key. I upload that key as a secret to Azure Key Vault. A Logic App periodically rotates keys (per service API) and updates the corresponding Key Vault secrets.

This works, but it’s labor-intensive because I have to detect each new resource and register it by hand. I’m hoping there’s a more streamlined, Azure-provided approach.

What I’d like to achieve:

  1. Discovery / inventory Is there a built-in way to identify new resources that have data-plane keys (via Azure Policy, Azure Resource Graph, etc.) and automatically onboard them to a rotation workflow (e.g., Policy DeployIfNotExists)? Any official patterns or samples?
  2. Automatic secret ingestion on resource creation Is there an out-of-the-box mechanism to capture keys when resources are created (e.g., Event Grid on Microsoft.Resources.ResourceWriteSuccess) and push them into Key Vault—without maintaining a big custom mapping of listKeys operations per resource type?
  3. Grace period behavior When rotating/regenerating resource access keys (e.g., Storage account keys, Cosmos DB keys, API Management subscription keys, Azure AI Search admin keys), is there any built-in grace window (e.g., old key remains valid for ~72 hours)? Or is the old key invalidated immediately upon regeneration, so rotation must rely on the typical primary/secondary key swap pattern? If this is service-specific, pointers to the official docs would be appreciated.

Environment/constraints: Enterprise/regulated environment; prefer Azure-native controls. Centralized secret storage in Key Vault; automation via Logic Apps or Azure Automation/Functions is fine if it’s the recommended pattern.

Azure API Management
Azure API Management
An Azure service that provides a hybrid, multi-cloud management platform for APIs.

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Rakesh Mishra 2,265 Reputation points Microsoft External Staff Moderator
    2025-10-27T09:54:47.5966667+00:00

    Hi @Yu-Jeong Seo , please check below and let me know if any further question on this.

    1. How to discover / inventory resources that generate auto-keys
      1. Run an initial Resource Graph scan for resource types that typically have data-plane keys (storageAccounts, Microsoft.DocumentDB/databaseAccounts, Cognitive Services, Search, etc.). Save the list to a table (resourceId, type, subscription, resourceGroup, tags).
      2. Create/maintain a small resource-type → key API & semantics mapping (e.g., storageAccounts → Access Keys REST/portal; Cosmos DB → listKeys/regenerateKey). This is the authoritative mapping your automation will use.
      3. Use Azure Policy AuditIfNotExists (or DeployIfNotExists with a managed identity for remediation) to flag resources that are not yet “onboarded” (for example, missing tag KeyVaultOnboarded=true). Policy will give you a near-real time compliance inventory.
      4. Periodically (daily/weekly) re-run Resource Graph + Policy compliance to find new or missed resources; export to a queue/CSV for remediation. (Resource Graph is fast and suitable for large inventories.)
    2. How to automatically ingest / onboard keys when a resource is created
      1. Subscribe to Event Grid for Microsoft.Resources.ResourceWriteSuccess events at subscription or resource-group scope. Filter to only resource types in your mapping. This captures new resources (and updates).
      2. Event Grid forwards the event to an Azure Function / Logic App (managed identity). The function should:
        1. Parse the event → resourceId & type.
        2. Check Azure Policy / tags to skip if already onboarded.
        3. Use your mapping to call the service’s List Keys API (or CLI) to fetch the current key(s). For example, Cosmos DB: listKeys REST; Storage: listKeys or portal/CLI.
        4. Store each key as a Key Vault secret (/<resourceName>/key1, /<resourceName>/key2) and tag the resource KeyVaultOnboarded=true. (Use Key Vault secret versioning for audit/history.)
      3. If some services don’t expose listKeys on creation or require extra steps (private preview or role), have the function enqueue the resource for a remediation run (ARM deployment script or human review). Document these exceptions in your mapping.
      4. Add a smoke-test: after writing secret to Key Vault, the function attempts a minimal auth call to the service using the stored secret to confirm it works (optional but recommended). If the test fails, raise an alert and mark resource for manual remediation.
    3. How to understand and implement grace period / rotation behaviour safely
      1. Assume service-specific behaviour — test it. Do not assume a universal grace period. For each service in your mapping, create a short test plan: regenerate key A and immediately attempt to use the old key; record whether it still works and for how long. Document results. (Storage, Cosmos DB, etc. have documented regenerate APIs; behaviour differs.)
      2. Prefer the two-key (primary/secondary) swap pattern where available:
        1. Step A: Ensure apps can read both keys from Key Vault (or switch to secondary).
        2. Step B: Regenerate secondary (key2) via API → update Key Vault secret for key2.
        3. Step C: Switch applications to key2 (update config to use new secret version).
        4. Step D: Regenerate key1. This provides zero-downtime if the service supports two keys.
      3. For services with one credential or immediate invalidation: coordinate rotation with application owners and plan a short maintenance window — or use a sidecar/feature-flag to quickly swap credentials. Treat these as higher-risk and test thoroughly.
      4. Automate verification after rotation: after your rotation run (Logic App/Function):
        1. Confirm regenerateKey returned success,
        2. update Key Vault secret,
        3. trigger Key Vault secret event and have dependent apps re-read the secret,
        4. perform a health check using the new secret. If health check fails, rollback by switching app to previous secret version (if service supports it) or alert operator.
      5. Record timelines & audit: log old/new secret versions, timestamps, who/what performed rotation; surface in Azure Monitor / Workbook for compliance (rotation older than X days). Use Policy to enforce rotation cadence where possible. I hope the provided answer is helpful,

    Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

    Thanks

    1 person found this answer helpful.
    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.