Understanding Workload Identity in Kubernetes: A Comprehensive Guide with Examples for AKS, EKS, and GKE

In the world of container orchestration, Kubernetes has become our go-to standard. As we move our applications to Kubernetes, managing secure and scalable authentication and authorization becomes crucial. Workload Identity offers a powerful solution to this challenge by enabling Kubernetes Pods to authenticate with cloud services using native identity management systems. In this blog post, we’ll explore the concept of Workload Identity, why it’s important, the mechanisms behind it, and how we can implement it in AKS, EKS, and GKE.

Table of Contents

1. What is Workload Identity?

2. Why is Workload Identity Important?

3. Behind-the-Scenes Mechanisms

4. Workload Identity Implementation in AKS

5. Workload Identity Implementation in EKS

6. Workload Identity Implementation in GKE

7. Conclusion

What is Workload Identity?

Workload Identity is a mechanism in Kubernetes that lets our Pods authenticate to cloud services without manually managing service account credentials. It leverages cloud providers' identity and access management systems (IAM), making integration seamless and access secure.

Key Features of Workload Identity

• Credential Management: It automates the management and rotation of credentials, helping us reduce security risks.

• Scoped Access: This feature provides fine-grained access control by allowing our workloads to assume specific roles or identities.

• Native Integration: It works with cloud providers' IAM systems, ensuring we have a seamless experience.

Why is Workload Identity Important?

Security

• Reduced Risk of Credential Exposure: Workload Identity minimizes the risk of credential leakage by eliminating the need for static credentials.

• Automatic Credential Rotation: Cloud providers take care of the credential lifecycle, including rotation, which eases our operational burden.

Simplicity

• Easy Configuration: Workload Identity makes it simple for us to associate Kubernetes service accounts with cloud service accounts.

• Centralized Management: We can manage identity and access control policies centrally through cloud IAM systems.

Scalability

• Fine-Grained Access Control: This allows us to precisely control which cloud resources a workload can access.

• Supports Multi-Cluster Environments: It works seamlessly across multiple Kubernetes clusters and cloud accounts.

Behind-the-Scenes Mechanisms

Workload Identity involves several components and processes that help us securely and efficiently manage identity and access for our Kubernetes workloads. Let’s break down the behind-the-scenes mechanisms that are common across all cloud providers:

1. Kubernetes API Server and Service Accounts

• Service Accounts in Kubernetes: Every Pod in Kubernetes can be associated with a service account. This service account is what our Pod uses to authenticate with the Kubernetes API server.

• Annotations on Service Accounts: For Workload Identity, we annotate the Kubernetes service account (KSA) with information that links it to the cloud provider’s identity service. This annotation typically includes the identity or name of the cloud service account, like GCP’s Google Service Account, AWS’s IAM Role, or Azure’s Managed Identity.

2. Cloud Provider’s Identity Provider Integration

• Identity Mapping: Each cloud provider has its own way of mapping a Kubernetes service account to its identity service. This is done by recognizing the annotations on the KSA and translating them into a cloud-specific identity.

• OIDC (OpenID Connect): Most providers use OpenID Connect to federate identities between Kubernetes and the cloud provider. Kubernetes acts as the identity provider (IdP), issuing tokens that the cloud provider can validate.

3. Token Request and Token Projection

• Token Request API: Kubernetes has a Token Request API that our Pods can use to request a JSON Web Token (JWT) representing the service account. This JWT includes claims about the service account, namespace, and the audience (the intended recipient).

• Projected Service Account Token Volume: Kubernetes mounts the JWT token into the Pod using a projected volume. This token is periodically refreshed and includes the necessary claims that the cloud provider’s identity system needs to validate the request.

4. Identity Validation and Role Assumption

• Identity Validation: When our Pod makes a request to a cloud service, it presents the JWT token. The cloud provider’s service then validates this token against the configured OpenID Connect Provider, which in this case, is the Kubernetes API server.

• Role Assumption: Once the cloud provider validates the JWT token, it maps the token to the associated cloud service account—like a Google Service Account, AWS IAM Role, or Azure Managed Identity—and allows our Pod to assume the role specified in the annotations.

5. Access Control and Enforcement

• RBAC and IAM Policies: The cloud provider enforces specific IAM policies to restrict access so that our service account can only access the resources it’s allowed to. This fine-grained access control ensures that our Pod can only perform actions it’s explicitly permitted to.

• Controllers and Admission Webhooks: In some cases, Kubernetes uses admission webhooks and controllers to enforce the correct annotation and configuration of service accounts. These controllers check and make sure that the proper annotations are in place and that the JWT tokens are issued and projected correctly.

Workload Identity Implementation in AKS

Prerequisites

• Azure Kubernetes Service (AKS) cluster version 1.21 or later.

• Azure CLI installed and configured.

Step-by-Step Guide

• Step 1: Enable Azure AD Workload Identity

To enable Workload Identity, follow the Azure documentation to configure Azure AD Workload Identity for AKS.

