Utiliser Microsoft Entra Workload ID avec Azure Kubernetes Service (AKS)

Article
08/02/2024

Les charges de travail déployées sur un cluster Azure Kubernetes Services (AKS) nécessitent les informations d’identification de l’application Microsoft Entra ou des identités managées pour accéder aux ressources protégées Microsoft Entra, telles qu’Azure Key Vault et Microsoft Graph. Microsoft Entra Workload ID s’intègre aux fonctionnalités natives de Kubernetes pour se fédérer avec des fournisseurs d’identité externes.

Microsoft Entra Workload ID utilise une projection de volume de jeton de compte de service (c’est-à-dire un compte de service), pour permettre aux pods d’utiliser une identité Kubernetes. Un jeton Kubernetes est émis et la fédération OIDC permet aux applications Kubernetes d’accéder aux ressources Azure de façon sécurisée avec Microsoft Entra ID, en se basant sur des comptes de service annotés.

Microsoft Entra Workload ID fonctionne particulièrement bien avec les bibliothèques de client Azure Identity ou avec la collection Bibliothèque d’authentification Microsoft (MSAL), en combinaison avec l’inscription d’application. Votre charge de travail peut utiliser n’importe laquelle de ces bibliothèques pour authentifier des ressources cloud Azure et y accéder en toute transparence.

Cet article vous permet de comprendre Microsoft Entra Workload ID et passe en revue les options disponibles pour planifier votre stratégie de projet et votre éventuelle migration depuis une identité managée par pod de Microsoft Entra.

Remarque

Vous pouvez utiliser le Connecteur de services pour vous aider à configurer automatiquement certaines étapes. Consultez également Qu’est-ce que Service Connector ?

Dépendances

AKS prend en charge Microsoft Entra Workload ID version 1.22 et ultérieure.
Azure CLI version 2.47.0 ou ultérieure. Exécutez az --version pour rechercher la version, puis exécutez az upgrade pour mettre à niveau la version. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.

Bibliothèques clientes d’identité Azure

Dans les bibliothèques de client Azure Identity, choisissez l’une des approches suivantes :

Utilisez DefaultAzureCredential, qui tente d’utiliser le WorkloadIdentityCredential.
Créez une instance ChainedTokenCredential qui inclut WorkloadIdentityCredential.
Utilisez WorkloadIdentityCredential directement.

Le tableau suivant fournit la version de package minimale demandée par la bibliothèque de client de chaque écosystème linguistique.

Écosystème	Bibliothèque	Version minimale
.NET	Azure.Identity	1.9.0
C++	azure-identity-cpp	1.6.0
Go	azidentity	1.3.0
Java	azure-identity	1.9.0
Node.js	@azure/identity	3.2.0
Python	azure-identity	1.13.0

Dans les exemples de code suivants, DefaultAzureCredential est utilisé. Ce type d’informations d’identification utilise les variables d’environnement injectées par le webhook de mutation de l’identité de charge de travail Azure pour s’authentifier dans Azure Key Vault.

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;

string keyVaultUrl = Environment.GetEnvironmentVariable("KEYVAULT_URL");
string secretName = Environment.GetEnvironmentVariable("SECRET_NAME");

var client = new SecretClient(
    new Uri(keyVaultUrl),
    new DefaultAzureCredential());

KeyVaultSecret secret = await client.GetSecretAsync(secretName);

#include <cstdlib>
#include <azure/identity.hpp>
#include <azure/keyvault/secrets/secret_client.hpp>

using namespace Azure::Identity;
using namespace Azure::Security::KeyVault::Secrets;

int main()
{
  const char* keyVaultUrl = std::getenv("KEYVAULT_URL");
  const char* secretName = std::getenv("SECRET_NAME");
  auto credential = std::make_shared<DefaultAzureCredential>();

  SecretClient client(keyVaultUrl, credential);
  Secret secret = client.GetSecret(secretName).Value;

  return 0;
}

package main

import (
	"context"
	"os"

	"github.com/Azure/azure-sdk-for-go/sdk/azidentity"
	"github.com/Azure/azure-sdk-for-go/sdk/security/keyvault/azsecrets"
    "k8s.io/klog/v2"
)

