Edit

Share via

Kubernetes workload identity and access

Microsoft Entra ID
Azure Kubernetes Service (AKS)

This article describes how Amazon Elastic Kubernetes Service (Amazon EKS) and Azure Kubernetes Service (AKS) provide identity for Kubernetes workloads to access cloud platform services. For a detailed comparison of Amazon Web Services (AWS) Identity and Access Management (IAM) and Microsoft Entra ID, see:

This guide explains how AKS clusters, built-in services, and add-ons use managed identities to access Azure resources like load balancers and managed disks. The article also demonstrates how to use Microsoft Entra Workload ID so AKS workloads can access Azure resources without needing a connection string, access key, or user credentials.

Note

This article is part of a series of articles that helps professionals who are familiar with Amazon EKS to understand Azure Kubernetes Service (AKS).

Amazon EKS Identity and Access Management

Amazon EKS has two native options to call AWS services from within a Kubernetes pod: IAM roles for service accounts, and Amazon EKS service-linked roles.

IAM roles for service accounts associate IAM roles with a Kubernetes service account. This service account provides AWS permissions to the containers in any pod that uses the service account. IAM roles for service accounts provide the following benefits:

  • Least privilege: You don't need to provide extended permissions to the node IAM role for pods on that node to call AWS APIs. You can scope IAM permissions to a service account, and only pods that use that service account have access to those permissions. This feature also eliminates the need for third-party solutions such as kiam or kube2iam.

  • Credential isolation: A container can only retrieve credentials for the IAM role associated with the service account that it belongs to. A container never has access to credentials for another container that belongs to another pod.

  • Auditability: Amazon CloudTrail provides access and event logging to help ensure retrospective auditing.

Amazon EKS service-linked roles are unique IAM roles that are linked directly to Amazon EKS. Service-linked roles are predefined by Amazon EKS and include all the permissions required to call other AWS services on behalf of the role. For the Amazon EKS node IAM role, the Amazon EKS node kubelet daemon calls AWS APIs on behalf of the node. Nodes get permissions for these API calls from an IAM instance profile and associated policies.

AKS cluster managed identities

An AKS cluster requires an identity to access Azure resources like load balancers and managed disks. This identity can be either a managed identity or a service principal. By default, creating an AKS cluster automatically creates a system-assigned managed identity. The Azure platform manages the identity, and you don't need to provision or rotate any secrets. For more information about Microsoft Entra managed identities, see Managed identities for Azure resources.

AKS doesn't create a service principal automatically, so if you want to use a service principal, you must create it. The service principal eventually expires, and you must renew it to keep the cluster working. Managing service principals adds complexity, so it's easier to use managed identities.

Managed identities are essentially wrappers around service principals that simplify management. The same permission requirements apply both to service principals and managed identities. Managed identities use certificate-based authentication. Each managed identities credential has an expiration of 90 days and is rotated after 45 days.

AKS uses both system-assigned and user-assigned managed identity types, and these identities are immutable. When you create or use an AKS virtual network, attached Azure disk, static IP address, route table, or user-assigned kubelet identity with resources outside the node resource group, the Azure CLI adds the role assignment automatically.

If you use another method to create the AKS cluster, such as a Bicep template, Azure Resource Manager template, or Terraform module, you need to use the principal ID of the cluster managed identity to do a role assignment. The AKS cluster identity must have at least Network Contributor role on the subnet within your virtual network. To define a custom role instead of using the built-in Network Contributor role, you need the following permissions:

  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read

When the cluster identity needs to access an existing resource, for example when you deploy an AKS cluster to an existing virtual network, you should use a user-assigned managed identity. If you use a system-assigned control plane identity, the resource provider can't get its principal ID before it creates the cluster, so it's impossible to create the proper role assignments before cluster provisioning.

Summary of managed identities

AKS uses the following user-assigned managed identities for built-in services and add-ons.

Identity Name Use case Default permissions Bring your own identity
Control plane AKS Cluster Name Manages cluster resources including ingress load balancers and AKS-managed public IPs, cluster autoscaler, and Azure Disk and Azure file CSI drivers Contributor role for node resource group Supported
Kubelet AKS Cluster Name-agentpool Authenticates with Azure Container Registry NA (for Kubernetes v1.15+) Supported
Add-on HTTPApplicationRouting Manages required network resources Reader role for node resource group, Contributor role for DNS zone No
Add-on Ingress application gateway Manages required network resources Contributor role for node resource group No
Add-on omsagent Send AKS metrics to Azure Monitor Monitoring Metrics Publisher role No
Add-on Virtual-Node (ACIConnector) Manages required network resources for Azure Container Instances Contributor role for node resource group No

