(cache)Set up volumes accessing cross-tenant Azure Storage without account access keys in Azure Kubernetes Service

Sometimes, for security reasons, your organization may need to separate different resources into different tenants. In some extreme cases, the data you need to retrieve is provided by external providers and is beyond your control.
This article helps you access storage account in different tenants without using access keys.

For accessing Azure Storage without account access keys within same tenant, check out: Set up volumes using Azure Storage without account access keys in Azure Kubernetes Service
For accessing other Azure resources across different tenant, check out: Access cross-tenant resources via workload identity on Azure Kubernetes Service

Options#

Choose among the following options:

Use BlobFuse via workload identity to access Azure block blob container
Use NFS to access Azure block blob container/Azure fileshare

NOTE
In this article, we assume that Tenant 1 is where AKS is located and Tenant 2 is where the storage account is located.

Use BlobFuse via workload identity to access Azure block blob container#

In this section, we will use BlobFuse via workload identity to access Azure block blob container.
Before proceeding, ensure that:

Azure Blob storage CSI driver is enabled.
OIDC issuer feature and workload identity add-on is enabled.

NOTE
AKS version must be 1.34 or higher, or Azure Blob CSI driver version must be v1.27.1 or greater, to proceed with the steps in this section.

Preparation: variables set-up#

In this section, it is assumed that the below variables will be used:

1
# Assmuing AKS cluster is in Tenant 1 and Azure blob stroage is in Tenant 2
2
# Subscription 2 ID in Tenant 2 is required to be filled
3
tenant1=
4
tenant2=
5
subscription2=
6

7
# The application you want to create for cross-tenant access
8
app=
9

10
# AKS cluster name and resource group it locates in Tenant 1
11
rG1=
12
aks=
13

14
# Define Kubernetes resources service account and namespace name
15
# Both of them will be newly created in this article
16
# Example has been pre-filled here for convenience
17
namespace=blob-fuse
18
svc=blob-fuse-sa
19

20
# New stroage account name and new resource group/location in Tenant 2
21
# Both stroage account and resource group will be newly created in this section
22
# Container name has been pre-filled
23
location2=
24
rG2=
25
sa=
26
container=aks-container

The following parameters also need to be pre-defined, after enabling the workload identity add-on:

1
# Retrieve OIDC Issuer URI
2
oidcIssuer=$(az aks show -n ${aks} -g ${rG1} \
3
    --query oidcIssuerProfile.issuerUrl -o tsv)

Remember to get or switch kubeconfig:

1
az aks get-credentials -n ${aks} -g ${rG1}

Tenant 1: create app registration and federated identity credential#

1
az ad app create --display-name ${app} -o none \
2
    --sign-in-audience AzureADMultipleOrgs

Get client ID of the application with its object ID in Tenant 1

1
appClientId=$(az ad app list --display-name ${app} \
2
    --query '[0].appId' -o tsv)
3
appObjectId=$(az ad app show --id ${appClientId} \
4
    --query id -o tsv)

Create federated identity credential using defined parameters

Define parameters

1
fidcParams=$(cat <<EOF
2
{
3
  "name": "kubernetes-federated-credential",
4
  "issuer": "${oidcIssuer}",
5
  "subject": "system:serviceaccount:${namespace}:${svc}",
6
  "description": "Kubernetes service account federated credential for ${namespace}:${svc}",
7
  "audiences": [
8
    "api://AzureADTokenExchange"
9
  ]
10
}
11
EOF
12
)

Create federated identity credential

1
az ad app federated-credential create --id ${appObjectId} \
2
    --parameters "${fidcParams}" -o none

Tenant 2: storage account preparation and role assignment#

Log into Tenant 2

1
az login --tenant ${tenant2}

Create service principal for application as an enterprise application

1
az ad sp create --id ${appClientId} -o none
2

3
# This step is to make it shown as an "Enterprise Application"
4
az ad sp update --id ${appClientId} -o none \
5
    --set tags="['WindowsAzureActiveDirectoryIntegratedApp']"

Get object ID of service principal in Tenant 2

1
spObjectId=$(az ad sp show --id ${appClientId} \
2
    --query id -o tsv)

Create Azure block blob container in Tenant 2

1
az group create -n ${rG2} -l ${location2} -o none
2

