If you don't want to add a secret manually, the CSI driver will use the kubelet identity, which is a user-assigned managed identity created by AKS at cluster creation (unless you specified your own). This managed identity is primarily used by the kubelet to access Azure Container Registry (ACR), but it can also be used for authentication to Azure storage for persistent volume mounting.
To view the kubelet identity details:
az aks show --resource-group <your-resource-group> --name <your-cluster-name> --query "identityProfile.kubeletidentity"
You need to assign the correct role to the kubelet identity to allow it to retrieve storage access keys.
To assign the Storage Account Key Operator Service Role:
az role assignment create --assignee <kubelet-identity-client-id> --role "Storage Account Key Operator Service Role" --scope /subscriptions/<your-subscription-id>/resourceGroups/<storage-resource-group>/providers/Microsoft.Storage/storageAccounts/<your-storage-account>
Ensure that you do not have a secret named azure-storage-account-{accountname}-secret in the pod namespace and omit the nodeStageSecretRef field in the persistent volume configuration, because as the the azurefile-csi-driver doc says:
- if the nodeStageSecretRef field is not specified in the persistent volume (PV) configuration, the driver will attempt to retrieve the azure-storage-account-{accountname}-secret in the pod namespace.
- If azure-storage-account-{accountname}-secret in the pod namespace does not exist, the driver will use the kubelet identity to retrieve the account key directly from the Azure storage account API, provided that the kubelet identity has reader access to the storage account.
Additionally,I want to make clear that, when you create an AKS cluster, it sets up two managed identities by default: