Azure Key Vault Provider for Secrets Store CSI Driver

The Azure Key Vault provider for the Secrets Store CSI Driver enables Kubernetes pods to access secret contents stored in an Azure Key Vault. It uses the Secrets Store CSI driver interface to mount these secrets directly into pods as volumes.

Key Features

• CSI Inline Volume Mounting: Mounts secrets, keys, and certificates to pods using a CSI Inline volume.
• Multi-Object Volumes: Supports mounting multiple secrets store objects as a single volume.
• Multi-Provider Support: Multiple providers can run in the same cluster simultaneously.
• Pod Portability: Uses the SecretProviderClass Custom Resource Definition (CRD) to support pod portability.
• Cross-Platform: Supports both Linux and Windows containers.
• Kubernetes Secret Sync: Supports synchronizing mounted secrets with native Kubernetes Secrets.
• Auto Rotation: Supports automatic rotation of secrets.

To use the Azure Key Vault Provider, follow these high-level steps:

1. Configure Identity and Access: Set up the necessary role assignments and access policies in Azure to allow the driver to access your Key Vault.
2. Install the Provider: Deploy the provider to your cluster using Helm or YAML deployment files.
3. Configure Usage: Follow the usage guide and review supported configurations to set up your SecretProviderClass.

For a complete end-to-end example, refer to the standard walkthrough.

Use Azure Workload Identity to allow your Kubernetes pods to access Azure Key Vault without managing long-lived secrets. This method uses federated identity credentials between your Kubernetes Service Account and an Azure AD Application or User-Assigned Managed Identity.

Prerequisites

• AKS Cluster: Version 1.21+ with OIDC Issuer enabled.
• Secrets Store CSI Driver: v1.1.0 or higher.
• Azure Key Vault Provider: v1.1.0 or higher.
• Azure CLI: version 2.40.0 or higher.

Setup Steps

1. Create an Identity

Either create an Azure AD Application (Service Principal) or a User-Assigned Managed Identity:

Azure AD Application:

export APPLICATION_NAME="<your application name>"
az ad sp create-for-rbac --name "${APPLICATION_NAME}"
export APPLICATION_CLIENT_ID=$(az ad sp list --display-name ${APPLICATION_NAME} --query '[0].appId' -otsv)

User-Assigned Managed Identity:

export RESOURCE_GROUP=<resource group name>
export USER_ASSIGNED_IDENTITY_NAME="<your user-assigned managed identity name>"
az identity create -g ${RESOURCE_GROUP} -n ${USER_ASSIGNED_IDENTITY_NAME}
export USER_ASSIGNED_IDENTITY_CLIENT_ID=$(az identity show -g ${RESOURCE_GROUP} -n ${USER_ASSIGNED_IDENTITY_NAME} --query clientId -otsv)

2. Grant Key Vault Permissions

Assign the necessary permissions to the identity to access keys, secrets, or certificates:

# Replace $KEYVAULT_NAME and the identity ID with your values
az keyvault set-policy -n $KEYVAULT_NAME --key-permissions get --spn ${IDENTITY_CLIENT_ID}
az keyvault set-policy -n $KEYVAULT_NAME --secret-permissions get --spn ${IDENTITY_CLIENT_ID}
az keyvault set-policy -n $KEYVAULT_NAME --certificate-permissions get --spn ${IDENTITY_CLIENT_ID}

3. Establish Federated Identity Credential

First, retrieve your AKS OIDC issuer URL:

export SERVICE_ACCOUNT_ISSUER=$(az aks show --resource-group <resource_group> --name <cluster_name> --query "oidcIssuerProfile.issuerUrl" -otsv)

Then, create the federation based on your identity type:

For Azure AD Application:

export SERVICE_ACCOUNT_NAME=<name of the service account>
export SERVICE_ACCOUNT_NAMESPACE=<namespace of the service account>
export APPLICATION_OBJECT_ID="$(az ad app show --id ${APPLICATION_CLIENT_ID} --query id -otsv)"

