IMPORTANT: the steps below are not relevant anymore; the steps in the quick guide have been updated; see https://github.com/gbaeke/quick-guides/blob/main/workload-identity/README.md for the correct steps.
Some things that have changed:
- you can now use managed identities instead of app registrations; federated token configuration is at the managed identity level
- you do not need to install the webhook
- the
azwiCLI is not required
I recently had to do a demo about Workload Identity on AKS and threw together some commands to enable and verify the setup. It contains bits and pieces from the documentation plus some extras. I wrote another post some time ago with more background.
All commands are for bash and should be run sequentially in the same shell to re-use the variables.
Step 1: Enable OIDC issuer on AKS
You need an existing AKS cluster for this. You can quickly deploy one from the portal. Note that workload identity is not exclusive to AKS.
CLUSTER=<AKS_CLUSTER_NAME>
RG=<AKS_CLUSTER_RESOURCE_GROUP>
az aks update -n $CLUSTER -g $RG --enable-oidc-issuer
After enabling OIDC, retrieve the issuer URL with ISSUER_URL=$(az aks show -n $CLUSTER -g $RG --query oidcIssuerProfile.issuerUrl -o tsv). To check, run echo $ISSUER_URL. It contains a URL like https://oidc.prod-aks.azure.com/GUID/. You can issue the command below to obtain the OpenID configuration. It will list other URLs that can be used to retrieve keys that allow Azure AD to verify tokens it receives from Kubernetes.
curl $ISSUER_URL/.well-known/openid-configuration
Step 2: Install the webhook on AKS
Use the Helm chart to install the webhook. First, save the Azure AD tenant Id to a variable. The tenantId will be retrieved with the Azure CLI so make sure you are properly logged in. You also need Helm installed and a working Kube config for your cluster.
AZURE_TENANT_ID=$(az account show --query tenantId -o tsv)
helm repo add azure-workload-identity https://azure.github.io/azure-workload-identity/charts
helm repo update
helm install workload-identity-webhook azure-workload-identity/workload-identity-webhook \
--namespace azure-workload-identity-system \
--create-namespace \
--set azureTenantID="${AZURE_TENANT_ID}"
Step 3: Create an Azure AD application
Although you can create the application directly in the portal or with the Azure CLI, workload identity has a CLI to make the whole process less error-prone and easier to script. Install azwi with brew: brew install Azure/azure-workload-identity/azwi.
Run the following commands. First, we save the application name in a variable. Use any name you like.
APPLICATION_NAME=WorkloadDemo
azwi serviceaccount create phase app --aad-application-name $APPLICATION_NAME
You can now check the application registrations in Azure AD. In my case, WorkloadDemo was created.
If you want to grant this application access rights to resources in Azure, first grab the appId:
APPLICATION_CLIENT_ID="$(az ad sp list --display-name $APPLICATION_NAME --query '[0].appId' -otsv)"
Now you can use commands such as az role assignment create to grant access rights. For example, here is how to grant the Reader role to your current Azure CLI subscription:
SUBSCRIPTION_ID=$(az account show --query id -o tsv)
az role assignment create --assignee-object-id $APPLICATION_CLIENT_ID --role "Reader" --scope /subscriptions/$SUBSCRIPTION_ID
Step 4: Create a Kubernetes service account
Although you can create the service account with kubectl or via a YAML manifest, azwi can help here as well:
SERVICE_ACCOUNT_NAME=sademo
SERVICE_ACCOUNT_NAMESPACE=default
azwi serviceaccount create phase sa \
--aad-application-name "$APPLICATION_NAME" \
--service-account-namespace "$SERVICE_ACCOUNT_NAMESPACE" \
--service-account-name "$SERVICE_ACCOUNT_NAME"
This creates a service account that looks like the below YAML manifest:
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
azure.workload.identity/client-id: <value of APPLICATION_CLIENT_ID>
labels:
azure.workload.identity/use: "true"
name: sademo
namespace: default
This is a regular Kubernetes service account. Later, you will configure your pod to use the service account.
The label is important because the webhook we installed earlier acts on service accounts with this label to perform all the behind-the-scenes magic! 😉
Note that workload identity does not use the Kubernetes service account token. That token is used to authenticate to the Kubernetes API server. The webhook will ensure that there is another token, its path is in $AZURE_FEDERATED_TOKEN_FILE, which is the token sent to Azure AD.
Step 5: Configure the Azure AD app for token federation
The application created in step 5 needs to be configured to trust specific tokens issued by your Kubernetes cluster. When AAD receives such a token, it returns an Azure AD token that your application in Kubernetes can use to authenticate to Azure.
Although you can manually configure the Azure AD app, azwi can be used here as well:
SERVICE_ACCOUNT_NAMESPACE=default
azwi serviceaccount create phase federated-identity \
--aad-application-name "$APPLICATION_NAME" \
--service-account-namespace "$SERVICE_ACCOUNT_NAMESPACE" \
--service-account-name "$SERVICE_ACCOUNT_NAME" \
--service-account-issuer-url "$ISSUER_URL"
In the AAD app, you will see:
You find the above by clicking Certificates & Secrets and then Federated credentials.
Step 6: Deploy a workload
Run the following command to create a deployment and apply it in one step:
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
name: azcli-deployment
namespace: default
labels:
app: azcli
spec:
replicas: 1
selector:
matchLabels:
app: azcli
template:
metadata:
labels:
app: azcli
spec:
serviceAccount: sademo
containers:
- name: azcli
image: mcr.microsoft.com/azure-cli:latest
command:
- "/bin/bash"
- "-c"
- "sleep infinity"
EOF
This runs the latest version of the Azure CLI in Kubernetes.
Grab the first pod name (there is only one) and exec into the pod’s container:
POD_NAME=$(kubectl get pods -l "app=azcli" -o jsonpath="{.items[0].metadata.name}")
kubectl exec -it $POD_NAME -- bash
Step 7: Test the setup
In the container, issue the following commands:
echo $AZURE_CLIENT_ID
echo $AZURE_TENANT_ID
echo $AZURE_FEDERATED_TOKEN_FILE
cat $AZURE_FEDERATED_TOKEN_FILE
echo $AZURE_AUTHORITY_HOST
# list the standard Kubernetes service account secrets
cd /var/run/secrets/kubernetes.io/serviceaccount
ls
# check the folder containing the AZURE_FEDERATED_TOKEN_FILE
cd /var/run/secrets/azure/tokens
ls
# you can use the AZURE_FEDERATED_TOKEN_FILE with the Azure CLI
# together with $AZURE_CLIENT_ID and $AZURE_TENANT_ID
# a password is not required since we are doing federated token exchange
az login --federated-token "$(cat $AZURE_FEDERATED_TOKEN_FILE)" \
--service-principal -u $AZURE_CLIENT_ID -t $AZURE_TENANT_ID
# list resource groups
az group list
If the last command works, that means you successfully logged on with workload identity ok AKS. You can list resource groups because you granted the Azure AD app the Reader role on your subscription.
Note that the option to use token federation was added to Azure CLI quite recently. At the time of this writing, May 2022, the image mcr.microsoft.com/azure-cli:latest surely has that capability.
Conclusion
I hope the above commands are useful if you want to quickly test or demo Kubernetes workload identity on AKS. If you spot errors, be sure to let me know!
baeke.info 