In preview: Azure Key Vault secrets provider extension for Arc enabled Kubernetes clusters

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.

Do you use a cloud provider managed secrets store solution or store your application secrets locally on a Kubernetes cluster? Be it a database connection string, TLS certificate used for ingress controller or any encryption/decryption key, what triggers this decision is more often than not a security vulnerability or at-scale consumption demand. Hence, enterprises are slowly moving away from using Kubernetes secrets and rather storing them centrally in a secrets management solution like Azure Key Vault (AKV). This allows enterprise level usage for all your Kubernetes clusters hosted in any cloud or on-prem.


We are happy to announce the public preview of a Microsoft managed service that lets you use AKV as secrets management solution for Azure Arc enabled Kubernetes cluster. Azure Key Vault secrets provider is now available as an extension in public preview. This extension allows you to get secret contents stored in an Azure Key Vault instance and uses the Secrets Store CSI driver interface to mount them into Kubernetes pods of your Azure Arc enabled Kubernetes clusters, thereby reducing the exposure of secrets to the minimum. 


How does this work?

CSI driver Interface.png


The extension is installed by a cluster admin. This deploys Secrets Store CSI driver and AKV secrets provider as daemon sets. The application teams then create their namespace-scoped custom resource SecretProviderClass, referencing the AKV instance and its contents. Further, the application teams reference this SecretProviderClass object in application pod manifests.


On application pod start and restart, the Secrets Store CSI driver communicates with the Azure Key Vault secrets provider using gRPC to retrieve the secret content from the Azure Key Vault specified in the SecretProviderClass custom resource. Then the volume is mounted in the pod as tmpfs and the secret contents are written to the volume. On pod delete, the corresponding volume is cleaned up and deleted.


What do you get during public preview?

  • Support for both single tenant and multi-tenant clusters: Once the extension is deployed by the cluster admin, the application teams can specify which Azure Key Vault and what secrets their applications need access to and scope their access down to their namespaces. This is done with the help of a namespace-scoped custom resource SecretProviderClass. You would require only one installation of the AKV secrets provider extension to achieve both single tenancy and multi-tenancy.
  • Service Principal based authentication for Azure Key Vault: While defining the application pod on Kubernetes cluster, you will reference a Kubernetes secret, encasing the information of a service principal created in Azure that has GET permissions to the required AKV instance. Referencing the service principal at the workload level ensures that the fetched secrets are available only to the workload. While managed identity is not an option today for authentication, it is on the roadmap for the next phase of this extension release.

Additional configuration options

The extension allows for 3 configuration options:

  1. Secret Rotation - Periodically update the pod mount with the latest secret from the AKV secrets store
  2. Rotation Poll Interval - Frequency of the pod mount update if Secret Rotation configuration is enabled
  3. Sync as Kubernetes secret - Create Kubernetes secret(s) to mirror the mounted content

Try it out

The fastest way to see it in action is by following the Azure Arc Jumpstart scenario that uses Cluster API as an Arc connected Kubernetes cluster. This scenario automates creation of the SecretProviderClass object and a sample workload to fetch the secret stored in an AKV instance. You can further use your own AKV instance and try it out on your own for POC.


Check out the full documentation to get more information on the installation and the configuration of this capability. By the next month, we will also enable quick installation through 'Extensions' blade of your Arc connected cluster. This will enable one click install of the extension with its default configuration. 

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.