Workload Identity dans Azure Kubernetes Service

Dans ce nouvel article, nous allons regarder Workload Identity dans un contexte AKS.

Pour rappel, Workload Identity s’attelle à proposer une solution simple et élégante pour gérer de manière granulaire les autorisations de pods dans Kubernetes sur des ressources Azure. Puisqu’il s’agit de l’objet de l’article, plus de détails dans la suite…

Nous aborderons les points suivants :

• Avant Workload Identity, le besoin et la solution
• Concepts de Workload Identity
• Implementer Workload Identity dans AKS

Avant Workload Identity

Workoad Identity est maintenant GA (General Availability) depuis un peu plus d’un an. Mais revenons un peu en arrière pour comprendre le besoin.

D’un point de vue Microservices, il y a bien souvent des interactions, même en respectant la pratique “Loose coupling”, entre les différents services d’une application. Pour sécuriser l’application, il est logique d’envisager que chacun de ces services prouve qu’il est celui qu’il prétend être. C’est le processus d’authentification. À la suite de son authentification, ledit service devrait avoir des autorisations définies, pour respecter le principe de least privilege.

Si l’on se place à présent dans un contexte Azure, il existe un moyen pour authentifier et autoriser un service à faire des choses dans Azure ou dans un service intégré à Entra Id. Ce moyen s’appuie sur les identités managées.

Ce moyen fonctionne plutôt bien avec l’avantage de se dédouaner de la gestion des couples login/mot de passe.

En théorie donc, il n’y a pas de risque de trouver une connection string ou un secret codé en dur dans du code applicatif. Mais que se passe-t-il quand on se met dans un contexte containerisé, et spécifiquement dans AKS ?

Tout d’abord, il faut se rappeler qu’un container, par design, est un processus isolé qui partage un noyau. Bien que l’isolation soit moindre par rapport à un OS virtualisé (et de fait plus légère, donc plus rapide…), il s’agit toujours d’une isolation.

De fait, la plateforme Azure ne peut pas vraiment voir ce qui se passe dans un container, ou dans un pod AKS.

La première réponse à ce problème hérité de la nature des containers (et des pods) était un projet OSS appelé Pod Identity.

À travers Pod Identity, un objet Kubernetes correspondant à une identité managée était introduit dans le control plan Kubernetes.

Une Custom Resource Definition (CRD) permettait de créer un objet managed identity dans le plan Kubernetes et était associée à un pod à l’aide d’un managed identity binding (aussi sous la forme d’une CRD). Un peu à la manière d’un service associé à des pods à travers leurs labels.

Ensuite, un daemonset garantissait qu’un certain type de pod était toujours présent sur chaque node, afin d’intercepter les requêtes d’authentification, et communiquait avec un autre pod, géré dans un déploiement, qui lui-même vérifiait côté Entra Id (Azure AD à l’époque) l’authentification et les autorisations.

D’un point de vue Kubernetes, l’approche pouvait sembler élégante. Après tout, la tendance est à l’utilisation de CRD un peu partout. Néanmoins, l’architecture de Pod Identity comportait un certain nombre de limitations, et le développement n’est jamais arrivé à la V2.

À la place, le produit a été redéveloppé entièrement et appelé Workload Identity.

Concepts de Workload Identity

Après ce petit intermède historique, concentrons-nous à présent sur la manière dont fonctionne Workload Identity.

Pour commencer, il est intéressant de considérer le scope de Workload Identity.

En effet, en dehors d’un scope purement Kubernetes (on parle bien de Kubernetes et pas d’AKS, ce qui était d’ailleurs une des limitations de Pod Identity V1), il est intéressant de noter que Workload Identity est en fait défini au niveau Entra Id. Il existe d’ailleurs une page dédiée dans la documentation Entra.

Cette documentation définit les différents types d’identités éligibles à Workload Identity :

• Les identités managées
• Les Applications registrations

On y trouve également des informations sur le concept de Workload Identity Federation qui est en fait le concept fondamental de la façon dont fonctionne Workload Identity.

Pour faire simple, il s’agit au final de fédérer un fournisseur d’identité avec Entra Id, à travers une Application registration ou une Identité managée.

Alors qu’une identité managée ne fonctionne que dans un contexte Azure, il est donc possible de s’appuyer sur des Applications registrations dans des environnements non Azure.

En établissant une Workload Identity Federation, on configure en réalité une identité Entra afin qu’elle fasse confiance à un fournisseur d’identité tiers. Mais le plus intéressant dans cette approche est le fait que le secret de l’Application registration n’est plus requis pour des systèmes non Azure.

Comme décrit dans le schéma ci-dessous, une application, que l’on appelle ici workload, s’appuie sur l’Identity provider (idp) local pour récupérer un token.

Ce token, connu uniquement de l’idp local, est envoyé à la partie d’Entra Id, l’identité fédérée. De par sa fédération avec l’idp local, l’identité va aller vérifier sur cet idp le token reçu.

Si le token est valide, le processus passe à l’étape d’autorisation, qui s’appuie sur les role assignments Azure assignés à l’identité Entra. Le workload aura donc les autorisations de l’identité Entra.

Un des points séduisants de cette approche est la granularité de la fédération, limitée à l’identité Entra uniquement, plutôt qu’au niveau d’un tenant.

Maintenant que nous avons vu les concepts, nous allons à présent les traduire dans environnement AKS.

