Azure Workload Identity and AKS Integration Guide

Azure Workload Identity is a game-changer for managing identities in Azure Kubernetes Service (AKS). It eliminates the need for service principals and allows your pods to authenticate directly to Azure Active Directory (AAD).

This integration is seamless and secure, enabling your applications to access Azure resources without the need for credentials. Azure Workload Identity integrates with AKS by using a Kubernetes Service Account to authenticate to Azure Active Directory.

With Azure Workload Identity, you can manage identities at scale and reduce the complexity of identity management in your AKS clusters. This is particularly useful in large-scale deployments where identity management can become overwhelming.

Azure Workload Identity is an Azure Managed Identity that federates a workload in Kubernetes, providing all the advantages of a managed identity, especially managed credentials and security.

It eliminates the need to store credentials in code or configuration files, reducing the risk of exposure.

Azure Workload Identity utilizes Azure Managed Identities, which automatically handle token issuance and renewal without manual intervention.

There are different methods for accessing Key Vaults, and Azure Workload Identity is one of them, as demonstrated in the AKS Identities for KeyVault sample.

Here are the different scenarios for accessing Key Vaults, categorized by their Key Scenario:

Azure Workload Identity offers enhanced security, simplified identity management, seamless integration, improved scalability and flexibility, cost efficiency, compliance and auditing, streamlined development, and resilience and reliability.

To set up Azure Workload Identity, you'll need an Azure AD tenant with permissions to create applications and managed identities. This allows you to create the necessary components for workload identity.

Enable OIDC Issuer in AKS by following the initial step, which is to ensure the AKS cluster has the OIDC issuer enabled. This is a crucial first step in the setup process.

Install Azure Workload Identity Components by deploying them in the AKS cluster. This will provide the necessary components for workload identity to function properly.

Here are the key steps to follow in setting up Azure Workload Identity:

Before diving into the setup process, let's make sure we have the necessary prerequisites in place. You'll need to own an Azure keyvault or be able to create one in the same tenant as the managed identity.

To manage the Kubernetes cluster, it's essential to have DevOps rights. This will allow you to make the necessary changes and configurations.

Here's a quick rundown of what you'll need to get started:

To set up Azure Workload Identity in AKS, you'll need an Azure AD tenant with permissions to create applications and managed identities. This is the foundation for the entire process.

First, ensure your AKS cluster has the OIDC issuer enabled. This is a crucial step that must be completed initially.

Next, deploy the Azure Workload Identity components in the AKS cluster. This will enable the necessary functionality for the workload identity.

Create an Azure AD application and managed identity for the workload. This will provide the necessary credentials for the workload identity to access Azure resources.

To link the Azure AD application with the Kubernetes service account, you'll need to configure the federated identity credential. This is a critical step that ties the workload identity to the Kubernetes service account.

You'll also need to annotate the Kubernetes service account with the Azure Workload Identity information. This will provide the necessary metadata for the workload identity to function correctly.

Finally, assign the necessary Azure RBAC roles to the managed identity to access the required Azure resources. This will grant the workload identity the necessary permissions to perform its tasks.

Here's a summary of the setup steps:

To use workload identity, you need to add the label azure.workload.identity/use: "true" to the pod spec. This label is required in the pod template spec, and only pods with this label are mutated by the azure-workload-identity mutating admission webhook.

The label azure.workload.identity/use: "true" is required for pods that need to use workload identity. If the label is not added, the pods will fail after they are restarted.

You can also use annotations to configure the service account token expiration, skip containers, and inject a proxy sidecar into the pod. For example, you can set the annotation azure.workload.identity/service-account-token-expiration to 3600 seconds to prevent downtime caused by errors during service account token refresh.

Here's a summary of the annotations you can use:

Service accounts in Kubernetes can have multiple identities, and Microsoft Entra Workload ID supports one-to-one, many-to-one, and one-to-many mappings. This means a service account can reference a single Microsoft Entra object, multiple service accounts can reference the same Microsoft Entra object, or a service account can reference multiple Microsoft Entra objects.

If the service account annotations are updated, you must restart the pod for the changes to take effect. This is because the annotations are used to configure the behavior of the service account.

A service account can be thought of as an Azure security principal, but it's part of the core Kubernetes API, not a Custom Resource Definition (CRD). Service account annotations can be used to configure the behavior of the service account when exchanging the service account token for a Microsoft Entra access token.

Here are some available labels and annotations that can be used to configure the behavior of the service account:

Pod annotations can also be used to configure the behavior of the pod. The annotation azure.workload.identity/service-account-token-expiration can be used to represent the expirationSeconds field for the projected service account token. The default value for this annotation is 3600, and the supported range is 3600-86400.

You can use the annotation azure.workload.identity/skip-containers to represent a semi-colon-separated list of containers to skip adding projected service account token volume. For example, container1;container2. The default value for this annotation is to add the projected service account token volume to all containers if the pod is labeled with azure.workload.identity/use: true.

Service accounts and pod identities are two concepts that are often confused with each other, but they serve different purposes. A service account is a special type of account that represents a non-human entity such as an application, API, or other service.

There are three types of service accounts native to Azure Active Directory: Managed identities, service principals, and user-based service accounts. Service accounts are not deprecated, unlike pod identities.

Pod identity, on the other hand, is a deprecated concept that was used to bind an Azure managed identity with a Kubernetes workload. It's been replaced by workload identity.

Here's a comparison between service accounts and pod identities:

Workload identity, which has replaced pod identity, integrates with Kubernetes capabilities to federate with external identity providers. It's a managed identity that federates a workload in Kubernetes.