IntermediateSecrets Management

Secrets & Key Management

Master Azure Key Vault: secure storage and management of secrets, keys, and certificates. Learn access policies and best practices.

🧠 ELI5 Explanation

Secret: Sensitive data you don't want exposed (password, API key, database connection string). Key Vault: A super-secure locked box that stores secrets. Access Policy: Only specific people (or apps) can open the box. You don't hardcode secrets in your code; instead, code asks Vault: "Can I have the password?" Vault checks who's asking, then provides it.

Technical Explanation

Azure Key Vault Overview

Managed service for secure secret storage & retrieval:

Secrets: Passwords, connection strings, API keys (plain text, up to 25KB)
Keys: Encryption keys (RSA, EC, symmetric)
Certificates: X.509 digital certificates
Access Control: RBAC + access policies (legacy)

Why use it? Don't hardcode secrets in code/config. Vault stores them encrypted, audits access, rotates periodically.

What NOT to Do (Anti-patterns)

❌ Store secrets in environment variables on VM
❌ Hardcode passwords in source code (git history is forever)
❌ Store in plain text in config files
❌ Share secrets via Slack/email
✅ Use Key Vault + managed identity for production

Key Vault Access Control

Method	What It Controls	Who Uses It
RBAC	Vault-level: list/create/delete Vault contents	Modern (recommended)
Access Policies	Secret/key operations: get/set/delete/list specific secrets	Legacy (still supported)

Example RBAC role: "Key Vault Secrets Officer" can read/write secrets

Example Policy: AppServiceIdentity can "get" secrets but not "delete"

Managed Identity + Key Vault Pattern

Best practice for apps to retrieve secrets securely:

App Service/VM gets a managed identity (system-assigned or user-assigned)
Managed identity = Azure-managed credential (no password to manage)
Grant managed identity access to Key Vault (RBAC or policy)
App requests secret: "Hi, I'm this managed identity, give me secret X"
Vault verifies identity, returns secret
No hardcoded credentials in code

Visual Representation

Secret Retrieval Flow


      App (in App Service)

      ├─ Has Managed Identity

      │  ├─ Requests token from Azure AD

      │  └─ Gets token: "I'm WebApp_Identity"

      ├─ Uses token to call Key Vault

      │  └─ "Get secret: dbPassword, token: ..."

      │

      Key Vault

      ├─ Validates token with Azure AD

      ├─ Checks access policy

      ├─ WebApp_Identity can "get dbPassword"? YES

      └─ Returns encrypted secret to app

      │

      App uses secret to connect to database

Hands-on: Create & Store Secrets

# Create a Key Vault
az keyvault create --name myKeyVault --resource-group myRG --location eastus

# Store a secret
az keyvault secret set --vault-name myKeyVault --name dbPassword --value "supersecret123!"

# Retrieve secret
az keyvault secret show --vault-name myKeyVault --name dbPassword --query value

# Update secret
az keyvault secret set --vault-name myKeyVault --name dbPassword --value "newpassword456!"

# List all secrets
az keyvault secret list --vault-name myKeyVault --query "[].{name:name}" --output table

# Grant managed identity access to Key Vault
az keyvault set-policy --name myKeyVault \
 --object-id {managedIdentityObjectId} \
 --secret-permissions get list

# Delete secret (soft delete = can recover)
az keyvault secret delete --vault-name myKeyVault --name dbPassword

Real-world Use Case

Scenario: E-commerce app stores DB password in Azure SQL Database connection string.

Insecure approach: Hardcode in App Service config → password exposed in git, shared via email, visible in Azure Portal logs.

Secure approach (Key Vault):
1. Create Key Vault, store password as secret "sqlPassword"
2. App Service gets managed identity
3. Grant App Service identity access to Vault secret
4. App code: secret = keyvault.get_secret("sqlPassword")
5. No password in code, config, or git
6. Vault logs every access attempt (audit trail)
7. Rotate password monthly → app automatically gets new value next request

Summary

Key Vault: Managed service for storing secrets, keys, certificates securely.
Never hardcode secrets. Use Key Vault + managed identity.
Managed Identity: Azure-managed credential for apps to authenticate securely.
Access Control: RBAC (modern) or Access Policies (legacy).
Audit: Every secret access is logged.

Interview Questions

Q (Beginner): Should you store API keys as environment variables on a VM?
A: No. Anyone with VM access can read them. Use Key Vault instead—only apps with correct managed identity can retrieve.

Q (Beginner): What's a managed identity?
A: Azure-managed credential for VMs/App Services. No password to manage. Azure handles generation & rotation.

Q (Intermediate): How do you grant an App Service access to Key Vault?
A: 1) Enable managed identity on App Service 2) Grant identity RBAC "Key Vault Secrets Officer" role or access policy 3) App uses identity token to request secrets.

Q (Intermediate): What's the difference between RBAC and Access Policies for Key Vault?
A: RBAC = vault-level actions (who can delete vault). Access Policies = secret-level actions (who can read/write specific secrets). RBAC is modern.

Q (Scenario): Your app needs database password, API key for payment processor, and TLS certificate. How do you manage these in Key Vault?
A: Store password & API key as secrets, certificate as certificate object in same vault. Grant app managed identity access to all. App retrieves at runtime. Single point of audit/rotation.