How to Access Azure Resources from Amazon EKS Passwordlessly Using OIDC and Workload Identity Federation

Managing static credentials, API keys, or database passwords across different cloud providers is a security nightmare. If you run your workloads in Amazon Elastic Kubernetes Service (EKS) but need to read files from Azure Blob Storage or fetch data from Azure Databases, you don’t need to generate a single Azure client secret.

Instead, you can use your Amazon EKS cluster’s native OIDC identity provider to establish a secure, passwordless trust relationship directly with Microsoft Entra ID (Azure AD).

In this guide, we will step through how to connect an Amazon EKS Pod to an Azure Storage Account and an Azure SQL Database using Microsoft Entra Workload Identity Federation.

The Architecture Overview

Instead of storing a static secret inside Kubernetes, the authentication flow leverages temporary tokens:

1. Your EKS Pod generates a signed Kubernetes Service Account token (JWT).
2. The Pod sends this token directly to Microsoft Entra ID.
3. Entra ID verifies the token against your EKS OIDC public endpoint.
4. If valid, Entra ID issues a short-lived Azure Access Token to the Pod.
5. The Pod uses this token to authenticate against Azure RBAC resources.

[ EKS Pod ] ──(1) Sends EKS JWT Token ───────────────────────────> [ Microsoft Entra ID ]
    │                                                                   │
    │                                                            (2) Validates JWT 
    │                                                            via EKS OIDC URL
    │                                                                   │
    │ <──(3) Exchanges for Azure Access Token ──────────────────────────┘
    │
    └──(4) Actions API call (e.g. Read Key Vault) ──────────────────> [ Azure RBAC Resource ]

Prerequisites

Before starting, ensure you have the following installed and configured:

• AWS CLI and Azure CLI (az) authenticated to your accounts.
• kubectl connected to your Amazon EKS cluster (Kubernetes v1.21+).
• An existing Azure Resource Group where your target storage or database resides.

Step 1: Extract Your Amazon EKS OIDC Issuer URL

Every modern EKS cluster hosts its own public OpenID Connect discovery endpoint. Run the following command to retrieve yours:

# Set your EKS Cluster Name
CLUSTER_NAME="my-eks-cluster"

# Fetch the OIDC Issuer URL
EKS_OIDC_URL=$(aws eks describe-cluster --name "$CLUSTER_NAME" --query "cluster.identity.oidc.issuer" --output text)
echo "Your EKS Issuer URL is: $EKS_OIDC_URL"