3
az storage account create -n ${sa} -g ${rG2} \
4
    --kind StorageV2 -o none \
5
    --sku Standard_LRS \
6
    --allow-shared-key-access false
7

8
saId=$(az storage account show \
9
    -n ${sa} -g ${rG2} --query id -o tsv)
10

11
az rest --method PUT -o none \
12
    --url https://management.azure.com${saId}/blobServices/default/containers/${container}?api-version=2023-05-01 \
13
    --body "{}"

Grant permission to service principal in Tenant 2

1
az role assignment create --role "Storage Blob Data Contributor" \
2
    --assignee-object-id ${spObjectId} -o none \
3
    --scope ${saId}/blobServices/default/containers/${container} \
4
    --assignee-principal-type ServicePrincipal

Access storage account from your AKS cluster#

Create service account in AKS cluster

1
cat <<EOF | kubectl apply -f -
2
apiVersion: v1
3
kind: Namespace
4
metadata:
5
  name: ${namespace}
6
---
7
apiVersion: v1
8
kind: ServiceAccount
9
metadata:
10
  name: ${svc}
11
  namespace: ${namespace}
12
EOF

Randomize volumeHandle ID

1
volUniqId=${sa}#${container}#$(tr -dc a-zA-Z0-9 < /dev/urandom | head -c 4)

Deploying Kubernetes storage resources

1
cat <<EOF | kubectl apply -f -
2
kind: StorageClass
3
apiVersion: storage.k8s.io/v1
4
metadata:
5
  name: azureblob-fuse
6
provisioner: blob.csi.azure.com
7
parameters:
8
  skuName: Standard_LRS
9
reclaimPolicy: Delete
10
mountOptions:
9 collapsed lines
11
  - '-o allow_other'
12
  - '--file-cache-timeout-in-seconds=120'
13
  - '--use-attr-cache=true'
14
  - '--cancel-list-on-mount-seconds=10'
15
  - '-o attr_timeout=120'
16
  - '-o entry_timeout=120'
17
  - '-o negative_timeout=120'
18
  - '--log-level=LOG_WARNING'
19
  - '--cache-size-mb=1000'
20
allowVolumeExpansion: true
21
volumeBindingMode: Immediate
22
---
23
apiVersion: v1
24
kind: PersistentVolume
25
metadata:
26
  annotations:
27
    pv.kubernetes.io/provisioned-by: blob.csi.azure.com
28
  name: pv-blob-wi
29
spec:
9 collapsed lines
30
  capacity:
31
    storage: 10Gi
32
  accessModes:
33
    - ReadWriteMany
34
  persistentVolumeReclaimPolicy: Retain
35
  storageClassName: azureblob-fuse
36
  mountOptions:
37
    - -o allow_other
38
    - --file-cache-timeout-in-seconds=120
39
  csi:
40
    driver: blob.csi.azure.com
41
    volumeHandle: ${volUniqId}
42
    volumeAttributes:
43
      mountWithWorkloadIdentityToken: 'true'
44
      storageaccount: ${sa}
45
      containerName: ${container}
46
      clientID: ${appClientId}
47
      resourcegroup: ${rG2}
48
      tenantID: ${tenant2}
49
      subscriptionid: ${subscription2}
50
---
51
kind: PersistentVolumeClaim
52
apiVersion: v1
53
metadata:
54
  name: pvc-blob-wi
55
  namespace: ${namespace}
56
spec:
57
  accessModes:
58
    - ReadWriteMany
59
  resources:
60
    requests:
61
      storage: 10Gi
62
  volumeName: pv-blob-wi
63
  storageClassName: azureblob-fuse
64
EOF

Mount the block storage into Pod

1
cat <<EOF | kubectl apply -f -
2
apiVersion: v1
3
kind: Pod
4
metadata:
5
  name: blob-fuse-wi-mount
6
  namespace: ${namespace}
7
spec:
8
  serviceAccountName: ${svc}
9
  containers:
10
  - name: demo
11
    image: alpine
12
    command: ["/bin/sh"]
13
    args: ["-c", "while true; do cat /mnt/azure/text; sleep 5; done"]
14
    volumeMounts:
15
      - mountPath: /mnt/azure
16
        name: volume
17
        readOnly: false
18
  volumes:
19
   - name: volume
20
     persistentVolumeClaim:
21
       claimName: pvc-blob-wi
