Azure Blob/File Storage as PVC: Support authorization via Workload Identities

[karlschriek]

Describe the solution you'd like

We use Azure AD Workload Identities extensively in order to authorize various services on our AKS clusters to interact with other Azure Services. We follow a zero-credential approach as far as possible and workload identities a pivotal part of making this possible.

(With workload identities you can federate an Azure AD Service Principal to a specific service account within a specific namespace, within a specific cluster. The cluster itself is acts as an OIDC provider and the service account acts as an identity associated with the cluster's OIDC provider. By federating the service principal authentication to this identity - and only that identity! - it is therefore possible for log in as that service principal without needing any credentials).

We would like to be able to also use this with PVCs that attach blob/file storage. Currently only storage account keys and SAS keys are supported.

For example, currently you would set up something like this (abbreviated):

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-blob
  namespace: my-namespace
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  ...
  csi:
    ...
    nodeStageSecretRef:
      name: azure-secret  # <--- credentials need to be stored in this secret

We would like to here instead attach a ServiceAccount to the PV provisioner and have it authenticate using the Workload Identity. For example by specifying:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-blob
  namespace: my-namespace
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  ...
  csi:
    ...
    nodeStageServiceAccount
      name: my-service-account

Describe alternatives you've considered

The only alternatives are to fetch storage account or SAS keys into a Secret on the Namespace where you want to register the PVC. Our interim solution is to store these keys in AKV and fetch them into the cluster using external-secrets. However, that still requires that the credentials to be nakedly exposed on the cluster itself. We want to be able to avoid this.

Additional context

Not directly relevant, but here are some issues on major open-source projects where we've contributed to the adoption of workload identities. Some of the discussions there might be of useful for context:

cert-manager (in order to enable interaction with Azure DNS Zones )

• https://github.com/cert-manager/cert-manager/issues/5085
• https://github.com/cert-manager/cert-manager/pull/5570

external-dns (in order to enable interaction with Azure DNS Zones )

• https://github.com/kubernetes-sigs/external-dns/issues/2724
• https://github.com/kubernetes-sigs/external-dns/pull/3111