cat <<EOF > params.json
{
  "name": "kubernetes-federated-credential",
  "issuer": "${SERVICE_ACCOUNT_ISSUER}",
  "subject": "system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}",
  "description": "Kubernetes service account federated credential",
  "audiences": [
    "api://AzureADTokenExchange"
  ]
}
EOF

az ad app federated-credential create --id "${APPLICATION_OBJECT_ID}" --parameters @params.json

For User-Assigned Managed Identity:

az identity federated-credential create \
  --name "kubernetes-federated-credential" \
  --identity-name "${USER_ASSIGNED_IDENTITY_NAME}" \
  --resource-group "${RESOURCE_GROUP}" \
  --issuer "${SERVICE_ACCOUNT_ISSUER}" \
  --subject "system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}"

4. Deploy SecretProviderClass

In your SecretProviderClass, set usePodIdentity: "false" and provide the clientID of your identity.

To use Identity Binding to access Azure Key Vault on AKS, follow these three main steps:

1. Create a managed identity and grant Key Vault access

Create a user-assigned managed identity and grant it get permissions for keys, secrets, and certificates in your Key Vault.

2. Create the identity binding and configure RBAC

Refer to the AKS identity binding documentation to:

1. Create an identity binding resource for your AKS cluster.
2. Create the required Kubernetes RBAC (ClusterRole and ClusterRoleBinding) to authorize your service account to use the managed identity.

3. Deploy SecretProviderClass and application

Configure your SecretProviderClass with useAzureTokenProxy: "true" and provide the clientID of your managed identity. Ensure your Pod uses a service account that has the RBAC configured in step 2.

Important Note for Manual Installations: If you are installing the Secrets Store CSI Driver using raw manifests instead of the Helm chart, you must ensure the CSIDriver resource includes api://AKSIdentityBinding in the tokenRequests field. The Helm chart includes this by default.

### 1. Create a managed identity and grant Key Vault access

```bash
export RESOURCE_GROUP=<resource group name>
export USER_ASSIGNED_IDENTITY_NAME="<your managed identity name>"
export KEYVAULT_NAME="<your key vault name>"

az identity create -g ${RESOURCE_GROUP} -n ${USER_ASSIGNED_IDENTITY_NAME}
export USER_ASSIGNED_IDENTITY_CLIENT_ID=$(az identity show -g ${RESOURCE_GROUP} -n ${USER_ASSIGNED_IDENTITY_NAME} --query clientId -otsv)

# Grant Key Vault access
az keyvault set-policy -n $KEYVAULT_NAME --key-permissions get --spn ${USER_ASSIGNED_IDENTITY_CLIENT_ID}
az keyvault set-policy -n $KEYVAULT_NAME --secret-permissions get --spn ${USER_ASSIGNED_IDENTITY_CLIENT_ID}
az keyvault set-policy -n $KEYVAULT_NAME --certificate-permissions get --spn ${USER_ASSIGNED_IDENTITY_CLIENT_ID}

To use TLS certificates with the NGINX Ingress Controller via the Azure Key Vault Provider, you must first generate a certificate and import it to Azure Key Vault in .pfx format.

1. Generate a self-signed certificate using OpenSSL.
2. Convert the certificate to PFX format.
3. Import the PFX to Azure Key Vault using the Azure CLI.

Note: When retrieving certificates and private keys from Azure Key Vault, you must use objectType: secret in your SecretProviderClass configuration.

# 1. Generate TLS Cert
export CERT_NAME=ingresscert
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
    -out ingress-tls.crt \
    -keyout ingress-tls.key \
    -subj "/CN=demo.test.com/O=ingress-tls"

# 2. Convert to PFX and Import to Azure Key Vault
export AKV_NAME="[YOUR AKV NAME]"
openssl pkcs12 -export -in ingress-tls.crt -inkey ingress-tls.key  -out $CERT_NAME.pfx
# (skip Password prompt)

az keyvault certificate import --vault-name $AKV_NAME -n $CERT_NAME -f $CERT_NAME.pfx