Workload Identity dans AKS

Aperçu de Workload Identity dans un contexte AKS

En partant du schéma précédent, dans un contexte Kubernetes, nous obtenons ceci :

Kubernetes dispose d’une URL OIDC depuis sa version 1.20, ce qui en fait un Identity provider comme dans le schéma.

Ensuite, nous avons notre application, qui est composée d’un pod (plus exactement de pods, dans un controller mais gardons les choses simples pour le moment), et d’un service account associé à ce pod.

Le service account est la partie qui récupère le token, et qui va autoriser le request token dans Entra Id à être utilisé par le pod pour les accès dont il a besoin.

D’un point de vue concept, on constate que l’architecture est plus simple que dans l’ancien Pod Identity.

Composant de Workload Identity dans AKS

À l’aide de notre schéma, nous pouvons faire une liste des composants pour Workload Identity :

Dans Azure :

• Une identité managée avec federated credentials utilisé sur AKS,

Dans Kubernetes :

• Un service account
• L’url OIDC du cluster

La création des federated credentials est disponible depuis le portail :

Ou via appel d’API, par exemple avec le provider Terraform avec deux ressources distinctes :

• L’identité managée
• Les federated credentials

Il n’y a pas de difficulté pour la création de l’identité managée. En revanche, la configuration des federated credentials demande un peu plus de planification.

En nous référant à la documentation Microsoft sur le sujet, on sait que les paramètres « issuer » et « subject » sont les informations qui permettent l’établissement de la relation avec le l’idp externe.

Dans AKS, la propriété OIDC Issuer url est la valeur que l’on configure pour le paramètre issuer et ressemble à ceci :

https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/

On peut récupérer cette valeur avec az cli :

En ce qui concerne le paramètre subject, il s’agit – comme discuté au préalable – d’un service account. On le référence en spécifiant son namespace de la manière suivante :

system:serviceaccount:<service_account_namespace>:<service_account_name>

La valeur recommandée pour le paramètre audience est api://AzureADTokenExchange. Certains remarqueront peut-être que ce paramètre semble attendre une liste dans l’exemple Terraform. En effet, la documentation Entra Id fait référence à « audiences » plutôt que « audience », et définit une liste d’audiences pouvant apparaitre dans les tokens extérieurs présentés.

Dans notre exemple avec le provider Terraform, nous avons également le paramètre parent_id qui correspond à l’id de l’identité managée sur laquelle les federated credentials sont établis.

Côté Kubernetes, on peut observer un déploiement dans le namespace kube-system :

Ce déploiement est le webhook qui permet de récupérer le token d’Entra Id et de le distribuer aux Pods qui ont besoin de s’authentifier, à travers un mutated admission webhook.

Passons à présent à un peu de mise en pratique.

Utiliser Workload Identity avec le provider Key Vault CSI Secret Store

Pour un cas d’usage pratique, nous allons essayer Workload Identity avec le Key Vault CSI Secret Store provider.

Le choix de cette solution est basé sur deux raisons. Tout d’abord, l’usage du secret store est un bon moyen de sortir les secrets du cluster en lui-même, et en second lieu, il est relativement simple à mettre en œuvre, sans rentrer dans du développement.

Le CSI provider est disponible comme un AKS add-on, ce qui en simplifie grandement l’installation. En revanche, l’add-on déploie également une identité managée associée au cluster, ce qui n’est pas aussi granulaire que nous pourrions le vouloir. De fait l’usage de Workload Identity s’impose pour atteindre la granularité voulue.

La première étape est la définition de la CRD qui permet de définir un secret store dans Kubernetes.

D’un point de vue configuration, on notera l’usage du paramètre clientID, pour lequel nous spécifions la client Id de l’identité managée. Le paramètre usePodIdentity est bien entendu configuré sur false.

Nous avons ensuite besoin d’un Service account, correspondant à la configuration des federated credentials.

Le nom du Service account ainsi que le namespace doivent, de fait, correspondre avec ce qui est défini dans les federated credentials.

On notera également l’annotation azure.workload.identity/use: “true” qui valide que le service account est utilisé pour Workload Identity.
D’autres annotations sont explicitées dans la documentation Workoad Identity disponible sur le github du projet.

On peut vérifier les informations de l’identité fédérée avec la commande suivante :

Enfin, les pods doivent être configurés avec le service account pour, dans notre cas, accéder au key vault configuré dans le csi provider.

Une fois déployés, on peut voir que les pods sont configurés avec deux volumes : le volume du CSI, et un volume projeté qui porte le token pour l’accès Entra Id.

Et pour finir, le secret configuré dans le secret store est disponible dans les pods, avec un contrôle d’accès granulaire :

L’essentiel à retenir sur Workload Identity dans AKS

Worklad Identity permet bien d’apporter une granularité d’accès dans Azure pour des workloads Kubernetes, avec une configuration à l’usage simple qui dépend simplement de l’association à un service account.

Dans le plan Azure, la configuration s’appuie sur une identité, qui peut être une identité managée ou une application registration dans Entra Id, et la création d’une fédération sur cette identité à l’aide des federated credentials.

Devenant une fonctionnalité Entra Id, les options de sécurisation de l’Idp de Microsoft comme Conditional access ou encore Access Review peuvent également être considérées pour renforcer la sécurité des workloads Kubernetes.

Vous souhaitez être accompagnés dans vos projets ? Contactez-nous !