Workload Identity requires Access Keys on Azure Storage Account to be enabled

[mkemmerz]

Hello, I have some questions to the Workload Identity feature.

Currently trying out the blob-csi-driver 1.24.1 release together with an AKS 1.29.2. I am not using the microsoft managed blob-csi-driver.

I only got the Workload Identity for blobs running if my Azure Storage Account has access keys enabled. The blob-node pod would print out the following message:
clientID(xxx) is specified, use service account token to get account key

This is in the blob.go

// if client id is specified, we only use service account token to get account key
if clientID != "" {
	klog.V(2).Infof("clientID(%s) is specified, use service account token to get account key", clientID)
	if subsID == "" {
		subsID = d.cloud.SubscriptionID
	}
	accountKey, err := d.cloud.GetStorageAccesskeyFromServiceAccountToken(ctx, subsID, accountName, rgName, clientID, tenantID, serviceAccountToken)
	authEnv = append(authEnv, "AZURE_STORAGE_ACCESS_KEY="+accountKey)
	return rgName, accountName, accountKey, containerName, authEnv, err
}

Azure also shows the access in the Activity log:

The Service Account Token should be used to directly access the Storage Account resources I think.
The Workload Identity should allow to disable the access keys and only use RBAC for the Azure Storage Account.
Maybe I missed something here or my setup is not correct or is this intended behaviour?

[andyzhangx]

this driver would use workload identity to get access keys, if you don't want to use access keys, you could follow this example:
Mount an azure blob storage with a dedicated user-assigned managed identity, while this example dose not use workload identity

[itzikbekelmicrosoft]

this driver would use workload identity to get access keys, if you don't want to use access keys, you could follow this example: Mount an azure blob storage with a dedicated user-assigned managed identity, while this example dose not use workload identity

Not sure I understood, it should solve the mentioned issue? we have similar setup just like the example in your repository but we still see the MI is used for getting the Storage Key as mentioned by @mkemmerz

Could you please clarify? there is support to mount blob storage using fuse without storage key?

[andyzhangx]

if you use the example(https://github.com/qxsch/Azure-Aks/tree/master/aks-blobfuse-mi), it would always mount with managed identity auth instead of account key, the key part is AzureStorageAuthType: MSI

    volumeAttributes:
      protocol: fuse
      resourceGroup: aks-fuseblob-mi
      storageAccount: myaksblob
      containerName: mycontainer
      AzureStorageAuthType: MSI
      AzureStorageIdentityObjectID: "xxxxx-xxxx-xxx-xxx-xxxxxxx"

[rohayon]

@andyzhangx Thank you we followed the guide and successfully mount blobs. Thanks razo

[dvanrijnberk]

It is not recommended to use storage account keys according to Microsoft and policies within our company disallow it. How can we mount the blob storage without using the keys and with Workload Identity? Giving one whole node pool access to a storage account is also not that much of an option, right?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[maxarndt]

It is not recommended to use storage account keys according to Microsoft and policies within our company disallow it. How can we mount the blob storage without using the keys and with Workload Identity? Giving one whole node pool access to a storage account is also not that much of an option, right?

We have similar policies in our company. It would be great if there were a way to avoid using access keys and instead use a workload identity for authentication. For us, an inline/ephemeral CSI mount is particularly important.

Would be great to get some guidance on this issue!

/remove-lifecycle stale

[acortelyou]

@andyzhangx Can you prioritize adopting a "secure by default" stance for this csi driver? Microsoft policy requires that we disable access keys on our storage accounts. Workload Identity and MSI should be the golden path. No scenarios here actually require the use access keys given the available modern alternatives. Thanks.

[Vegoo89]

if you use the example(https://github.com/qxsch/Azure-Aks/tree/master/aks-blobfuse-mi), it would always mount with managed identity auth instead of account key, the key part is AzureStorageAuthType: MSI

    volumeAttributes:
      protocol: fuse
      resourceGroup: aks-fuseblob-mi
      storageAccount: myaksblob
      containerName: mycontainer
      AzureStorageAuthType: MSI
      AzureStorageIdentityObjectID: "xxxxx-xxxx-xxx-xxx-xxxxxxx"

Hey, this doesn't seem to work for me for inline volumes and static PV.

I am getting:

Error: failed to initialize new pipeline [config error in azstorage [account name not provided]]

However when I create secret with azurestorageaccountname (just name, no key) and reference to it via volumeAttibutes.secretName it works

I know this seems minor, but error is very unclear. For some reason storageAccount is not passed to the driver.

I am using 1.24.1 Blob CSI