22
EOF

Write the message to a file and check if it works after the Pod starts

1
kubectl exec blob-fuse-wi-mount -n ${namespace} -- sh -c 'touch /mnt/azure/text; echo hello\! > /mnt/azure/text'

1
kubectl logs blob-fuse-wi-mount -n ${namespace}

Output:

1
cat: can't open '/mnt/azure/text': No such file or directory
2
hello!
3
hello!

Use NFS to access Azure fileshare#

In this section, we will use NFS to access Azure fileshare. The process is very similar to the single-tenant setup. However, instead of using VNet whitelisting, private link is now the only option.
Unless you must use Azure fileshare, this solution is not suitable for multi-tenant (more than 3) management as it increases the complexity of the network architecture.

TIP
No identity-based authentication is required when using NFS. The authentication itself is entirely network-based. This is by design.

Preparation: variables set-up#

In this section, it is assumed that the below variables will be used:

1
# Assmuing AKS cluster is in Tenant 1 and Azure stroage is in Tenant 2
2
tenant1=
3
tenant2=
4

5
# AKS cluster name and resource group it locates in Tenant 1
6
rG1=
7
aks=
8

9
# Define Kubernetes resources namespace name, it will be newly created in this section
10
# Example has been pre-filled here for convenience
11
namespace=fileshare-nfs
12

13
# New stroage account name and new resource group/location in Tenant 2
14
# Both stroage account and resource group will be newly created in this section
15
# Fileshare name has been pre-filled
16
location2=
17
rG2=
18
sa=
19
fileshare=aks-share

Remember to get or switch kubeconfig:

1
az aks get-credentials -n ${aks} -g ${rG1}

Tenant 2: storage account preparation and network configuration#

Log into Tenant 2

1
az login --tenant ${tenant2}

Prepare Azure storage account

To use NFS protocol to access Azure fileshare, you need to create Premium storage account:

1
az group create -n ${rG2} -l ${location2} -o none
2

3
# Secure transfer must be disabled to use NFS in Azure fileshare
4
az storage account create -n ${sa} -g ${rG2} \
5
--kind FileStorage -o none \
6
--sku Premium_LRS --default-action Deny \
7
--public-network-access Disabled \
8
--allow-shared-key-access false  \
9
--https-only false
10

11
saId=$(az storage account show \
12
-n ${sa} -g ${rG2} --query id -o tsv)
13

14
az rest --method PUT -o none \
15
--url https://management.azure.com${saId}/fileServices/default/shares/${fileshare}?api-version=2023-05-01 \
16
--body "{'properties':{'enabledProtocols':'NFS'}}"

Create private link
Connnection from private links are considered as whitelisted, and in cross-tenant scenario, this is the only solution to make it work.
To create private link, see also: Creating a private endpoint.
Add VNet Link to AKS VNet In step 3, a private DNS zone called “privatelink.file.core.windows.net” is created. Go into this private DNS zone, find the “Virtual Network Links” under “DNS management”. Then create a new link to the VNet in Tenant 1.
Enable auto registration is not needed for registeration.
Create VNet peering between AKS and storage account See also: Create a virtual network peering - Resource Manager, different subscriptions and Microsoft Entra tenants

Access storage account from your AKS cluster#

Randomize volumeHandle ID

1
volUniqId=${sa}#${container}#$(tr -dc a-zA-Z0-9 < /dev/urandom | head -c 4)

Deploying Kubernetes storage resources

1
cat <<EOF | kubectl apply -f -
2
kind: StorageClass
3
apiVersion: storage.k8s.io/v1
4
metadata:
5
  name: azurefile-premium-nfs
6
provisioner: file.csi.azure.com
7
parameters:
8
  protocol: nfs
9
  skuName: Premium_LRS
7 collapsed lines
10
reclaimPolicy: Delete
11
mountOptions:
12
  - nconnect=4  # Azure Linux node does not support nconnect option
13
  - noresvport
14
  - actimeo=30
15
allowVolumeExpansion: true
16
volumeBindingMode: Immediate
17
---
18
apiVersion: v1
19
kind: PersistentVolume
20
metadata:
21
  annotations:
22
    pv.kubernetes.io/provisioned-by: file.csi.azure.com
23
  name: pv-fileshare-nfs
24
spec:
10 collapsed lines
25
  capacity:
