Edit

Share via

Kubernetes workload identity and access

  • Article

This article describes how Amazon Elastic Kubernetes Service (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 the following resources:

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. It also demonstrates how to use Microsoft Entra Workload ID so that 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 understand Azure Kubernetes Service (AKS).

Amazon EKS identity and access management

Amazon EKS provides native options to manage identity and access within Kubernetes pods. These options include IAM roles for service accounts and Amazon EKS service-linked roles.

IAM roles for service accounts

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

  • Least privilege: You can assign specific IAM permissions to a service account, which ensures that only the pods that use that service account have access to those permissions. This configuration eliminates the need to grant extended permissions to the node IAM role for all pods on a node. This approach provides enhanced security and granular control and eliminates the need for partner solutions, like kube2iam. For more information, see IAM roles for service accounts.

  • Credential isolation: Each container within a pod can only retrieve the credentials for the IAM role that's associated with its respective service account. This isolation ensures that a container can't access credentials that belong to another container in a different pod.

  • Auditability: Amazon EKS uses AWS CloudTrail to provide access and event logging, which facilitates retrospective auditing and compliance.

For more information, see IAM roles for service accounts.

Amazon EKS service-linked roles

Amazon EKS service-linked roles are unique IAM roles that directly link to Amazon EKS. These predefined roles include the necessary permissions to call AWS services on behalf of the associated role. The main service-linked role for Amazon EKS is the Amazon EKS node IAM role.

The Amazon EKS node kubelet daemon uses the Amazon EKS node IAM role to make API calls to AWS services on behalf of the node. The IAM instance profile and associated policies provide permissions for these API calls. This setup simplifies the management of IAM roles for nodes within the EKS cluster.

For more information, see Use service-linked roles for Amazon EKS.

More information about identity and access management

In addition to IAM roles for service accounts and Amazon EKS service-linked roles, other essential aspects of managing identity and access in Amazon EKS include:

  • Amazon EKS RBAC authorization: Amazon EKS supports role-based access control (RBAC). Use this feature to define fine-grained permissions for Kubernetes resources within your cluster.

  • AWS IAM: IAM provides a comprehensive identity management solution for AWS services, including EKS. Use IAM to create and manage users, groups, and roles to control access to your EKS resources.

  • Amazon EKS security groups: Use Amazon EKS to apply security group rules to pods that run within your cluster. Use this feature to control inbound and outbound traffic.

For more information, see What is Amazon EKS?.

AKS cluster managed identities

AKS clusters require a Microsoft Entra identity to access Azure resources, like load balancers and managed disks. We recommend that you use managed identities for Azure resources to authorize access from an AKS cluster to other Azure services.

Managed identity types

Developers often struggle with the management of secrets, credentials, certificates, and keys that help secure communication between services. Managed identities eliminate the need for you to manage these credentials. You can use managed identities to authenticate your AKS cluster without managing credentials or including them in your code. Assign an Azure RBAC role to an identity to grant the identity permissions to specific resources in Azure.

Two types of managed identities include:

  • System-assigned. You can use some Azure resources, such as virtual machines, to enable a managed identity directly on the resource. When you enable a system-assigned managed identity:

    • A special type of service principal is created in Microsoft Entra ID for the identity. The service principal is tied to the lifecycle of that Azure resource. When the Azure resource is deleted, Azure automatically deletes the service principal.

    • Only that Azure resource can use the identity to request tokens from Microsoft Entra ID.

    • You authorize the managed identity to have access to one or more services.

    • The name of the system-assigned service principal is the same as the name of the Azure resource that it's created for.

  • User-assigned. You might create a managed identity as a standalone Azure resource. You can create a user-assigned managed identity and assign it to one or more Azure resources. When you enable a user-assigned managed identity:

    • A special type of service principal is created in Microsoft Entra ID for the identity. The service principal is managed separately from the resources that use it.

    • Multiple resources can use it.

    • You authorize the managed identity to have access to one or more services.

You can use either type of managed identity to authorize access to Azure resources from your AKS cluster.

For more information, see Managed identity types.

Managed identities in AKS

You can use the following types of managed identities with an AKS cluster:

  • A system-assigned managed identity is associated with a single Azure resource, such as an AKS cluster. It exists for the lifecycle of the cluster only.

  • A user-assigned managed identity is a standalone Azure resource that you can use to authorize access to other Azure services from your AKS cluster. It persists separately from the cluster and multiple Azure resources can use it.

  • A precreated kubelet managed identity is an optional user-assigned identity that the kubelet can use to access other resources in Azure. If no user-assigned managed identity is specified for the kubelet, AKS creates a user-assigned kubelet identity in the node resource group.

Configure managed identities for AKS clusters

When you deploy an AKS cluster, a system-assigned managed identity is automatically created. You can also create the cluster with a user-assigned managed identity. The cluster uses the managed identity to request tokens from Microsoft Entra ID. The tokens authorize access to other resources that run in Azure.

When you assign an Azure RBAC role to the managed identity, you can grant your cluster permissions to access specific resources. For example, you can assign the managed identity an Azure RBAC role that allows it to access secrets in an Azure key vault. Use this approach to easily authorize access to your cluster without managing credentials.

Benefits and management of managed identities in AKS

When you use managed identities in AKS, you don't need to provision or rotate secrets. Azure manages the identity's credentials. Therefore, you can authorize access from your applications without managing any extra secrets.

If you already have an AKS cluster that uses a managed identity, you can update the cluster to a different type of managed identity. However, this update might introduce a delay while the control plane components switch to the new identity. This process can take several hours. During this time, the control plane components continue to use the old identity until its token expires.

Types of managed identities in AKS

AKS uses different types of managed identities to enable various built-in services and add-ons.

Managed identity Use case Default permissions
Control plane (system-assigned) AKS control plane components use this identity to manage cluster resources. These resources include ingress load balancers, AKS-managed public IP addresses, the cluster autoscaler, and Azure disk, file, and blob CSI drivers. Contributor role for the node resource group
Kubelet (user-assigned) Authenticate with Azure Container Registry. N/A (for Kubernetes version 1.15 and later)
Add-on identities (AzureNPM, AzureCNI network monitoring, Azure Policy, and Calico) These add-ons don't require an identity. N/A
Application routing Manages Azure DNS and Azure Key Vault certificates. Key Vault Secrets User role for Key Vault, DNS Zone Contributor role for DNS zones, Private DNS Zone Contributor role for private DNS zones
Ingress application gateway Manages required network resources. Contributor role for the node resource group
Operations Management Suite (OMS) agent Sends AKS metrics to Azure Monitor. Monitoring Metrics Publisher role
Virtual node (Azure Container Instances connector) Manages required network resources for Container Instances. Contributor role for the node resource group
Cost analysis Gathers cost allocation data. N/A
Workload identity (Workload ID) Enables applications to securely access cloud resources with Workload ID. N/A

For more information, see Use a managed identity in AKS.

Workload ID for Kubernetes

Workload ID integrates with Kubernetes to enable AKS cluster-deployed workloads to access Microsoft Entra protected resources, such as Key Vault and Microsoft Graph. Workload ID uses Kubernetes-native capabilities to federate with external identity providers. For more information, see Use Workload ID with AKS.

To use Workload ID, configure a service account within Kubernetes. Pods use this service account to authenticate and access Azure resources securely. Workload ID works well with Azure identity services client libraries or the Microsoft Authentication Library collection. You must register the application in Microsoft Entra ID to manage permissions and access control for the identities.

To fully employ Workload ID in a Kubernetes cluster, configure the AKS cluster to issue tokens and publish an OpenID Connect (OIDC) discovery document for token validation. For more information, see Create an OIDC provider on AKS.

You also need to configure the Microsoft Entra applications to trust the Kubernetes tokens. Developers can then configure their deployments to use Kubernetes service accounts to obtain tokens. Workload ID exchanges the tokens for Microsoft Entra tokens. AKS cluster workloads can use these Microsoft Entra tokens to securely access protected resources in Azure.

The following diagram shows how a 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 via the Azure identity services SDKs or the Microsoft Authentication Library.

Diagram that shows 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 verify 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 via the Microsoft Entra access token.

For more information about Workload ID, see the following resources:

Example workload

The following example workload runs on an AKS cluster and consists of a front-end and a back-end service. These services use Workload ID to access Azure services, including Key Vault, Azure Cosmos DB, Azure Storage accounts, and Azure Service Bus namespaces. To set up this example workload, do the following prerequisites:

  1. Set up an AKS cluster that has the OIDC issuer and workload identity enabled.

  2. Create a Kubernetes service account in the workload namespace.

  3. Create a Microsoft Entra user-assigned managed identity or registered application.

  4. Establish a federated identity credential between the Microsoft Entra managed identity or registered application and the workload service account.

  5. Assign the necessary roles with appropriate permissions to the Microsoft Entra managed identity or registered application.

  6. Deploy the workload and verify authentication with the workload identity.

Workload ID message flow

In this example workload, the front-end and back-end applications acquire Microsoft Entra security tokens to access Azure platform as a service (PaaS) solutions. The following diagram shows the message flow.

Diagram that shows an example application that uses Workload ID.

Download a Visio file of this architecture.

  1. Kubernetes issues a token to the pod when the pod is scheduled on a node. This token is based on the pod or deployment specifications.

  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 verifies 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 Workload ID end-to-end in a Kubernetes cluster:

  1. Configure the AKS cluster to issue tokens and publish an OIDC discovery document to allow validation of these tokens.

  2. 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. 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

Microsoft maintains this article. The following contributors wrote this article.

Principal authors:

Other contributors:

To see nonpublic LinkedIn profiles, sign in to LinkedIn.

Next steps