• Step 2: Create an Azure AD Application and Service Principal

Create an Azure AD application and service principal to represent the identity of the workload.

az ad sp create-for-rbac --name "my-app" --skip-assignment

• Step 3: Create a Kubernetes Service Account

Create a Kubernetes Service Account (KSA) and annotate it with the Azure AD application's client ID.

kubectl create serviceaccount my-ksa --namespace my-namespace
kubectl annotate serviceaccount my-ksa \
    --namespace my-namespace \
    azure.workload.identity/client-id=APPLICATION_CLIENT_ID

• Step 4: Assign Permissions to the Service Principal

Assign the necessary permissions to the service principal in Azure.

az role assignment create --assignee <SERVICE_PRINCIPAL_ID> \
    --role <ROLE_NAME> \
    --scope <RESOURCE_SCOPE>

• Step 5: Deploy Pods Using the KSA

Deploy the application Pods using the annotated Kubernetes Service Account.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: my-ksa
  containers:
  - name: my-container
    image: my-image

Workload Identity Implementation in EKS

Prerequisites

• Amazon Elastic Kubernetes Service (EKS) cluster version 1.14 or later.

• AWS CLI installed and configured.

Step-by-Step Guide

• Step 1: Enable IAM Roles for Service Accounts (IRSA)

Enable IAM roles for service accounts in the EKS cluster by following the AWS documentation.

• Step 2: Create an IAM Role

Create an IAM role for the Kubernetes Service Account.

aws iam create-role --role-name my-role \
    --assume-role-policy-document file://trust-policy.json

Create a trust-policy.json file with the following content:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<ACCOUNT_ID>:oidc-provider/oidc.eks.<AWS_REGION>.amazonaws.com/id/<OIDC_ID>"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.<AWS_REGION>.amazonaws.com/id/<OIDC_ID>:sub": "system:serviceaccount:<NAMESPACE>:<KSA_NAME>"
        }
      }
    }
  ]
}

• Step 3: Create a Kubernetes Service Account

Create a Kubernetes Service Account and annotate it with the IAM role ARN.

kubectl create serviceaccount my-ksa --namespace my-namespace
kubectl annotate serviceaccount my-ksa \
    --namespace my-namespace \
    eks.amazonaws.com/role-arn=arn:aws:iam::<ACCOUNT_ID>:role/my-role

• Step 4: Deploy Pods Using the KSA

Deploy the application Pods using the annotated Kubernetes Service Account.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: my-ksa
  containers:
  - name: my-container
    image: my-image

Workload Identity Implementation in GKE

Prerequisites

• Google Kubernetes Engine (GKE) cluster version 1.12 or later.

• Google Cloud SDK installed and initialized.

Step-by-Step Guide

• Step 1: Enable Workload Identity

Enable Workload Identity for the GKE cluster.

gcloud container clusters update my-cluster \
    --workload-pool=project-id.svc.id.goog

• Step 2: Create a Kubernetes Service Account

Create a Kubernetes Service Account.

kubectl create serviceaccount my-ksa

• Step 3: Create a Google Service Account

Create a Google Service Account.

gcloud iam service-accounts create my-gsa \
    --display-name "My Google Service Account"

• Step 4: Grant the GSA Necessary Roles

Assign roles to the Google Service Account.

gcloud projects add-iam-policy-binding project-id \
    --member "serviceAccount:my-gsa@project-id.iam.gserviceaccount.com" \
    --role "roles/iam.serviceAccountUser"

• Step 5: Bind the KSA to the GSA

Bind the Kubernetes Service Account to the Google Service Account.

gcloud iam service-accounts add-iam-policy-binding \
    my-gsa@project-id.iam.gserviceaccount.com \
    --member "serviceAccount:project-id.svc.id.goog[namespace/my-ksa]" \
    --role "roles/iam.workloadIdentityUser"

• Step 6: Annotate the KSA

Annotate the Kubernetes Service Account to link it to the Google Service Account.

kubectl annotate serviceaccount my-ksa \
    --namespace namespace \
    iam.gke.io/gcp-service-account=my-gsa@project-id.iam.gserviceaccount.com

• Step 7: Deploy Pods Using the KSA

Deploy the application Pods using the annotated Kubernetes Service Account.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: my-ksa
  containers:
  - name: my-container
    image: my-image

Conclusion

Workload Identity is a crucial feature in Kubernetes that boosts security, simplifies credential management, and provides scalable access control for cloud resources. By integrating Kubernetes with cloud providers' IAM systems, Workload Identity eliminates the need for manual credential management and reduces the risk of credential leakage.

The behind-the-scenes mechanisms ensure that our workload's identity is verified and that only the intended cloud services are accessed, all while maintaining our application's security posture.

Whether we're using AKS, EKS, or GKE, implementing Workload Identity can significantly enhance the security and manageability of our Kubernetes deployments. Follow the steps outlined in this guide to set up Workload Identity in our Kubernetes environment and tap into the full potential of cloud-native identity management.