Moving from Azure App Services to Azure Kubernetes Service (Part 2)

Managing Kubernetes access using Azure Active Directory

This is a follow-up to my previous post:

At the company I work in, centralized authentication for any sort of PaaS or SaaS solutions is a requirement to get anything into production. With Azure App Services, this is built into the platform by default — in order to access any of the App Service infrastructure stuff (e.g. App Settings, Kudu, Configuration) you need to go login to the Azure portal or Azure CLI.

Unfortunately, with AKS this isn’t the case — if you use the default setup, AKS will use client certificates for controlling access through kubectl.

In order for me to take the next step in making AKS our platform of choice for running our web applications, I need to make sure it integrates with Azure Active Directory.

In this post, I’ll run through how exactly the authentication process will look like, and how to do the setup.

AKS-managed Azure Active Directory integration

Required tools:

• az cli: used to set up the configuration for kubectl
• kubectl: the cli for interacting with kubernetes

As you’ll see below, the process for setting up kubectl is pretty exactly the same as non-AAD integrated AKS. However, a key difference is that AAD-integrated clusters force you to perform an AAD authentication before you can run any kubectl commands.

Let’s take a look at how this works below:

We first perform an az login…

PS C:\> az login
The default web browser has been opened at https://login.microsoftonline.com/common/oauth2/authorize. Please continue the login in the web browser. If no web browser is available or if the web browser fails to open, use device code flow with `az login --use-device-code`.
You have logged in. Now let us find all the subscriptions to which you have access...

Then we can get our kubectl credentials az aks get-credentials:

Now, when I first try running a kubectl command, I get prompted to perform an AAD login:

Only after completing the login will I get any output from kubectl:

What do kubectl AAD credentials look like?

In case you’re curious how the kubectl credentials differ on between an AKS cluster with AAD integration vs. one without, here you go!

Without AAD: You’re using a certificate to authenticate to AKS

With AAD: When you first run az aks get-credentials, kubectl config initially gets populated with AAD auth-provider configuration:

Once you actually authenticate with AAD, kubectl configuration gets updated with an access token:

This is much better (from a cybersecurity perspective) because if you have somebody leave the company, you don’t have to worry about them taking any Kubernetes certificates with them.

Setting it up

Here are the steps for creating a new AKS instance with AAD integration. Note: All these steps are available from the Microsoft documentation

• Create resource group
• Create AD group (used for assigning AKS permissions)
• Create AKS-managed AD cluster

# Login to Azure
az login
az account set -s "Your Subscription Name"

# Set up variables
$RG="digital-aks"
$AKSCLUSTER="digital-aks"
$AKSADMINGROUP="AKS Admins"

# Create an Azure AD group for cluster admins
az ad group create --display-name $AKSADMINGROUP --mail-nickname digitalaksadmins

# Create resource groups for AKS
az group create --name DefaultResourceGroup-EAU --location australiaEast 

az group create --name $RG --location australiaEast 

# Create an AKS-managed Azure AD cluster
$AKS_GROUP_ID=$(az ad group show -g $AKSADMINGROUP --query objectId -o tsv)

az aks create -g $RG -n $AKSCLUSTER --enable-aad --aad-admin-group-object-ids $AKS_GROUP_ID

# Assign cluster admin role to AD group
$AKS_ID=$(az aks show --resource-group $RG --name $AKSCLUSTER --query id -o tsv)

az role assignment create --assignee $AKS_GROUP_ID --role "Azure Kubernetes Service Cluster Admin Role" --scope $AKS_ID

# Assign users to the AKS admin group
$MEMBER_ID=$(az ad user show --id [email protected] --query objectId -o tsv)
az ad group member add --group $AKS_GROUP_ID --member-id $MEMBER_ID

Conclusion

One of the great things about App Services is that integration with Azure AD is built into the platform (I’m referring specifically about the infrastructure layer). Getting to things like Kudu or App Service settings all require going through the Azure Portal, which forces you to do AAD authentication.

AKS by default manages authentication using certificates — and while this is convenient, it tends to raise cybersecurity red flags (who has a copy of the cert, how are they kept, how are they rotated when people leave, etc).

AAD is the preferred IDP for many enterprises running on Azure, so chances are the security folks will want you to implement AAD integration if you’re trying to push AKS as the platform of choice at your company.

Luckily, Microsoft has made this very easy to do, so why not use it? Its definitely nice not having to worry about rotating certificates every time somebody quits!