For more information, see Use a managed identity in Azure Kubernetes Service.

Microsoft Entra Workload ID for Kubernetes

Kubernetes workloads require Microsoft Entra application credentials to access Microsoft Entra protected resources, such as Azure Key Vault and Microsoft Graph. A common challenge for developers is managing secrets and credentials to secure communication between different components of a solution.

Microsoft Entra Workload ID for Kubernetes eliminates the need to manage credentials to access cloud services like Azure Cosmos DB, Azure Key Vault, or Azure Blob Storage. An AKS-hosted workload application can use Microsoft Entra Workload ID to access an Azure managed service by using a Microsoft Entra security token, instead of explicit credentials like a connection string, username and password, or primary key.

As shown in the following diagram, the Kubernetes cluster becomes a security token issuer that issues tokens to Kubernetes service accounts. You can configure these tokens to be trusted on Microsoft Entra applications. The tokens can then be exchanged for Microsoft Entra access tokens by using the Azure Identity SDKs or the Microsoft Authentication Library (MSAL).

Diagram showing a simplified workflow for a pod managed identity in Azure.

  1. The kubelet agent projects a service account token to the workload at a configurable file path.
  2. The Kubernetes workload sends the projected, signed service account token to Microsoft Entra ID and requests an access token.
  3. Microsoft Entra ID uses an OIDC discovery document to check trust on the user-defined managed identity or registered application and validate the incoming token.
  4. Microsoft Entra ID issues a security access token.
  5. The Kubernetes workload accesses Azure resources by using the Microsoft Entra access token.

Microsoft Entra Workload ID federation for Kubernetes is currently supported only for Microsoft Entra applications, but the same model could potentially extend to Azure managed identities.

For more information, automation, and documentation for Microsoft Entra Workload ID, see:

Example workload

The example workload runs a frontend and a backend service on an AKS cluster. The workload services use Microsoft Entra Workload ID to access the following Azure services by using Microsoft Entra security tokens:

  • Azure Key Vault
  • Azure Cosmos DB
  • Azure Storage account
  • Azure Service Bus namespace

Prerequisites

  1. Set up an AKS cluster with the OIDC issuer enabled.
  2. Install the mutating admission webhook.
  3. Create a Kubernetes service account for the workloads.
  4. Create a Microsoft Entra application as shown in the quickstart.
  5. Assign roles with the right permissions to the needed Microsoft Entra registered applications.
  6. Establish a federated identity credential between the Microsoft Entra application and the service account issuer and subject.
  7. Deploy the workload application to the AKS cluster.

Microsoft Entra Workload ID message flow

AKS applications get security tokens for their service account from the OIDC issuer of the AKS cluster. Microsoft Entra Workload ID exchanges the security tokens with security tokens issued by Microsoft Entra ID, and the applications use the Microsoft Entra ID-issued security tokens to access Azure resources.

The following diagram shows how the frontend and backend applications acquire Microsoft Entra security tokens to use Azure platform as a service (PaaS) services.

Diagram showing an example application that uses Microsoft Entra Workload ID.

Download a Visio file of this architecture.

  1. Kubernetes issues a token to the pod when it's scheduled on a node, based on the pod or deployment spec.
  2. The pod sends the OIDC-issued token to Microsoft Entra ID to request a Microsoft Entra token for the specific appId and resource.
  3. Microsoft Entra ID checks the trust on the application and validates the incoming token.
  4. Microsoft Entra ID issues a security token: {sub: appId, aud: requested-audience}.
  5. The pod uses the Microsoft Entra token to access the target Azure resource.

To use Microsoft Entra Workload ID end-to-end in a Kubernetes cluster:

  1. You configure the AKS cluster to issue tokens and publish an OIDC discovery document to allow validation of these tokens.
  2. You configure the Microsoft Entra applications to trust the Kubernetes tokens.
  3. Developers configure their deployments to use the Kubernetes service accounts to get Kubernetes tokens.
  4. Microsoft Entra Workload ID exchanges the Kubernetes tokens for Microsoft Entra tokens.
  5. AKS cluster workloads use the Microsoft Entra tokens to access protected resources such as Microsoft Graph.

Contributors

This article is maintained by Microsoft. It was originally written by the following contributors.

Principal authors:

Other contributors:

To see non-public LinkedIn profiles, sign in to LinkedIn.

Next steps