func main() {
	keyVaultUrl := os.Getenv("KEYVAULT_URL")
	secretName := os.Getenv("SECRET_NAME")

	credential, err := azidentity.NewDefaultAzureCredential(nil)
	if err != nil {
		klog.Fatal(err)
	}

	client, err := azsecrets.NewClient(keyVaultUrl, credential, nil)
	if err != nil {
		klog.Fatal(err)
	}

	secret, err := client.GetSecret(context.Background(), secretName, "", nil)
	if err != nil {
		klog.ErrorS(err, "failed to get secret", "keyvault", keyVaultUrl, "secretName", secretName)
		os.Exit(1)
	}
}

import java.util.Map;

import com.azure.security.keyvault.secrets.SecretClient;
import com.azure.security.keyvault.secrets.SecretClientBuilder;
import com.azure.security.keyvault.secrets.models.KeyVaultSecret;
import com.azure.identity.DefaultAzureCredentialBuilder;
import com.azure.identity.DefaultAzureCredential;

public class App {
    public static void main(String[] args) {
        Map<String, String> env = System.getenv();
        String keyVaultUrl = env.get("KEYVAULT_URL");
        String secretName = env.get("SECRET_NAME");

        SecretClient client = new SecretClientBuilder()
                .vaultUrl(keyVaultUrl)
                .credential(new DefaultAzureCredentialBuilder().build())
                .buildClient();
        KeyVaultSecret secret = client.getSecret(secretName);
    }
}

import { DefaultAzureCredential } from "@azure/identity";
import { SecretClient } from "@azure/keyvault-secrets";

const main = async () => {
    const keyVaultUrl = process.env["KEYVAULT_URL"];
    const secretName = process.env["SECRET_NAME"];

    const credential = new DefaultAzureCredential();
    const client = new SecretClient(keyVaultUrl, credential);

    const secret = await client.getSecret(secretName);
}

main().catch((error) => {
    console.error("An error occurred:", error);
    process.exit(1);
});

import os

from azure.keyvault.secrets import SecretClient
from azure.identity import DefaultAzureCredential

def main():
    keyvault_url = os.getenv('KEYVAULT_URL', '')
    secret_name = os.getenv('SECRET_NAME', '')

    client = SecretClient(vault_url=keyvault_url, credential=DefaultAzureCredential())
    secret = client.get_secret(secret_name)

if __name__ == '__main__':
    main()

Bibliothèque d’authentification Microsoft (MSAL)

Les bibliothèques de client suivantes sont la version minimale demandée.

Écosystème	Bibliothèque	Image	Exemple	A Windows
.NET	Bibliothèque d’authentification Microsoft pour .NET	`ghcr.io/azure/azure-workload-identity/msal-net:latest`	Lien	Oui
Go	Bibliothèque d’authentification Microsoft pour Go	`ghcr.io/azure/azure-workload-identity/msal-go:latest`	Lien	Oui
Java	Bibliothèque d’authentification Microsoft pour Java	`ghcr.io/azure/azure-workload-identity/msal-java:latest`	Lien	Non
JavaScript	Bibliothèque d’authentification Microsoft pour JS	`ghcr.io/azure/azure-workload-identity/msal-node:latest`	Lien	Non
Python	Bibliothèque d’authentification Microsoft pour Python	`ghcr.io/azure/azure-workload-identity/msal-python:latest`	Lien	Non

Limites

Vous pouvez avoir un maximum de 20 informations d’identification d’identité fédérée par identité managée.
Il faut quelques secondes pour que les informations d’identification d’identité fédérée soient propagées après avoir été ajoutées initialement.
Le module complémentaire Nœuds virtuels, basé sur le projet open source Virtual Kubelet, n’est pas pris en charge.
La création d’informations d’identification d’identité fédérée n’est pas prise en charge sur les identités managées affectées par l’utilisateur dans ces régions.

Fonctionnement

Dans ce modèle de sécurité, le cluster AKS agit en tant qu’émetteur de jeton. Microsoft Entra ID utilise OpenID Connect pour découvrir les clés de signature publiques et pour vérifier l’authenticité du jeton du compte de service avant de l’échanger contre un jeton Microsoft Entra. Votre charge de travail peut échanger un jeton de compte de service projeté sur son volume contre un jeton Microsoft Entra en utilisant la bibliothèque de client Azure Identity ou la bibliothèque d’authentification Microsoft (MSAL).

