Managing Secrets with Azure Key Vault

Overview and What You Will Learn

In this lab, you will create a Key Vault, store a secret in it, then grant a VM's Managed Identity permission to read that secret - so the application running on that VM can retrieve a credential at runtime without any secret ever being written into its own configuration file or source code.

Why This Matters in Production

A developer at a fintech startup hardcodes a database password directly into an application's config file, commits it to source control, and six months later that repository becomes public by accident. Every credential inside it is now compromised. Azure Key Vault exists specifically to prevent this scenario - the application never holds the actual secret value in its own files at all.

Core Principles

The pattern that makes Key Vault genuinely secure, rather than just another place to paste a password, depends on Managed Identity - an identity automatically tied to an Azure resource (like a VM) that Azure itself manages, with no credential file for you to create, store, or leak.

The application code calls the Key Vault SDK, Azure verifies the calling VM's Managed Identity has the correct access policy, and the secret is returned - all without a single credential ever appearing in the application's own files.

Detailed Step-by-Step Practical Lab

1. Create a Resource Group and a Key Vault:

2. Store a secret in the vault - here, a database connection string:

3. Create a VM with a System-Assigned Managed Identity enabled at creation time:

Note

--assign-identity gives the VM its own System-Assigned Managed Identity, a unique identity automatically tied to this specific VM's lifecycle - it's deleted automatically if the VM itself is deleted, with no separate credential to manage.

4. Grant that VM's Managed Identity permission to read secrets from the vault:

5. SSH into the VM and confirm it can retrieve the secret using its own identity, with no stored credentials anywhere on the VM:

Note

169.254.169.254 is the Azure Instance Metadata Service - a special local address every Azure VM can reach to ask "what identity am I, and can you get me a token for this resource" without any credential file being involved anywhere in that request.

6. Clean up:

Production Best Practices & Common Pitfalls

Common Mistake

Storing a secret in Key Vault, but then retrieving it once and hardcoding the retrieved value into application config anyway "to save an API call." This defeats the entire purpose - the application should retrieve the secret fresh at startup or runtime, so rotating the secret in Key Vault actually takes effect without a code or config change.

Security

Enable soft-delete and purge protection on every production Key Vault. Soft-delete means an accidentally deleted secret can be recovered within a retention window rather than being gone instantly and permanently.

• Prefer Managed Identity over service principals with stored credentials wherever the resource type supports it. A service principal still requires a client secret or certificate to be stored somewhere; Managed Identity requires nothing to be stored at all.
• Grant the narrowest secret permissions actually needed. An application that only ever reads secrets should be granted get and list, not the ability to set or delete secrets it will never need to modify.

Quick Reference & Troubleshooting Commands