No More Hardcoded Secrets: Azure Key Vault + AKS kubernetes Done Right
Real-World Approaches for Securely Consuming Azure Key Vault Secrets in AKS: File Mount vs Environment Variable Injection
1. Problem Statement :
Most teams start by hardcoding secrets database passwords, API keys directly into Kubernetes YAML as environment variables. These files are versioned in Git, passed around, and often end up on developer laptops. Every person who can view the YAML can see every secret, in plain text. It’s a compliance and security nightmare. Even “Kubernetes secrets” aren’t much better they’re just base64, not encrypted at rest unless you explicitly configure it, and still live in etcd where anyone with cluster admin can see them.
What problem do these methods solve?
Method 1 (Mount as files): The app never sees secrets in environment variables. Secrets are pulled just-in-time from Azure Key Vault and mounted inside the pod as files. The secret exists only in memory, not in YAML, not in Git, not in etcd.
Method 2 (Inject as env vars): For apps that must consume secrets as environment variables, you can still avoid hardcoding. Key Vault secrets are synced as native Kubernetes secrets, and then referenced as env vars. At no point is the real value ever exposed in your codebase or manifests.
In both cases, you remove hardcoded secrets entirely from code, YAML, and Git, and you get full control, rotation, and auditing via Key Vault.
2. Why We Need This Use Case
Why do we need both methods?
Some apps expect secrets as files (classic .pem, .crt, .json configs), others need them as environment variables. A modern platform team needs a secure, automated way to deliver both without ever hardcoding or storing secrets in version control.
What do these two approaches demonstrate?
How to connect AKS to Azure Key Vault securely with managed identity (no passwords, no service principals).
How to mount secrets directly as files using the CSI Secrets Store Driver most secure for apps that can read files.
How to inject secrets as environment variables, by syncing them from Key Vault to Kubernetes secrets, and referencing in pod specs ideal for legacy apps.
End-to-end Infrastructure-as-Code with Terraform and YAML, so the pattern is repeatable and auditable.
Both methods cover almost every real-world need for consuming secrets in Kubernetes, the right way.
3. When We Need This Use Case
You need this pattern when:
You have any secret that shouldn’t live in your code repo or be managed manually
You must support both apps that read from files and those that expect environment variables
You want to rotate secrets instantly, across all pods, with a single change in Key Vault
You need a “zero trust” posture nothing in the cluster should trust static credentials
You’re working in regulated environments where auditability and RBAC matter