Getting started with AKS Workload Identities

Azure Kubernetes Service (AKS) offers a powerful feature called Workload Identity, which enhances security and simplifies authentication for applications running in Kubernetes clusters. Here’s an overview of how Workload Identities work in the context of AKS:

Workload Identity in AKS allows pods to authenticate against Azure resources without using secrets or credentials stored within the cluster. Instead, it leverages Entra ID(Azure AD) and OpenID Connect (OIDC) to provide a more secure and manageable authentication mechanism

Problems Solved by AKS Workload Identities

Azure Workload Identities solve several critical problems in cloud authentication and security, particularly in the context of Azure Kubernetes Service (AKS). Here are the key issues addressed by workload identities:

1. Simplified Credential Management:
   By leveraging Azure Active Directory (Azure AD) and OpenID Connect (OIDC), workload identities simplify the process of credential management. Developers no longer need to manually manage, rotate, or store secrets, reducing administrative overhead and potential human errors.
2. Enhanced Security:
   Workload identities provide a more secure authentication mechanism by using short-lived tokens instead of long-lived secrets. This approach minimizes the window of opportunity for potential attackers if credentials are compromised.
3. Seamless Integration with Azure Services:
   Workload identities integrate smoothly with existing Azure services and can be easily incorporated into CI/CD pipelines, making them ideal for modern cloud-native architectures.
4. Scalability:
   Workload identities are designed to scale effectively in complex, multi-service architectures common in Kubernetes environments, providing a more manageable approach to identity and access management for cloud-native applications.
5. Transition from Legacy Systems:
   Workload identities offer a path for organizations to move away from older, less secure authentication methods, such as the now-deprecated Pod Identity in AKS.

How Workload identities work

Here’s how it works:

1. Enable OIDC Issuer: When creating or updating an AKS cluster, you need to enable the OIDC issuer. This is done using the --enable-oidc-issuer and --enable-workload-identity flags when using Azure CLI.
2. Create a Managed Identity: You’ll need to create a user-assigned managed identity in Azure that your application will use to access Azure resources.
3. Configure Service Account: In your Kubernetes cluster, create a service account and annotate it with the client ID of the managed identity.
4. Set Up Pod Configuration: Configure your pod to use the service account and add the necessary label azure.workload.identity/use: "true" to enable Workload Identity.
5. Authenticate and use: Update your application to use Azure SDK libraries that support Workload Identity authentication. The latest version of Azure CLI also supports authentication using workload identities.

Step-by-Step Demo: Implementing Workload Identity in AKS

Prerequisites:

• Azure CLI installed and logged in
• kubectl installed and configured
• An existing AKS cluster (version 1.22 or higher)

Step 1: Enable OIDC Issuer on AKS Cluster

First, enable the OpenID Connect (OIDC) issuer on your AKS cluster to allow workload identity authentication.

az aks update -g aks-workload-identity-rg-01 -n my-aks-cluster-01 \ 
--enable-oidc-issuer --enable-workload-identity

You can check the status using below command.

az aks show -g aks-workload-identity-rg-01 -n my-aks-cluster-01 \
 --query "[oidcIssuerProfile, securityProfile]"

Retrieve the OIDC issuer URL:

export AKS_OIDC_ISSUER="$(az aks show -g aks-workload-identity-rg-01 \
 -n my-aks-cluster-01 --query "oidcIssuerProfile.issuerUrl" -otsv)"

Step 2: Create a user assigned managed identity

Create a user-assigned managed identity that your workload will use to access Azure resources and export its CLIENT_ID

az identity create --name aks-user-assigned-ma \ 
--resource-group aks-workload-identity-rg-01 --location westus2

export USER_ASSIGNED_CLIENT_ID="$(az identity show \
--name aks-user-assigned-ma --resource-group aks-workload-identity-rg-01 --query 'clientId' -otsv)"

Step 3: Create Kubernetes Service Account

