Overview

Traditionally, when executing programs or applications on Virtual Machines (VMs) provided by cloud services, the cloud provider grants specified permissions to the VM. This setup allows the program running on the VM to access designated cloud resources without the need for password authentication. For instance, in Azure, binding a system-assigned or user-assigned managed identity to a VM enables the program running on the VM to operate as the managed identity, inheriting permissions associated with it.

We aim to replicate this user experience in Kubernetes, whereby a pod in a Kubernetes cluster (k8s) can be granted permissions without requiring the program within the pod to read any long-term credentials like passwords.

Previously, Azure Kubernetes Service (AKS) had introduced a feature known as Pod Identity to achieve this. However, this feature was deprecated before reaching General Availability (GA) as a more robust and widely accepted solution emerged.

The feature, Service Account Issuer Discovery, marked as stable starting from Kubernetes version v1.21, transforms the Kubernetes API server into an OIDC identity provider. This setup facilitates the issuance of tokens, via service accounts to pods, which are recognizable by external services outside the Kubernetes cluster, thereby establishing an authentication pathway between the pod within the cluster and external services including those on Azure, AWS, etc.

Both Azure AKS and AWS EKS have enabled this feature by default, offering convenient methods to configure the Kubernetes cluster OIDC Provider to integrate with their respective access control services, namely Microsoft Entra ID and AWS IAM. This feature is termed differently in their respective managed cluster documentation as follows:

• AKS: Workload Identity
• EKS: IAM roles for service accounts (IRSA)

Note: All Kubernetes clusters with the "Service Account Issuer Discovery" feature enabled can be integrated with cloud providers, not merely the managed clusters provided by cloud providers, albeit the setup may be slightly complex.

In this document, we will delve into the workings of this feature.

Service Account Issuer Discovery Flow

Assume we have a Kubernetes cluster, hosting applications purposed for reading and writing Azure Blobs.

Initially, the cluster administrator should activate the "Service Account Issuer Discovery" feature on the cluster. Following this, the cluster should be configured with the cloud provider, in this instance, Microsoft Entra ID, ensuring that Microsoft Entra ID is cognizant of the cluster's existence. In more precise terms, Microsoft Entra ID and the Kubernetes OIDC provider are federated, establishing a trust relationship.

Applications running in the cluster are assigned service accounts. (If not explicitly defined, a default service account is bound to every pod). Assigning a service account to a pod results in a JWT token being projected into the pod, stored on the pod’s disk.

Through different annotations on the service account, the cluster administrator can manipulate the claims within the token, thus, various service accounts can be endowed with different permissions.

The application can read the JWT token and forward it to the cloud access control service, in this scenario, Microsoft Entra ID. Upon receiving the token, Microsoft Entra ID validates it. Given the pre-established trust relationship with the Kubernetes cluster OIDC provider, it can ascertain the token’s validity.

Note: In this step, the cloud access control service may or may not access the Kubernetes API server, depending on whether the JWT token validation is a local or remote process.

Post validation, Microsoft Entra ID issues an access token to the application. The application can then utilize this token to access Azure Blobs or other cloud resources managed by Microsoft Entra ID.

References

• Use Microsoft Entra ID Workload Identity with Azure Kubernetes Service (AKS)
• Service Account Issuer Discovery
• IAM roles for service accounts (IRSA)