Best Practices for Secrets
What it is
Secrets are values that prove identity or grant access: passwords, API keys, connection strings, tokens, and private keys. Secret-handling practice is the set of rules that prevents those values from leaking through source code, pipeline definitions, logs, chat, or screenshots.
Why it exists
Someone who obtains a usable secret can often act as the application or person it represents. Prevention matters because deleting a leaked string does not remove copies from Git history, build logs, browsers, or recipients. If a secret may have leaked, rotate or revoke it and investigate its use.
Key ideas
- Avoid a stored secret when identity can do the job. An Azure workload can use a managed identity; a pipeline can use workload identity federation. Both replace a long-lived credential with a short-lived identity token.
- Keep unavoidable secrets in a purpose-built store. Azure Key Vault can centralize secrets, keys, and certificates, with identity-based access, logging, rotation, and network controls.
- Reference; do not copy. A pipeline or application retrieves the secret at runtime. Do not commit it to Git, place it directly in YAML, or paste it into a ticket.
- Treat masking as a safety net, not protection. Azure Pipelines can mask a secret variable’s full value in logs, but it does not mask substrings. Never echo a secret or pass it on a command line where another process might expose it.
- Limit the damage. Use separate, least-privileged credentials for each app and environment; restrict who and which pipeline can retrieve them; rotate routinely and immediately after suspected exposure.
Northwind example
Northwind’s deployment pipeline uses workload identity federation to deploy the web app, so it does not hold an Azure client secret. At runtime, the app’s managed identity reads the one partner API key it still needs from Key Vault. The pipeline records only the Key Vault reference; it never prints the key. If the partner key appears in a log, Priya treats it as compromised, replaces it with the partner, updates Key Vault, and checks access records.
How it fits
The best practices are the how behind linked variable groups and Key Vault, and they connect to identity via service connections. Adopt them wholesale for secure CD and for validating pipelines in security/compliance reviews.
Exam notes
- Prefer federation or managed identities over a stored credential.
- Key Vault is for secrets that must exist; it does not make a broadly shared secret safe.
- Log masking reduces accidental disclosure but cannot make printing a secret acceptable.
Related
secrets-management · secure-cd · variables-groups · subscription-connection · environment-approvals
📘 Sources: Microsoft Learn — Secure Key Vault · Secret variables in Azure Pipelines