Secure Access to Azure Services using Workload Identity for Azure AKS¶
Although Azure Kubernetes Service (AKS) allows you to deploy containerized workloads in a managed Kubernetes environment, developers still need to deal with the challenge of securely managing access to Azure resources (e.g. Key Vault or Azure Storage). Traditionally, secrets like API keys or service account credentials are used to authenticate and authorize workloads, but this approach presents security risks and operational overhead.
In Azure for AKS clusters, developers have access to something similar called Workload Identity. It is a modern, secure, and scalable way to manage access without the hassle of managing secrets. In this blog post, we'll dive deep into what Workload Identity is, how it works in AKS, and why it's a game-changer for Kubernetes clusters on Azure.
Note
In a related blog, we will see how users can achieve something similar in Amazon EKS clusters using EKS Pod Identity.
What is Workload Identity?¶
Workload Identity is a feature that allows applications running on AKS clusters to access Azure resources using managed identities from Azure Active Directory (AAD). It eliminates the need for application developers to handle sensitive secrets like connection strings or API keys.
Instead of relying on secrets, Workload Identity leverages Azure's native managed identities to authenticate workloads. It allows each pod or workload to assume an identity, making it possible to securely access Azure services such as Azure Key Vault, Blob Storage, or Cosmos DB.
How Does Workload Identity Work in AKS?¶
Workload Identity in AKS is built on the integration of AAD Pod Identity and Managed Identity in Azure. Here’s a step-by-step look at how it works.
1. Cluster Setup and Identity Binding¶
When you deploy an AKS cluster, you associate it with an Azure Active Directory tenant. The AKS cluster can then use the specified AAD tenant to manage identities.
Each Kubernetes pod or workload can be assigned a specific Azure Managed Identity. These managed identities are tied to specific roles and permissions in Azure, meaning each workload gets access only to the resources it needs.
2. Kubernetes Pod Requests¶
When a pod running in AKS needs to access an Azure resource (e.g. read secrets from Key Vault), it doesn't have to supply any credentials like API keys or passwords. Instead, the pod makes a request to the Azure Instance Metadata Service (IMDS) to obtain an access token.
3. Token Issuance via AAD¶
The Azure Instance Metadata Service interacts with Azure Active Directory to verify that the pod has the required permissions. If the pod’s managed identity is authorized to access the requested resource, Azure AD issues an OAuth 2.0 access token.
4. Accessing Azure Resources¶
With the token in hand, the pod can now make authorized API calls to the specific Azure service (Key Vault, Storage, Cosmos DB, etc.). The token is valid for a limited time and automatically refreshed, which further enhances security and reduces the need for manual intervention.
Here’s a simplified workflow: - A Kubernetes pod requests access to an Azure resource. - The pod retrieves a token from Azure’s Instance Metadata Service (IMDS). - Azure Active Directory verifies the pod’s managed identity and issues a token. - The pod uses this token to securely access Azure resources.
Role-Based Access Control (RBAC)¶
Permissions for workloads are governed by Role-Based Access Control (RBAC) in Azure. This ensures that each managed identity has the minimum necessary privileges to perform its operations. For example, a workload needing read-only access to secrets in Azure Key Vault can be assigned that specific permission, and nothing more.
Benefits of Workload Identity¶
The benefits of Workload Identity are significant especially over manually managing secrets etc. Some of the critical ones are described below:
1. No More Secrets¶
Workload Identity eliminates the need to store secrets in Kubernetes or manage them via third-party secret management tools. By using Azure-managed identities, all secret management is handled natively and securely.
2. Improved Security Posture¶
Traditional approaches involve storing secrets in environment variables or Kubernetes secrets, which can be vulnerable to attacks if not properly secured. Workload Identity significantly reduces this risk by leveraging short-lived access tokens that are automatically refreshed and issued on-demand.
3. Granular Access Control¶
Each workload or pod can be assigned its own identity, ensuring that each application gets access only to the resources it needs. This reduces the chances of privilege escalation within the cluster.
4. Simplified Management¶
There’s no need for developers to worry about storing or rotating credentials. Managed identities and Azure Active Directory handle these aspects automatically. This streamlines both development and operations, reducing potential human error and administrative overhead.
5. Seamless Integration with Azure Services¶
Workload Identity integrates seamlessly with Azure’s ecosystem. Whether you’re interacting with Azure Key Vault to fetch secrets, Blob Storage to handle files, or Cosmos DB for database operations, Workload Identity makes secure access to these services smooth and efficient.
Conclusion¶
Workload Identity is a powerful feature that simplifies identity management and strengthens security in AKS clusters. By removing the need for secrets and leveraging Azure-managed identities, it helps reduce operational overhead, mitigates security risks, and offers granular control over how workloads access Azure resources. If you're managing Kubernetes workloads on AKS, adopting Workload Identity should be a top priority in your security strategy.
With Workload Identity, you can focus more on building your applications, knowing that Azure has your identity management and access control needs covered. In a follow up part for this blog to this, my colleague will describe how customers can use Workload Identity with Rafay using the integrated GitOps approach.
Thanks to readers of our blog who spend time reading our product blogs. Please Contact the Rafay Product Team if you would like us to write about other topics.