Configurer Azure Workload Identity sur AKS

Cette page récapitule les éléments à configurer pour que les découvertes Kubernetes d’une instance Cyberwatch déployée sur un cluster AKS s’authentifient auprès de l’API Kubernetes du cluster avec Azure Workload Identity.

Azure Workload Identity repose sur la fédération OIDC entre le cluster AKS et Microsoft Entra ID. Les pods de Cyberwatch obtiennent ainsi un jeton sans secret stocké dans le cluster. Un webhook de mutation injecte à la création des pods les variables d’environnement Azure que l’application utilise ensuite pour interroger l’API Kubernetes.

Configuration côté Azure

Cluster AKS

Le cluster doit disposer des fonctionnalités suivantes :

l’émetteur OIDC activé (oidcIssuerProfile.enabled à true)
Workload Identity activé (option --enable-workload-identity à la création ou à la mise à jour du cluster). Le webhook de mutation azure-wi-webhook est alors présent sur le cluster
l’autorisation Kubernetes par Azure RBAC activée (aadProfile.enableAzureRbac à true). Les droits d’accès à l’API Kubernetes se gèrent alors par des attributions de rôles Azure, et non par des ClusterRoleBinding

L’URL de l’émetteur OIDC du cluster est nécessaire pour la suite :

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

Identité managée

Créer une identité managée dédiée, de type user-assigned, qui portera les droits d’accès de la découverte.

Identifiant fédéré

Créer un identifiant fédéré (federated identity credential) sur l’identité managée, avec les paramètres suivants :

issuer : l’URL de l’émetteur OIDC du cluster
subject : l’identité du compte de service dédié décrit plus bas
audience : api://AzureADTokenExchange

Le subject est au format suivant, où <namespace> est l’espace de noms où Cyberwatch est déployé et <service-account> le nom du ServiceAccount :

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

Attributions de rôles

Attribuer les rôles suivants à l’identité managée :

Lecteur RBAC Azure Kubernetes Service (Azure Kubernetes Service RBAC Reader) sur le périmètre du cluster AKS. Ce rôle autorise les appels à l’API Kubernetes du cluster, comme lister les pods, les espaces de noms et les workloads
Lecteur (Reader) sur l’abonnement, ou sur un périmètre plus restreint, uniquement si la découverte énumère aussi des ressources Azure

Un rôle Lecteur sur l’abonnement ne donne pas accès à l’API Kubernetes. Sans le rôle Lecteur RBAC Azure Kubernetes Service sur le cluster, les appels échouent avec l’erreur User does not have access to the resource in Azure.

Configuration côté cluster Kubernetes

La configuration s’applique dans l’espace de noms où Cyberwatch est déployé, cyberwatch dans les exemples ci-dessous.

Compte de service dédié

Créer un ServiceAccount annoté avec le client ID de l’identité managée :

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

Déploiements Cyberwatch

Le chart Helm Cyberwatch expose les deux réglages nécessaires au déploiement : extraLabels applique le label sur le template de pod et serviceAccountName renseigne le ServiceAccount du pod. Le ServiceAccount n’est pas créé par le chart et doit déjà exister dans l’espace de noms.

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"

Pour appliquer le même ServiceAccount à tous les composants, il est possible de le renseigner une seule fois via global.serviceAccountName.

Appliquer les changements du chart helm avec un helm upgrade.

Vérifier le fonctionnement

Une fois les pods redémarrés, chaque pod concerné doit contenir les variables d’environnement AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_FEDERATED_TOKEN_FILE et AZURE_AUTHORITY_HOST, ainsi qu’un jeton projeté dans /var/run/secrets/azure/tokens/azure-identity-token :

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

La découverte Kubernetes peut ensuite être créée depuis l’application en suivant la documentation des découvertes Kubernetes.