Configurare Azure Workload Identity su AKS

Questa pagina riepiloga gli elementi da configurare affinché le discovery Kubernetes via kubeconfig di un’istanza Cyberwatch distribuita su un cluster AKS si autentichino presso l’API Kubernetes del cluster con Azure Workload Identity.

Azure Workload Identity si basa sulla federazione OIDC tra il cluster AKS e Microsoft Entra ID. I pod di Cyberwatch ottengono così un token senza alcun segreto memorizzato nel cluster. Un webhook di mutazione inietta, alla creazione dei pod, le variabili d’ambiente Azure che l’applicazione utilizza poi per interrogare l’API Kubernetes.

Configurazione lato Azure

Cluster AKS

Il cluster deve disporre delle funzionalità seguenti:

  • l’emittente OIDC attivato (oidcIssuerProfile.enabled impostato a true)
  • Workload Identity attivato (opzione --enable-workload-identity alla creazione o all’aggiornamento del cluster). Il webhook di mutazione azure-wi-webhook è quindi presente sul cluster
  • l’autorizzazione Kubernetes tramite Azure RBAC attivata (aadProfile.enableAzureRbac impostato a true). I diritti di accesso all’API Kubernetes vengono quindi gestiti tramite assegnazioni di ruoli Azure, e non tramite ClusterRoleBinding

L’URL dell’emittente OIDC del cluster è necessario per i passaggi successivi:

az aks show --resource-group <resource-group> --name <cluster-name> --query oidcIssuerProfile.issuerUrl

Identità gestita

Creare un’identità gestita dedicata, di tipo user-assigned, a cui saranno assegnati i diritti di accesso della discovery.

Credenziale federata

Creare una credenziale federata (federated identity credential) sull’identità gestita, con i parametri seguenti:

  • issuer: l’URL dell’emittente OIDC del cluster
  • subject: l’identità dell’account di servizio dedicato descritto più avanti
  • audience: api://AzureADTokenExchange

Il subject ha il formato seguente, dove <namespace> è il namespace in cui Cyberwatch è distribuito e <service-account> il nome del ServiceAccount:

system:serviceaccount:<namespace>:<service-account>

Assegnazioni di ruoli

Assegnare all’identità gestita il ruolo Lettore RBAC del servizio Azure Kubernetes (Azure Kubernetes Service RBAC Reader) su ogni cluster AKS da scansionare. Questo ruolo consente le chiamate all’API Kubernetes del cluster, come elencare i pod, i namespace e i workload.

La credenziale federata deve essere configurata una sola volta, per il cluster che ospita Cyberwatch. Gli altri cluster da scansionare necessitano solo di questo ruolo e devono appartenere allo stesso tenant Microsoft Entra dell’identità gestita.

Senza questo ruolo sul cluster, le chiamate all’API Kubernetes non riescono e restituiscono l’errore User does not have access to the resource in Azure.

Configurazione lato cluster Kubernetes

La configurazione si applica nel namespace in cui Cyberwatch è distribuito, cyberwatch negli esempi seguenti.

Account di servizio dedicato

Creare un ServiceAccount con un’annotazione contenente il client ID dell’identità gestita:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: workload-identity-sa
  namespace: cyberwatch
  annotations:
    azure.workload.identity/client-id: <client-id>

Deployment Cyberwatch

Il chart Helm Cyberwatch espone le due impostazioni necessarie alla distribuzione: extraLabels applica il label al template del pod e serviceAccountName specifica il ServiceAccount del pod. Il ServiceAccount non viene creato dal chart e deve già esistere nel namespace.

web:
  serviceAccountName: workload-identity-sa
  extraLabels:
    azure.workload.identity/use: "true"
sidekiq:
  serviceAccountName: workload-identity-sa
  extraLabels:
    azure.workload.identity/use: "true"
sidekiqMaster:
  serviceAccountName: workload-identity-sa
  extraLabels:
    azure.workload.identity/use: "true"
sidekiqNode:
  serviceAccountName: workload-identity-sa
  extraLabels:
    azure.workload.identity/use: "true"

Per applicare lo stesso ServiceAccount a tutti i componenti, è possibile specificarlo una sola volta tramite global.serviceAccountName.

Applicare le modifiche del chart Helm con un helm upgrade.

Verificare il funzionamento

Dopo il riavvio dei pod, ogni pod interessato deve contenere le variabili d’ambiente AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_FEDERATED_TOKEN_FILE e AZURE_AUTHORITY_HOST, oltre a un token proiettato in /var/run/secrets/azure/tokens/azure-identity-token:

kubectl -n cyberwatch exec deploy/web -- env | grep AZURE_

La discovery Kubernetes via kubeconfig può quindi essere creata dall’applicazione seguendo la documentazione delle discovery Kubernetes via kubeconfig.