<Identity and Access Management in Azure Kubernetes Service (AKS)>
Written on
Kubernetes lacks a native system for user management. Instead, administrators can link their preferred organizational identity provider to facilitate cluster interactions. This integration eliminates the need for duplicate user management. Azure Kubernetes Service (AKS) supports integration with Azure AD, a robust identity management solution that serves as the authoritative source for account and security management.
This article will delve into the concept of identity within AKS, exploring how it is established and the various options for authentication and authorization from both the Kubernetes and AKS perspectives.
TL;DR
There are four main configurations for authentication and authorization in an AKS cluster:
1. Local Account Authentication with RBAC Authorization
In this setup, users and admins receive an X.509 client certificate, locally created for the cluster. The certificate’s common name is set to "masterclient," and it belongs to the "system:masters" group, granting full cluster admin access.
Without an integrated identity management system, administrators must manually generate a certificate for each new user, signed by the cluster's certificate authority. Using Kubernetes RBAC, these users can be assigned permissions for cluster resources. For detailed instructions on user creation, refer to the Kubernetes documentation.
Example command to create a cluster with this setup:
az aks create -g MyResourceGroup -n MyManagedCluster
2. Local Account Authentication without Authorization
This approach mirrors the first but lacks any authorization mechanism, granting any authenticated user full admin access to the cluster.
Example command to create a cluster with this setup:
az aks create -g MyResourceGroup -n MyManagedCluster --disable-rbac
3. Azure Active Directory Authentication with RBAC Authorization
Users are directed to Azure Active Directory for authentication, while Kubernetes RBAC serves as the sole authorization mechanism. This configuration requires setting up an Azure AD group as the cluster admin, allowing group members to configure access for other AD users or groups.
Example commands to create this setup:
Create an Azure AD group for cluster admins:
az ad group create --display-name myAKSAdminGroup --mail-nickname myAKSAdminGroup
Retrieve the group object ID:
admin_group_object_id=$(az ad group show --group myAKSAdminGroup --query objectId -o tsv)
Add admin users to the group:
az ad group member add --group myAKSAdminGroup --member-id [[put your account object id here]]
Create the cluster, specifying the admin group:
az aks create -g MyResourceGroup -n MyManagedCluster --enable-aad --aad-admin-group-object-ids $admin_group_object_id --disable-local-accounts
Note: Local accounts are enabled by default. To centralize access control through Azure AD, disable local accounts. This feature is in preview, refer to official documentation for instructions.
AKS will create a cluster role binding that provides the admin group full access to the cluster. Verify this by retrieving the cluster credentials:
az aks get-credentials -g MyResourceGroup -n MyManagedCluster
Check the cluster role binding created by AKS:
kubectl get clusterrolebinding aks-cluster-admin-binding-aad -o yaml
4. Azure Active Directory Authentication with Azure and Kubernetes RBAC
In this scenario, users authenticate via Azure AD. The Kubernetes API delegates authorization to a webhook server that utilizes both Azure and Kubernetes RBAC for access control. This setup eliminates the need to establish an admin group for the cluster.
Example command for this configuration:
az aks create -g MyResourceGroup -n MyManagedCluster --enable-aad --enable-azure-rbac --disable-local-accounts
Note: Local accounts are enabled by default. Disable them to enforce centralized access control through Azure AD. This feature is still in preview; refer to official documentation for guidance.
Once the cluster is created, you can assign Azure AD principals Azure RBAC roles scoped to specific namespaces or across the entire AKS cluster.
To become a cluster admin, assign yourself the "Azure Kubernetes Service RBAC Cluster Admin" role:
AKS_ID=$(az aks show -g MyResourceGroup -n MyManagedCluster --query id -o tsv) az role assignment create --role "Azure Kubernetes Service RBAC Cluster Admin" --assignee <YOUR-AAD-ENTITY-ID> --scope $AKS_ID
For more information about available AKS roles and creating custom ones, consult the AKS documentation.
Understanding Identity in Kubernetes
Each API call made by a user to Kubernetes is directed to the kube-api server, which handles requests from various Kubernetes components like the scheduler and kubelets. For each incoming request, the API server processes three main tasks: authentication, authorization, and admission control.
Identity Concepts in Kubernetes
Kubernetes recognizes two types of identities:
- User Accounts: These represent user personas, unique across all namespaces. They are not managed within Kubernetes and can only be referred to inside the cluster. User accounts are typically created by an organization's identity management solution and can belong to groups.
- Service Accounts: These accounts represent applications running in pods. They are namespaced, allowing for duplicate names across different namespaces. Service accounts are Kubernetes objects managed by the cluster, and their credentials are stored as Kubernetes secrets.
Every namespace automatically includes a "default" service account. When deploying a pod, the default service account's credentials are mounted as a volume in the pod's filesystem unless a different service account is specified.
To create a service account:
kubectl create serviceaccount mysa
Identity in AKS
AKS clusters, managed by Azure, share the same identity types as Kubernetes: user accounts and service accounts. User accounts are typically managed outside Kubernetes. Users present valid certificates signed by the cluster's certificate authority to gain authentication.
With Azure AD integration, AKS allows users to access on-premises, Azure, and AKS cluster resources without managing certificate-based kubeconfig files. It's advisable to disable local accounts to enforce Azure AD as the central user management source.
Azure user accounts and service principals in Azure AD can authenticate to AKS clusters. Creating a user involves making a user or service principal in Azure AD.
To create a user in Azure AD:
az ad user create --display-name mydisplay --password {password} --user-principal-name myuserprincipal
To create a service principal:
az ad sp create-for-rbac --name ServicePrincipalName
Authentication Mechanisms
Authentication verifies the identity of the entity issuing the request.
Kubernetes Authentication
During Kubernetes cluster creation, you can enable various Authenticator Modules like static passwords, client certificates, and OpenID Connect tokens. Multiple modules can be activated simultaneously.
When a user runs a kubectl command, the client configuration decorates the request for API server authentication. Some client configurations include:
- Username and password for basic authentication.
- User X.509 certificate for CA-signed certificates.
- Bearer token from a preconfigured file.
- JWT token generated by an OAuth2 provider like Azure AD.
AKS Authentication
In AKS, both X.509 client certificates and JWT tokens from Azure AD are supported authentication methods. By default, AKS uses local accounts with X.509 certificates.
When using Azure AD, authentication is delegated to a webhook server. This server validates JWT tokens and checks group memberships via the MS Graph API.
To understand AKS authentication better, you can create an Azure AD enabled AKS cluster and examine the kubeconfig file generated during the process:
az aks get-credentials -g MyResourceGroup -n MyManagedCluster
The kubeconfig contains details for accessing the AKS cluster, including API server endpoint and user configurations.
When executing a command against the cluster for the first time, kubectl prompts for Azure AD authentication through an OAuth2 device authorization flow. After authentication, the kubeconfig file updates with token information.
Authorization Mechanisms
Following authentication, the API server assesses whether the requester has the necessary permissions to perform the requested action.
Kubernetes Authorization
Similar to authentication, the API server can enable multiple Authorization modules. Options include:
- ABAC: Policies defined in a static file.
- RBAC: Dynamic role-based access control to create and manage roles for cluster objects.
- Webhook: Delegates policy decisions to an external service.
- Node: Authorizes requests from kubelets.
Authorization in AKS integrates with Azure RBAC, enabling unified management across Azure resources and Kubernetes.
Conclusion
This article explored identity and the various authentication and authorization options available in Kubernetes and AKS.
In summary, Azure recommends using Azure AD integrated AKS clusters with disabled local accounts for authentication. Both Azure RBAC and Kubernetes RBAC should be enabled for comprehensive access management, while respecting the Principle of Least Privilege at each authorization level to ensure users and applications only access necessary resources.