Create a Kubernetes service account and annotate it with the managed identity’s client ID. Create a file named service-account.yaml:

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    azure.workload.identity/client-id: "5cee0ff9-0208-4555-93b8-b37eb6f239a9" #Update with your client_id
  name: "workload-identity-sa"
  namespace: "default"

Make sure you are authenticated to AKS cluster before running kubectl commands.

Step 4: Create Entra ID Federated Identity Credential

Create a federated identity credential to establish trust between Entra ID and the Kubernetes service account.

export SERVICE_ACCOUNT_NAMESPACE="default"
export SERVICE_ACCOUNT_NAME="workload-identity-sa"

az identity federated-credential create --name aks-user-assigned-ma-fed-identity \
--identity-name aks-user-assigned-ma --resource-group aks-workload-identity-rg-01 \
--issuer "${AKS_OIDC_ISSUER}" --subject system:serviceaccount:"${SERVICE_ACCOUNT_NAMESPACE}":"${SERVICE_ACCOUNT_NAME}" \
--audience api://AzureADTokenExchange

Step 6: Create a Pod with Workload Identity

Deploy a pod that uses the service account configured for workload identity. Create a file named azure-cli.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: azure-cli-workload-identity
  namespace: default
  labels:
    azure.workload.identity/use: "true"  # Required. Only pods with this label can use workload identity.
spec:
  serviceAccountName: workload-identity-sa
  containers:
    - image: mcr.microsoft.com/azure-cli
      name: azure-cli
      command: ["sleep"]
      args: ["3600"]

Step 7: Inspect Workload Identity Environment Variables

After setting up the workload identity and deploying the pod, we can inspect the environment variables that are automatically injected into the pod. These variables are crucial for the workload identity authentication process.

kubectl exec -it azure-cli-workload-identity -- /bin/bash

These environment variables are crucial for the workload identity authentication process:

• AZURE_TENANT_ID: The Azure Active Directory tenant ID associated with the workload identity.
• AZURE_FEDERATED_TOKEN_FILE: The path to the file containing the federated token used for authentication.
• AZURE_AUTHORITY_HOST: The Azure AD authority host URL used for authentication.
• AZURE_CLIENT_ID: The client ID of the managed identity associated with the workload.

These variables are automatically injected into the pod by the workload identity system, allowing applications to authenticate seamlessly without needing to manage credentials directly. The presence of these variables confirms that the workload identity is correctly configured for the pod.

Step 8: Add Role Assignment and Test Authentication/Authorization

Lets add a Reader role assignment to the managed identity and test Azure CLI authentication.

az role assignment create --assignee $USER_ASSIGNED_CLIENT_ID --role Reader \
 --scope /subscriptions/xxxx-xxxx-xxxx

Lets login to the pod and authenticate to Azure using Azure CLI. You can use az login --federated-token to authenticate using workload identity.

az login --federated-token "$(cat $AZURE_FEDERATED_TOKEN_FILE)" \
--service-principal -u $AZURE_CLIENT_ID -t $AZURE_TENANT_ID

Voila !! we are logged in, lets run an az cli command:

Conclusion

By adopting workload identities, organizations can significantly reduce the risk of credential leaks, simplify their secret management processes, and improve their overall security posture. As cloud-native architectures continue to evolve, technologies like workload identities will play a crucial role in maintaining secure and efficient operations.

You can also leverage these identities to host your CI/CD runners on AKS clusters. Instead of hosting a GitLab runner or Jenkins agent on a VM to support your GitOps deployments, you can host these runners on AKS with workload identities assigned. This approach allows you to utilize your AKS environment for such use cases, eliminating the need to allocate a full VM for these tasks.

Throughout this blog post, we’ve explored the concept of workload identities, their benefits, and how they address critical security challenges in Kubernetes environments. We’ve also provided a comprehensive, step-by-step demo that guides you through the process of enabling and implementing workload identities in AKS. I hope this was informative.