"The safest secret is the one you never handle. azd leans on managed identities and Key Vault so your app authenticates without passwords in your code."
Level: Beginner · Time: ~2 days · Prerequisites: Module 10
Learning Objectives
By the end of this module, you will be able to:
- Explain managed identity and why it beats passwords
- Store secrets in Azure Key Vault
- Understand least-privilege access
- Recognize secure defaults in azd templates
1. The Problem with Passwords
Every connection string or API key in your code is a leak waiting to happen — committed to Git, shared in chat, forgotten in a file. Once a password exists, it spreads: it lands in a config file, gets copied into a teammate's .env, pasted into a support ticket, and cached in your shell history. Every one of those copies is a place an attacker only has to find once, and rotating a leaked key across all of them is slow and error-prone. The best fix is to stop storing secrets at all where you can, and store the rest in a vault.
Concept: Security isn't only about protecting secrets — it's about having fewer of them. Modern Azure lets services prove who they are without a password at all.
2. Managed Identity: Passwordless Auth
A managed identity gives your Azure app its own built-in identity. Instead of storing a database password, you grant that identity permission to the database, and Azure handles authentication automatically — no secret to leak. Under the hood, Azure issues short-lived access tokens to the identity and rotates them for you, so there is nothing to store, refresh, or accidentally commit. The identity is bound to the resource: create the app and it gets one; delete the app and the identity goes with it.
Explain like I'm new: A managed identity is a staff badge your app is born with. To use the database, you don't hand over a password; you just show the badge, and the door opens because the badge is on the guest list.
Many azd templates wire managed identities up for you by default.
3. Azure Key Vault for Real Secrets
Some secrets are unavoidable — a third-party API key, for example. Store those in Azure Key Vault, a secure, access-controlled store. Your app fetches them at runtime; they never sit in code or plain config. Better still, combine both ideas: your app uses its managed identity to open the vault, then reads the one unavoidable key from inside — passwordless access to a securely stored secret, with an audit trail of who read what and when.
resource kv 'Microsoft.KeyVault/vaults@2023-07-01' = {
name: 'kv-${uniqueString(resourceGroup().id)}'
location: resourceGroup().location
properties: { sku: { family: 'A', name: 'standard' }, tenantId: tenant().tenantId }
}Common mistake: Putting a real API key in .env and committing it. Keys in Git are found by bots within minutes. Use Key Vault (or environment secrets), and add secret files to .gitignore.
4. Least Privilege
Grant each identity only the access it needs — read-only if it only reads, scoped to one database rather than the whole subscription. If something is ever compromised, the blast radius stays small.
| Principle | In practice |
|---|---|
| Least privilege | Give the minimum role needed |
| Scope tightly | One resource, not the whole account |
| Prefer identities | Managed identity over stored keys |
Try this: For an app you know, list what it actually needs to touch. Usually it's far less than "everything." That shorter list is your least-privilege access plan.
5. Secure by Default
Good azd templates bake security in: managed identities instead of keys, secrets in Key Vault, HTTPS on, and sensible roles. Because it's all in Bicep, security is reviewable in pull requests — not an afterthought bolted on later.
Real-world use case: A template deploys a web app that talks to a database and Azure OpenAI. It uses a managed identity for both, stores the one external key in Key Vault, and grants read-only roles — so there's not a single password in the repo.
✅ Checkpoint
- What does a managed identity let your app avoid?
- Where should unavoidable secrets (like a third-party key) live?
- What is the principle of least privilege?
Answers: 1) Storing and handling passwords — it authenticates to Azure services without a stored secret. 2) In Azure Key Vault, fetched at runtime. 3) Granting each identity only the minimum access it needs, scoped as tightly as possible.
Key Takeaway: Secure azd apps minimize secrets: managed identities give your app a passwordless identity to authenticate to Azure services, and Azure Key Vault safely stores the secrets you can't avoid. Apply least privilege — the smallest role, tightest scope — and rely on templates that are secure by default, with security defined in reviewable Bicep.
Further Learning
Part of "AZD for Beginners." Adapted from Microsoft's open AZD curriculum (MIT License).