Save this output URL (e.g., https://amazonaws.com). We will give this directly to Azure.

Step 2: Create a User-Assigned Managed Identity in Azure

Next, we create an identity inside Azure that will represent our Kubernetes application.

# Variables
RESOURCE_GROUP="my-azure-resource-group"
LOCATION="eastus"
IDENTITY_NAME="eks-azure-storage-db-accessor"

# Create the Managed Identity
az identity create \
  --resource-group "$RESOURCE_GROUP" \
  --name "$IDENTITY_NAME" \
  --location "$LOCATION"

# Extract critical IDs for later use
CLIENT_ID=$(az identity show --resource-group "$RESOURCE_GROUP" --name "$IDENTITY_NAME" --query "clientId" --output text)
TENANT_ID=$(az identity show --resource-group "$RESOURCE_GROUP" --name "$IDENTITY_NAME" --query "tenantId" --output text)

echo "AZURE_CLIENT_ID: $CLIENT_ID"
echo "AZURE_TENANT_ID: $TENANT_ID"

Step 3: Grant Azure RBAC Permissions

Now, let’s give our newly created Azure Identity permissions to access our Storage Account or Database.

Option A: For Azure Blob Storage

To give your EKS Pod permissions to read and write files to an Azure Storage Blob container:

# Replace with your actual Storage Account name
STORAGE_ACCOUNT_NAME="myazurestorageaccount"

# Fetch the resource ID of the storage account
STORAGE_ID=$(az storage account show --name "$STORAGE_ACCOUNT_NAME" --resource-group "$RESOURCE_GROUP" --query "id" --output text)

# Assign "Storage Blob Data Contributor" role
az role assignment create \
  --assignee "$CLIENT_ID" \
  --role "Storage Blob Data Contributor" \
  --scope "$STORAGE_ID"

Option B: For Azure SQL Database

For databases, you map the Managed Identity directly to a database user inside your SQL Server instance:

1. Connect to your Azure SQL Database using your admin tool.
2. Run the following SQL query to map the identity:

CREATE USER [eks-azure-storage-db-accessor] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [eks-azure-storage-db-accessor];
ALTER ROLE db_datawriter ADD MEMBER [eks-azure-storage-db-accessor];

Step 4: Configure the Workload Identity Federation Trust

This is the magic link. We must explicitly tell Azure to trust tokens coming from a specific Kubernetes namespace and service account inside our EKS cluster.

# Define your Kubernetes targets
K8S_NAMESPACE="production"
K8S_SERVICE_ACCOUNT="azure-accessor-sa"
FED_CRED_NAME="eks-to-azure-trust"

# Establish the federation trust policy
az identity federated-credential create \
  --resource-group "$RESOURCE_GROUP" \
  --identity-name "$IDENTITY_NAME" \
  --name "$FED_CRED_NAME" \
  --issuer "$EKS_OIDC_URL" \
  --subject "system:serviceaccount:${K8S_NAMESPACE}:${K8S_SERVICE_ACCOUNT}" \
  --audience "api://AzureADTokenExchange"

Step 5: Deploy the Manifests to Amazon EKS

Since EKS doesn’t have a built-in mutating webhook for Azure identities natively, we project the OIDC token file manually inside our deployment manifest.

Save the following file as eks-azure-deployment.yaml. Make sure to swap out your AZURE_CLIENT_ID and AZURE_TENANT_ID values gathered from Step 2.

apiVersion: v1
kind: Namespace
metadata:
  name: production
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: azure-accessor-sa
  namespace: production
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: azure-data-app
  namespace: production
spec:
  replicas: 1
  selector:
    matchLabels:
      app: azure-data-app
  template:
    metadata:
      labels:
        app: azure-data-app
    spec:
      serviceAccountName: azure-accessor-sa
      containers:
      - name: application
        image: python:3.11-slim
        command: ["sleep", "infinity"] # Keeping it open for testing
        env:
        - name: AZURE_CLIENT_ID
          value: "YOUR_AZURE_CLIENT_ID_HERE"
        - name: AZURE_TENANT_ID
          value: "YOUR_AZURE_TENANT_ID_HERE"
        - name: AZURE_FEDERATED_TOKEN_FILE
          value: /var/run/secrets/azure/tokens/azure-identity-token
        # App specific variables
        - name: AZURE_STORAGE_ACCOUNT_URL
          value: "https://windows.net"
        volumeMounts:
        - name: azure-token
          mountPath: /var/run/secrets/azure/tokens
          readOnly: true
      volumes:
      - name: azure-token
        projected:
          sources:
          - serviceAccountToken:
              audience: api://AzureADTokenExchange
              expirationSeconds: 3600
              path: azure-identity-token

Apply it to your cluster:

kubectl apply -f eks-azure-deployment.yaml

Step 6: Verify the Connection (Application Implementation)

The official Microsoft Azure SDK libraries natively look for the AZURE_FEDERATED_TOKEN_FILE environment variable. If they find it, they exchange the EKS token for an Azure token automatically.

Here is a short Python example showing how easy it is to list blobs from your EKS container without writing a single line of password authentication logic:

import os
from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient

def main():
    # 1. Initialize the Default Azure Credential
    # This automatically finds your EKS token file and authenticates seamlessly.
    credential = DefaultAzureCredential()

    account_url = os.environ["AZURE_STORAGE_ACCOUNT_URL"]

    # 2. Connect to the Azure Storage Blob Service
    blob_service_client = BlobServiceClient(account_url, credential=credential)

    print("Successfully authenticated to Azure using EKS OIDC!")

    # 3. List containers to verify RBAC access
    containers = blob_service_client.list_containers()
    print("Found Azure Blob Containers:")
    for container in containers:
        print(f" - {container.name}")
if __name__ == "__main__":
    main()

Conclusion

By configuring Microsoft Entra Workload Identity Federation with Amazon EKS, you eliminate the risk of exposed long-lived credentials. Security teams can rest easy knowing that permissions are strictly managed using fine-grained Azure RBAC roles tied directly to ephemeral Kubernetes Service Accounts.