Azure Key Vault secret store

In Kubernetes, you store the client secret or the certificate into the Kubernetes Secret Store and then refer to those in the YAML file. Before you start, you need the details of the Microsoft Entra ID application you created.

Using a client secret

1. Create a Kubernetes secret using the following command:

   kubectl create secret generic [your_k8s_secret_name] --from-literal=[your_k8s_secret_key]=[your_client_secret]
   

   • [your_client_secret] is the application’s client secret as generated above
   • [your_k8s_secret_name] is secret name in the Kubernetes secret store
   • [your_k8s_secret_key] is secret key in the Kubernetes secret store

2. Create an azurekeyvault.yaml component file.

   The component yaml refers to the Kubernetes secretstore using auth property and secretKeyRef refers to the client secret stored in the Kubernetes secret store.

   apiVersion: dapr.io/v1alpha1
   kind: Component
   metadata:
     name: azurekeyvault
   spec:
     type: secretstores.azure.keyvault
     version: v1
     metadata:
     - name: vaultName
       value: "[your_keyvault_name]"
     - name: azureTenantId
       value: "[your_tenant_id]"
     - name: azureClientId
       value: "[your_client_id]"
     - name: azureClientSecret
       secretKeyRef:
         name: "[your_k8s_secret_name]"
         key: "[your_k8s_secret_key]"
   auth:
     secretStore: kubernetes
   

3. Apply the azurekeyvault.yaml component:

   kubectl apply -f azurekeyvault.yaml
   

Using a certificate

1. Create a Kubernetes secret using the following command:

   kubectl create secret generic [your_k8s_secret_name] --from-file=[your_k8s_secret_key]=[pfx_certificate_file_fully_qualified_local_path]
   

   • [pfx_certificate_file_fully_qualified_local_path] is the path of PFX file you obtained earlier
   • [your_k8s_secret_name] is secret name in the Kubernetes secret store
   • [your_k8s_secret_key] is secret key in the Kubernetes secret store

2. Create an azurekeyvault.yaml component file.

   The component yaml refers to the Kubernetes secretstore using auth property and secretKeyRef refers to the certificate stored in the Kubernetes secret store.

   apiVersion: dapr.io/v1alpha1
   kind: Component
   metadata:
     name: azurekeyvault
   spec:
     type: secretstores.azure.keyvault
     version: v1
     metadata:
     - name: vaultName
       value: "[your_keyvault_name]"
     - name: azureTenantId
       value: "[your_tenant_id]"
     - name: azureClientId
       value: "[your_client_id]"
     - name: azureCertificate
       secretKeyRef:
         name: "[your_k8s_secret_name]"
         key: "[your_k8s_secret_key]"
   auth:
     secretStore: kubernetes
   

3. Apply the azurekeyvault.yaml component:

   kubectl apply -f azurekeyvault.yaml
   

Using Azure managed identity

1. Ensure your AKS cluster has managed identity enabled and follow the guide for using managed identities.

2. Create an azurekeyvault.yaml component file.

   The component yaml refers to a particular KeyVault name. The managed identity you will use in a later step must be given read access to this particular KeyVault instance.

   apiVersion: dapr.io/v1alpha1
   kind: Component
   metadata:
     name: azurekeyvault
   spec:
     type: secretstores.azure.keyvault
     version: v1
     metadata:
     - name: vaultName
       value: "[your_keyvault_name]"
   

3. Apply the azurekeyvault.yaml component:

   kubectl apply -f azurekeyvault.yaml
   

4. Create and assign a managed identity at the pod-level via either:

   • Microsoft Entra ID workload identity (preferred method)
   • Microsoft Entra ID pod identity

   Important: While both Microsoft Entra ID pod identity and workload identity are in preview, currently Microsoft Entra ID Workload Identity is planned for general availability (stable state).

5. After creating a workload identity, give it read permissions:

   • On your desired KeyVault instance
   • In your application deployment. Inject the pod identity both:
     • Via a label annotation
     • By specifying the Kubernetes service account associated with the desired workload identity

   apiVersion: v1
   kind: Pod
   metadata:
     name: mydaprdemoapp
     labels:
       aadpodidbinding: $POD_IDENTITY_NAME
   

Using Azure managed identity directly vs. via Microsoft Entra ID workload identity

When using managed identity directly, you can have multiple identities associated with an app, requiring azureClientId to specify which identity should be used.

However, when using managed identity via Microsoft Entra ID workload identity, azureClientId is not necessary and has no effect. The Azure identity to be used is inferred from the service account tied to an Azure identity via the Azure federated identity.