26
    storage: 10Gi
27
  accessModes:
28
    - ReadWriteMany
29
  persistentVolumeReclaimPolicy: Retain
30
  storageClassName: azurefile-premium-nfs
31
  mountOptions:
32
    - nconnect=4  # Azure Linux node does not support nconnect option
33
    - noresvport
34
    - actimeo=30
35
  csi:
36
    driver: file.csi.azure.com
37
    volumeHandle: ${volUniqId}
38
    volumeAttributes:
39
      storageAccount: ${sa}
40
      shareName: ${fileshare}
41
      storageEndpointSuffix: core.windows.net
42
      protocol: nfs
43
---
44
apiVersion: v1
45
kind: Namespace
46
metadata:
47
  name: ${namespace}
48
---
49
apiVersion: v1
50
kind: PersistentVolumeClaim
51
metadata:
52
  name: pvc-fileshare-nfs
53
  namespace: ${namespace}
54
spec:
55
  accessModes:
56
    - ReadWriteMany
57
  storageClassName: azurefile-premium-nfs
58
  volumeName: pv-fileshare-nfs
59
  resources:
60
    requests:
61
      storage: 5Gi
62
EOF

Mount the fileshare into Pod

1
cat <<EOF | kubectl apply -f -
2
apiVersion: v1
3
kind: Pod
4
metadata:
5
  name: fileshare-nfs-mount
6
  namespace: ${namespace}
7
spec:
8
  containers:
9
  - name: demo
10
    image: alpine
11
    command: ["/bin/sh"]
12
    args: ["-c", "while true; do cat /mnt/azure/text; sleep 5; done"]
13
    volumeMounts:
14
      - mountPath: /mnt/azure
15
        name: volume
16
        readOnly: false
17
  volumes:
18
   - name: volume
19
     persistentVolumeClaim:
20
       claimName: pvc-fileshare-nfs
21
EOF

Write the message to a file and check if it works after the Pod starts

1
kubectl exec fileshare-nfs-mount -n ${namespace} -- sh -c 'touch /mnt/azure/text; echo hello\! > /mnt/azure/text'

1
kubectl logs fileshare-nfs-mount -n ${namespace}

Output:

1
cat: can't open '/mnt/azure/text': No such file or directory
2
hello!

Use NFS to access Azure block blob container#

In this section, we will use NFS to access Azure block blob container. The whole process is identical to accessing Azure fileshare via NFS except the name, so I won’t go detail here.

Preparation: variables set-up#

In this section, it is assumed that the below variables will be used:

1
# Assmuing AKS cluster is in Tenant 1 and Azure stroage is in Tenant 2
2
tenant1=
3
tenant2=
4

5
# AKS cluster name and resource group it locates in Tenant 1
6
rG1=
7
aks=
8

9
# Define Kubernetes resources namespace name, it will be newly created in this section
10
# Example has been pre-filled here for convenience
11
namespace=blob-nfs
12

13
# New stroage account name and new resource group/location in Tenant 2
14
# Both stroage account and resource group will be newly created in this section
15
# container name has been pre-filled
16
location2=
17
rG2=
18
sa=
19
container=aks-container

Remember to get or switch kubeconfig:

1
az aks get-credentials -n ${aks} -g ${rG1}

Tenant 2: storage account preparation and network configuration#

Log into Tenant 2

1
az login --tenant ${tenant2}

Prepare Azure storage account

To use NFS protocol to access Azure fileshare, you need to create Premium storage account:

1
az group create -n ${rG2} -l ${location2} -o none
2

3
az storage account create -n ${sa} -g ${rG2} \
4
  --kind StorageV2 --sku Standard_LRS \
5
  --enable-hierarchical-namespace -o none \
6
  --allow-shared-key-access false \
7
  --enable-nfs-v3 --default-action Deny \
8
  --public-network-access Disabled
9

10
saId=$(az storage account show \
11
  -n ${sa} -g ${rG2} --query id -o tsv)
12

13
az rest --method PUT -o none \
14
  --url https://management.azure.com${saId}/blobServices/default/containers/${container}?api-version=2023-05-01 \
15
  --body "{}"

Create private link, add VNet Link to AKS VNet, and set up VNet peering

NOTE
As mentioned above, I won’t go into detail again. If you need explanation and instruction, check out “Use NFS to access Azure fileshare” in this article.

