Azure Kubernetes Service (AKS) Service Identity

Introduction to Service Identity in AKS

In Kubernetes, workloads often need to authenticate and authorize access to external resources, such as Azure Key Vault, Azure SQL Database, or other Azure services. Service identity provides a secure and manageable way for your AKS applications to obtain credentials without embedding secrets directly in your application code or Kubernetes manifests.

AKS supports two primary mechanisms for managing service identities:

• Service Principals: A traditional identity type used by applications and services to access Azure resources.
• Managed Identities: An Azure AD feature that provides an identity for Azure resources. AKS supports managed identities to simplify credential management for workloads running within the cluster.

Service Principals

A Service Principal is an identity created for use with applications, hosted services, and automated tools to access specific Azure resources. It consists of an appId and an appSecret (or certificate).

Creating a Service Principal

You can create a Service Principal using the Azure CLI:

az ad sp create-for-rbac --name myAKSAppSP --role contributor --scopes /subscriptions//resourceGroups/

This command creates a Service Principal, assigns it the contributor role scoped to a specific resource group, and outputs the credentials (appId, password, tenant).

Using a Service Principal in AKS

Once created, you can use the Service Principal's credentials to:

• Configure your AKS cluster to use it for managing Azure resources (e.g., for Load Balancers, Persistent Volumes).
• Mount secrets containing the credentials into your pods.

Managed Identities

Managed Identities for Azure resources is a feature of Azure Active Directory (Azure AD) that provides an identity for applications and services running on Azure. AKS leverages this feature to simplify credential management.

Types of Managed Identities

• System-assigned managed identity: Directly linked to an AKS cluster resource. It's enabled and disabled when the cluster is created or deleted.
• User-assigned managed identity: A standalone Azure resource that can be assigned to one or more AKS clusters. This offers more flexibility in managing identities across multiple resources.

Enabling Managed Identities in AKS

When creating an AKS cluster, you can specify the type of managed identity to use.

Using Azure CLI for system-assigned:

az aks create --resource-group myResourceGroup --name myAKSCluster --enable-managed-identity --node-count 1 --location eastus

Using Azure CLI for user-assigned:

# Create a user-assigned identity
az identity create --resource-group myResourceGroup --name myUserAssignedIdentity --location eastus

# Create AKS cluster with the user-assigned identity
az aks create --resource-group myResourceGroup --name myAKSCluster --assign-identity myUserAssignedIdentity --node-count 1 --location eastus

Leveraging Managed Identities in Pods

Pods in AKS can obtain an identity token from the Azure AD token endpoint using the managed identity. This allows them to authenticate to Azure services without needing explicit credentials.

Choosing Between Service Principals and Managed Identities

The choice between Service Principals and Managed Identities depends on your specific use case:

For applications running inside AKS that need to access other Azure services, Managed Identities are the recommended approach due to their built-in security and ease of management.

Implementing Service Identity in AKS Workloads

Scenario 1: Accessing Azure Key Vault from a Pod

To securely retrieve secrets from Azure Key Vault, your pod needs an identity. If you're using Managed Identities:

1. Enable Managed Identity for your AKS cluster.
2. Grant the Managed Identity appropriate RBAC permissions on your Key Vault (e.g., "Get" and "List" secrets).
3. Deploy a pod that uses a library or sidecar (like the Azure Key Vault CSI driver) to authenticate with the Managed Identity and fetch secrets.

The Azure Key Vault CSI driver automatically uses the pod's service account identity (linked to the cluster's Managed Identity) to authenticate.

Scenario 2: AKS Cluster Identity for Azure Resources

When AKS provisions resources like Azure Load Balancers or Persistent Volumes, it uses its own identity. This identity is typically the cluster's Service Principal or Managed Identity.

• Load Balancer: The AKS cluster identity needs permissions to create and manage public IPs and load balancer resources in your subscription.
• Persistent Volumes: If using Azure Disks or Azure Files, the cluster identity needs permissions to create and manage these storage resources.

During cluster creation, AKS typically prompts for or automatically configures these permissions if you're using a Managed Identity.

Best Practices for Service Identity in AKS

• Prefer Managed Identities: Whenever possible, use Managed Identities for applications running within AKS to simplify credential management and improve security.
• Least Privilege: Grant only the necessary permissions to your Service Principals or Managed Identities. Avoid overly broad roles like "Owner" or "Contributor" unless absolutely required.
• Regularly Review Permissions: Periodically audit the permissions assigned to your service identities to ensure they are still appropriate.
• Use Azure Key Vault for Secrets: Store sensitive application secrets and Service Principal secrets in Azure Key Vault and access them securely from your AKS pods.
• Automate Secret Rotation: If using Service Principals, implement a robust process for rotating secrets and updating the credentials in your AKS environment.
• Monitor Identity Usage: Utilize Azure Monitor and Azure AD logs to track the usage of your service identities and detect any suspicious activity.