Choosing Between the Azure Key Vault CSI Driver and External Secrets on AKS
Asked by
MellowPine47
I'm working with an AKS cluster and evaluating the best way to integrate Azure Key Vault for application secrets. The two approaches I'm considering are the Secrets Store CSI Driver and External Secrets Operator. The CSI Driver avoids storing secrets as Kubernetes objects, but mounting volumes and configuring references for each workload can add operational overhead. External Secrets is more convenient because it synchronizes values into native Kubernetes Secrets, although those secrets are then stored in etcd. For production workloads, how have you chosen between these options? Which trade-offs—security, workload identity, scalability, application changes, or operational simplicity—ended up mattering most?
Answers
A practical production pattern is to use Workload Identity and the Azure SDK whenever the application supports it. Use the CSI Driver for cases such as TLS certificates or third-party applications that need a file and cannot call Key Vault themselves. Use External Secrets when compatibility and ease of deployment are more important, but protect the resulting Kubernetes Secrets with strong RBAC and encryption at rest.
Reply to this answer
A managed identity can let workloads access Key Vault directly, but avoid assigning one broad identity to the entire cluster. Use workload-specific identities so a compromised pod cannot read every secret that the cluster identity can access. The downside is that direct SDK access requires application changes, so it may not work for third-party software that only understands files or environment variables.
Reply to this answer
The strongest default is usually Workload Identity with an identity bound to a specific Kubernetes service account. Grant that identity only the required Key Vault permissions, then let the application use the Azure SDK with DefaultAzureCredential. This avoids putting the secret into Kubernetes at all and gives you narrower access than a cluster-wide identity.
Reply to this answer
External Secrets isn’t automatically unsafe just because it creates Kubernetes Secrets. Kubernetes can encrypt Secret resources before storing them in etcd, including using a customer-managed key depending on the setup. The bigger concern is access control: anyone who can read Secrets or gain enough control over a pod may be able to retrieve them. Encrypting etcd and having strict RBAC are important if you choose this route.
Reply to this answer
Add your answer
Answers are reviewed before publication.
MellowPine47: That’s the main concern for me with direct SDK access: it improves the security model, but every application has to be updated to use the Azure authentication libraries.