Access storage account from your AKS cluster#

Randomize volumeHandle ID

1
volUniqId=${sa}#${container}#$(tr -dc a-zA-Z0-9 < /dev/urandom | head -c 4)

Deploying Kubernetes storage resources

1
cat <<EOF | kubectl apply -f -
2
kind: StorageClass
3
apiVersion: storage.k8s.io/v1
4
metadata:
5
  name: azureblob-nfs
6
provisioner: blob.csi.azure.com
7
parameters:
8
  protocol: nfs
9
  skuName: Standard_LRS
5 collapsed lines
10
reclaimPolicy: Delete
11
mountOptions:
12
  - nconnect=4  # Azure Linux node does not support nconnect option
13
allowVolumeExpansion: true
14
volumeBindingMode: Immediate
15
---
16
apiVersion: v1
17
kind: PersistentVolume
18
metadata:
19
  annotations:
20
    pv.kubernetes.io/provisioned-by: blob.csi.azure.com
21
  name: pv-blob-nfs
22
spec:
8 collapsed lines
23
  capacity:
24
    storage: 10Gi
25
  accessModes:
26
    - ReadWriteMany
27
  persistentVolumeReclaimPolicy: Retain
28
  storageClassName: azureblob-nfs
29
  mountOptions:
30
    - nconnect=4  # Azure Linux node does not support nconnect option
31
  csi:
32
    driver: blob.csi.azure.com
33
    volumeHandle: ${volUniqId}
34
    volumeAttributes:
35
      storageAccount: ${sa}
36
      containerName: ${container}
37
      storageEndpointSuffix: core.windows.net
38
      protocol: nfs
39
---
40
apiVersion: v1
41
kind: Namespace
42
metadata:
43
  name: ${namespace}
44
---
45
apiVersion: v1
46
kind: PersistentVolumeClaim
47
metadata:
48
  name: pvc-blob-nfs
49
  namespace: ${namespace}
50
spec:
51
  accessModes:
52
    - ReadWriteMany
53
  storageClassName: azureblob-nfs
54
  volumeName: pv-blob-nfs
55
  resources:
56
    requests:
57
      storage: 5Gi
58
EOF

Mount the block storage into Pod

1
cat <<EOF | kubectl apply -f -
2
apiVersion: v1
3
kind: Pod
4
metadata:
5
  name: blob-nfs-mount
6
  namespace: ${namespace}
7
spec:
8
  containers:
9
  - name: demo
10
    image: alpine
11
    command: ["/bin/sh"]
12
    args: ["-c", "while true; do cat /mnt/azure/text; sleep 5; done"]
13
    volumeMounts:
14
      - mountPath: /mnt/azure
15
        name: volume
16
        readOnly: false
17
  volumes:
18
   - name: volume
19
     persistentVolumeClaim:
20
       claimName: pvc-blob-nfs
21
EOF

Write the message to a file and check if it works after the Pod starts

1
kubectl exec blob-nfs-mount -n ${namespace} -- sh -c 'touch /mnt/azure/text; echo hello\! > /mnt/azure/text'

1
kubectl logs blob-nfs-mount -n ${namespace}

Output:

1
cat: can't open '/mnt/azure/text': No such file or directory
2
hello!

Afterword#

I initially wrote this article in May 2025, but it was not published due to token refresh issue. After nearly 9 months, the bug has finally been fixed in managed AKS environment, so I can publish this article.
This feature became Generally Available (GA) on May 10, 2025, but the fix is only being deployed as of Feb 8, 2026.

I’m unsure how to comment on the Azure GA process. The bug has been present since the initial GA announcement, yet it took nine months to deploy a fix. Users can self-deploy version 1.27 of the CSI driver during these 9 monthes, but this option would render their AKS cluster unsupported, making it a poor choice overall.
Even though the feature is Generally Available (GA), feature testing is still necessary before deploying it to a production environment. In this case, if a user utilizes workload identity from a user-assigned managed identity, it can take 24 hours for the issue to become reproducible. This leads me to suspect that the developer may not have left the test AKS server idle for a full 24 hours during testing, which allowed this bug to be published in the GA version.

This situation serves as a reminder that a 2-hour test should be regarded as short-term and unstable; thus, extending the test duration as much as possible is crucial before deploying it into production.