Currently it supports two ways of managed identity to mount an Azure file:

1. Kubelet identity
2. Workload identity.

But those solution are not helpful for first party user, especially for cross-tenant scenario. This proposal aims to unblock such scenario by bring your own managed identity token.

• currently when using accessKey to mount azure file, we need to have a secret which contains property "azurestorageaccountname", "azurestorageaccountkey", we can introduce another property: "azurestoragemanagedidentitytoken".
  • Exactly one of "azurestoragemanagedidentitytoken" and "azurestorageaccountkey" must be set
  • If "azurestoragemanagedidentitytoken" is provided, csi drvier should try to use this token to do mounting. Otherwise use key to do mounting
• User is responsible to fresh the "azurestoragemanagedidentitytoken" in the secret, and the csi driver should list watch the secret and always use the latest token in the secret.
• After getting the token, the rest mounting logic should be the same as Workload identity.

Note: this proposal should only work for static provisioned Azure File.

sample usage:

volumes:
- csi:
    driver: file.csi.azure.com
    readOnly: false
    volumeAttributes:
      secretName: secret1
      shareName: share1

// secret
apiVersion: v1
data:
  azurestoragemanagedidentitytoken: xxx
  azurestorageaccountname: xxx
kind: Secret
metadata:
  name: secret1
  namespace: ns1
type: Opaque