Azure Kubernetes Service (AKS) with Bring-Your-Own Identity (BYOID)
AKS would require an identity with sufficient permissions to perform the actions like creating additional load balancers, public IP addresses and managed disks on Azure platform. By default, AKS would take care all of this by creating system-assigned managed identities (MI). However, there are situations that administrators would like to use either user-assigned MI or just pure Azure active directory (AAD) service principals (SP).
MI has the characteristic of letting Azure platform to control its lifecycle. System-assigned MI’s lifecycle goes with the service itself and user-assigned MI does not have that trait as it is a separately created identity object. To know more about the details, please check this site.
AKS has the flexibility of using all sorts of identity, so it really comes down what needs to be achieved in the specific environment. For example, administrators might want to have specific user-assigned MI for Kubelet because of the integration with Azure container registry (ACR).
Let’s try to create an AKS cluster with user-assigned MIs for both control plane and Kubelet. First things first, we would need to register the feature.
# register for the Kubelet identity feature
- az feature register --namespace Microsoft.ContainerService -n CustomKubeletIdentityPreview# check the registering status
- az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/CustomKubeletIdentityPreview')].{Name:name,State:properties.state}"# register AKS resource provider
- az provider register --namespace Microsoft.ContainerService
Next, create an user-assigned MI for control plane (Master Nodes, which is managed by Azure platform in the backend) and another user-assigned MI for Kubelet.
# create a resource group
- az group create -n RG-BYOIDAKS -l westus2
# create an user-assigned MI for control plane and note down the resource ID
- az identity create --name jonwcontrolplaneid -g RG-BYOIDAKS
# create another user-assigned MI for Kubelet and note down the resource ID
- az identity create --name jonwkubeletid -g RG-BYOIDAKS
# create a virtual network and subnet and note down the subnet resource ID
- az network vnet create -g RG-BYOIDAKS --address-prefix 10.0.0.0/8 --subnet-name Subnet-BYOIDAKS --subnet-prefix 10.0.0.0/16# create an AKS cluster with 2 user-assigned MI
- az aks create \
-g RG-BYOIDAKS \
-n jonwbyoidaks \
--network-plugin azure \
--vnet-subnet-id /subscriptions/xxx/resourceGroups/RG-BYOIDAKS/providers/Microsoft.Network/virtualNetworks/VNet-BYOIDAKS/subnets/Subnet-BYOIDAKS \
--docker-bridge-address 172.17.0.1/16 \
--dns-service-ip 10.2.0.10 \
--service-cidr 10.2.0.0/24 \
--enable-managed-identity \
--assign-identity /subscriptions/xxx/resourcegroups/RG-BYOIDAKS/providers/Microsoft.ManagedIdentity/userAssignedIdentities/jonwcontrolplaneid \
--assign-kubelet-identity /subscriptions/xxx/resourcegroups/RG-BYOIDAKS/providers/Microsoft.ManagedIdentity/userAssignedIdentities/jonwkubeletid
# check AKS identity details
- az aks show -g RG-BYOIDAKS -n jonwbyoidaks | grep identity -A10
That is it for this article. Basically, unless you have very specific need of using your own AAD identity objects, using system-managed MI would be the way to reduce the most management overhead. Kubelet MI is still in public preview and there might be other changes in the future. Happy Learning!