Le tableau suivant décrit les points de terminaison de l’émetteur OIDC requis pour Microsoft Entra Workload ID :

Point de terminaison	Description
`{IssuerURL}/.well-known/openid-configuration`	Également appelé document de découverte OIDC. Il contient les métadonnées relatives aux configurations de l’émetteur.
`{IssuerURL}/openid/v1/jwks`	Il contient la ou les clés de signature publiques que Microsoft Entra ID utilise pour vérifier l’authenticité du jeton de compte de service.

Le diagramme suivant récapitule la séquence d’authentification à l’aide d’OpenID Connect.

Rotation automatique des certificats Webhook

À l’instar des autres modules complémentaires webhook, le certificat est retourné du fait de l’opération de rotation automatique du certificat de cluster.

Étiquettes et annotations de compte de service

Microsoft Entra Workload ID prend en charge les mappages suivants liés à un compte de service :

Un-à-un, où un compte de service fait référence un objet Microsoft Entra.
Plusieurs-à-un, où plusieurs comptes de service font référence au même objet Microsoft Entra.
Un-à-plusieurs, où un compte de service fait référence à plusieurs objets Microsoft Entra en modifiant l’annotation de l’ID client. Pour plus d’informations, consultez Comment fédérer plusieurs identités avec un compte de service Kubernetes.

Remarque

Si les annotations de compte de service sont mises à jour, vous devez redémarrer le pod pour que les modifications prennent effet.

Si vous avez utilisé une identité managée par pod Microsoft Entra, vous pouvez considérez un compte de service comme un principal de sécurité Azure, sauf qu’un compte de service fait partie de l’API Kubernetes principale, au lieu d’être une définition de ressource personnalisée (CRD). Les sections suivantes décrivent une liste des étiquettes et annotations disponibles qui peuvent être utilisées pour configurer le comportement lors de l’échange du jeton de compte de service contre un jeton d’accès Microsoft Entra.

Annotations de compte de service

Toutes les annotations sont facultatives. Si l’annotation n’est pas spécifiée, la valeur par défaut est utilisée.

Annotation	Description	Default
`azure.workload.identity/client-id`	Représente l’application Microsoft Entra Azure à utiliser avec le pod.
`azure.workload.identity/tenant-id`	Représente l’ID de locataire Azure où L’application Microsoft Entra est inscrite.	Variable d’environnement AZURE_TENANT_ID extraite de ConfigMap `azure-wi-webhook-config`.
`azure.workload.identity/service-account-token-expiration`	Représente le champ `expirationSeconds` pour le jeton de compte de service projeté. Il s’agit d’un champ facultatif que vous configurez pour éviter les temps d’arrêt occasionnés par des erreurs survenant lors de l’actualisation du jeton de compte de service. L’expiration du jeton de compte de service Kubernetes n’est pas corrélée avec les jetons Microsoft Entra. Les jetons Microsoft Entra expirent dans les 24 heures suivant leur émission.	3600 La plage prise en charge est 3600-86400.

Étiquettes du pod

Remarque

Pour les applications utilisant l’identité de charge de travail, il nécessaire d’ajouter l’étiquette azure.workload.identity/use: "true" à la spécification du pod pour que AKS déplace l’identité de charge de travail vers un scénario de Fail Close afin de fournir un comportement cohérent et fiable aux pods qui doivent utiliser l’identité de charge de travail. Dans le cas contraire, les pods échouent après avoir été redémarrés.

Libellé	Description	Valeur recommandée	Requis
`azure.workload.identity/use`	Cette étiquette est nécessaire dans la spécification de modèle de pod. Seuls les pods avec cette étiquette sont mutés par le webhook d’admission de mutation azure-workload-identity pour injecter les variables d’environnement spécifiques à Azure et le volume de jeton projeté du compte de service.	true	Oui

Annotations de pod

Toutes les annotations sont facultatives. Si l’annotation n’est pas spécifiée, la valeur par défaut est utilisée.

