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

Les charges de travail déployées sur un cluster AKS nécessitent des informations d’identification d’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. L’ID de charge de travail Microsoft Entra s’intègre aux fonctionnalités natives de Kubernetes pour fédérer avec des fournisseurs d’identité externes, ce qui vous permet d’affecter des identités de charge de travail à vos charges de travail pour authentifier et accéder à d’autres services et ressources.

L’ID de charge de travail Microsoft Entra utilise la projection de volume de jetons de compte de service (ou un compte de service) pour permettre aux pods d’utiliser une identité Kubernetes. Un jeton Kubernetes est émis et la fédération OpenID Connect (OIDC) permet aux applications Kubernetes d’accéder en toute sécurité aux ressources Azure avec l’ID Microsoft Entra, en fonction des comptes de service annotés.

Vous pouvez utiliser l’ID de charge de travail Microsoft Entra avec les bibliothèques clientes Azure Identity ou la collection MSAL (Microsoft Authentication Library), ainsi que l’inscription d’application, pour authentifier et accéder en toute transparence aux ressources cloud Azure.

Prerequisites

• 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.

Limites

• Vous pouvez avoir un maximum de 20 informations d’identification d’identité fédérée par identité managée.
• La propagation de l'identifiant fédéré prend quelques secondes après son ajout initial.
• Le module complémentaire de 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 gérées attribuées par l’utilisateur dans ces régions.

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 minimale du package requise pour la bibliothèque cliente de chaque écosystème de langage :

Exemples de code de bibliothèque de client Azure Identity

Les exemples de code suivants utilisent le DefaultAzureCredential. Ce type d’informations d’identification utilise les variables d’environnement injectées par l’identité de charge de travail mutant le webhook pour s’authentifier auprès d’Azure Key Vault. Pour afficher des exemples à l’aide de l’une des autres approches, reportez-vous aux bibliothèques clientes spécifiques à l’écosystème.

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

string keyVaultUrl = Environment.GetEnvironmentVariable("<key-vault-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("<key-vault-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("<key-vault-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("<key-vault-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["<key-vault-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('<key-vault-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 clientes suivantes sont la version minimale requise :

Fonctionnement

Dans ce modèle de sécurité, le cluster AKS agit en tant qu’émetteur de jeton. Microsoft Entra ID utilise OIDC pour découvrir les clés de signature publiques et vérifier l’authenticité du jeton du compte du service avant de l’échanger pour 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 MSAL.

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

Le diagramme suivant résume la séquence d’authentification à l’aide de l’OIDC :

Rotation automatique du certificat webhook

Comme pour d’autres modules complémentaires webhook, l’opération de rotation automatique du certificat de cluster fait pivoter le certificat.

É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 d’ID client. Pour plus d’informations, consultez Comment fédérer plusieurs identités avec un compte de service Kubernetes.

Si vous avez utilisé une identité managée par pod Microsoft Entra, pensez à un compte de service comme à un principal de sécurité Azure, sauf qu'un compte de service fait partie de l'API Kubernetes principale, plutôt qu'une définition de ressource personnalisée (CRD). Les sections suivantes décrivent une liste d’étiquettes et d’annotations disponibles que vous pouvez utiliser pour configurer le comportement lors de l’échange du jeton de compte de service pour 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.

Étiquettes du pod

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.

Migrer vers l’identifiant de charge de travail Microsoft Entra

Vous pouvez configurer des clusters qui exécutent déjà une identité managée par pod pour utiliser l’ID de charge de travail Microsoft Entra de deux façons :

• Utilisez la même 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 l’ID de charge de travail Microsoft Entra et injecter les annotations dans les pods.
• Réécrivez votre application pour utiliser la dernière version de la bibliothèque cliente Azure Identity.

Pour rationaliser et faciliter le processus de migration, nous avons développé un sidecar de migration qui convertit les transactions du Service de Métadonnées d'Instance (IMDS) que votre application effectue vers OIDC. Le side-car de migration n’est pas destiné à être une solution à long terme, mais un moyen d’être opérationnel rapidement sur l’ID de charge de travail Microsoft Entra. 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 votre cluster AKS :

É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 l’ID de charge de travail Microsoft Entra.
• Consultez Déployer et configurer un cluster AKS avec l’ID de charge de travail Microsoft Entra, ce qui vous aide à déployer un cluster et à configurer un exemple d’application pour utiliser une identité de charge de travail.