Annotation	Description	Default
`azure.workload.identity/service-account-token-expiration`	Représente le champ `expirationSeconds` pour le jeton de compte de service projeté. Il s’agit d’un champ facultatif que vous configurez pour éviter tout temps d’arrêt résultant d’erreurs lors de l’actualisation du jeton de compte de service. L’expiration du jeton de compte de service Kubernetes n’est pas corrélée avec les jetons Microsoft Entra. Les jetons Microsoft Entra expirent dans les 24 heures suivant leur émission. ¹	3600 La plage prise en charge est 3600-86400.
`azure.workload.identity/skip-containers`	Représente une liste de conteneurs séparés par des points-virgules pour ignorer l’ajout d’un volume de jeton de compte de service projeté. Par exemple : `container1;container2`.	Par défaut, le volume de jeton de compte de service projeté est ajouté à tous les conteneurs si le pod est étiqueté avec `azure.workload.identity/use: true`.
`azure.workload.identity/inject-proxy-sidecar`	Injecte un conteneur init de proxy et un sidecar de proxy dans le pod. Le proxy sidecar est utilisé pour intercepter des requêtes de jetons adressées à IMDS et acquérir un jeton Microsoft Entra pour le compte de l’utilisateur avec des informations d’identification d’identité fédérée.	true
`azure.workload.identity/proxy-sidecar-port`	Représente le port du sidecar de proxy.	8000

¹ Est prioritaire si le compte de service est également annoté.

Comment migrer vers ID de charge de travail Microsoft Entra

Vous pouvez configurer un cluster exécutant déjà une identité managée par pod pour utiliser une identité de charge de travail de deux façons. La première option vous permet d’utiliser la configuration que celle que vous avez implémentée pour l’identité managée par pod. Vous devez annoter le compte de service dans l’espace de noms avec l’identité pour activer ID de charge de travail Microsoft Entra et injecter les annotations dans les pods.

La deuxième option consiste à réécrire votre application pour utiliser la dernière version de la bibliothèque de client Azure Identity.

Pour simplifier et faciliter le processus de migration, nous avons développé un sidecar de migration qui convertit les transactions IMDS que votre application effectue sur OpenID Connect (OIDC). Le sidecar de migration n’est pas destiné à être une solution à long terme, mais un moyen d’être rapidement opérationnel pour l’identité de charge de travail. L’exécution du sidecar de migration dans votre application achemine les transactions IMDS de l’application vers OIDC. L’autre approche consiste à opérer une mise à niveau vers une version prise en charge de la bibliothèque de client Azure Identity qui prend en charge l’authentification OIDC.

Le tableau suivant récapitule nos recommandations de migration ou de déploiement pour une identité de charge de travail.

Scénario	Description
Un déploiement de cluster nouveau ou existant exécute une version prise en charge de la bibliothèque de client Azure Identity	Aucune étape de migration n’est requise. Exemples de ressources de déploiement : Déployer et configurer une identité de charge de travail sur un nouveau cluster
Un déploiement de cluster nouveau ou existant exécute une version non prise en charge de la bibliothèque de client Azure Identity	Mettez à jour l’image conteneur pour utiliser une version prise en charge du Kit de développement logiciel (SDK) Azure Identity, ou utilisez le sidecar de migration.

Étapes suivantes

Pour savoir comment configurer votre pod pour s’authentifier à l’aide d’une identité de charge de travail comme option de migration, consultez Moderniser l’authentification d’application avec une identité de charge de travail.
Consultez Déployer et configurer un cluster AKS avec une identité de charge de travail, qui vous aide à déployer un cluster Azure Kubernetes Service et à configurer un exemple d’application pour utiliser une identité de charge de travail.

Partager via

Utiliser Microsoft Entra Workload ID avec Azure Kubernetes Service (AKS)

Dépendances

Bibliothèques clientes d’identité Azure

Bibliothèque d’authentification Microsoft (MSAL)

Limites

Fonctionnement

Rotation automatique des certificats Webhook

Étiquettes et annotations de compte de service

Annotations de compte de service

Étiquettes du pod

Annotations de pod

Comment migrer vers ID de charge de travail Microsoft Entra

Étapes suivantes

Ressources supplémentaires