Använda Microsoft Entra-arbetsbelastnings-ID med Azure Kubernetes Service (AKS)

Arbetsbelastningar som distribueras i ett AKS-kluster kräver autentiseringsuppgifter för Microsoft Entra-program eller hanterade identiteter för åtkomst till Microsoft Entra-skyddade resurser, till exempel Azure Key Vault och Microsoft Graph. Microsoft Entra-arbetsbelastnings-ID integreras med funktioner som är inbyggda i Kubernetes för att federera med externa identitetsprovidrar, så att du kan tilldela arbetsbelastningsidentiteter till dina arbetsbelastningar för att autentisera och komma åt andra tjänster och resurser.

Microsoft Entra Workload ID använder volymprojektion för tjänstkontotoken för att göra det möjligt för poddar att använda en Kubernetes-identitet. En Kubernetes-token utfärdas och OIDC-federationen (OpenID Connect) gör det möjligt för Kubernetes-program att komma åt Azure-resurser på ett säkert sätt med Microsoft Entra-ID, baserat på kommenterade tjänstkonton.

Du kan använda Microsoft Entra-arbetsbelastnings-ID med Azure Identity-klientbibliotek eller MSAL-samlingen ( Microsofts autentiseringsbibliotek ) tillsammans med programregistrering för att smidigt autentisera och komma åt Azure-molnresurser.

Förutsättningar

AKS automatiska kluster

I AKS Automatic-kluster är arbetsbelastningsidentitet och OIDC-utfärdaren för klustret förkonfigurerade som en del av klustrets standardsäkerhetsinställningar. Ingen konfiguration på klusternivå krävs innan du använder workload-identitet i dina poddar. Fortsätt direkt till att konfigurera ditt program.

AKS-standardkluster

• AKS stöder Microsoft Entra-arbetsbelastnings-ID på version 1.22 och senare.
• Azure CLI version 2.47.0 eller senare. Kör az --version för att hitta versionen och kör az upgrade för att uppgradera versionen. Om du behöver installera eller uppgradera kan du läsa Installera Azure CLI.
• Du måste aktivera arbetsbelastningsidentiteten och OIDC-utfärdaren i klustret innan dina poddar kan använda arbetsbelastningsidentitet. Se Distribuera och konfigurera arbetsbelastningsidentitet i ett AKS-kluster.

Begränsningar

• Du kan ha högst 20 federerade identitetsuppgifter per hanterad identitet.
• Det tar några sekunder innan den federerade identitetsautentiseringsuppgiften sprids efter att den först har lagts till.
• Tillägget virtuella noder , baserat på projektet Virtual Kubelet med öppen källkod, stöds inte.
• Skapande av federerade identitetsuppgifter stöds inte för användartilldelade hanterade identiteter i dessa regioner.

Azure Identity-klientbibliotek

I Azure Identity-klientbiblioteken väljer du någon av följande metoder:

• Använd DefaultAzureCredential, som försöker använda WorkloadIdentityCredential.
• Skapa en ChainedTokenCredential instans som innehåller WorkloadIdentityCredential.
• Använd WorkloadIdentityCredential direkt.

När du begär token med WorkloadIdentityCredential, anger du omfång i Microsoft Entra ID v2-formatet <resource>/.default till exempel https://management.azure.com/.default. En rå resurs-URI, till exempel https://management.azure.com/, kan misslyckas eftersom workloadidentitet använder Microsoft Entra v2-token-slutpunkten i stället för IMDS-resourceflödet som används av hanterad identitet. Mer information om hur scope fungerar i v2-slutpunkten för token finns i Hämta en token.

Följande tabell innehåller den lägsta paketversion som krävs för varje språkekosystems klientbibliotek:

Kodexempel för Azure Identity-klientbibliotek

Följande kodexempel använder DefaultAzureCredential. Den här typen av autentiseringsuppgifter använder miljövariablerna som injiceras av arbetsbelastningsidentitetens muterande webhook för att autentisera med Azure Key Vault. Om du vill se exempel med någon av de andra metoderna kan du läsa de ekosystemspecifika klientbiblioteken.

Ersätt <key-vault-url> och <secret-name> med lämpliga värden för din Key Vault och hemlighet.

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()

Microsofts autentiseringsbibliotek (MSAL)

Följande klientbibliotek är den lägsta version som krävs:

Hur det fungerar

I den här säkerhetsmodellen fungerar AKS-klustret som tokenutfärdare. Microsoft Entra ID använder OIDC för att identifiera offentliga signeringsnycklar och verifiera autenticiteten för tjänstkontotoken innan du utbyter den mot en Microsoft Entra-token. Ditt arbetsflöde kan byta ut en tjänstkontotoken som används i dess volym mot en Microsoft Entra-token med hjälp av Azure Identity client library eller MSAL.

I följande tabell beskrivs de nödvändiga OIDC-utfärdarslutpunkterna för Microsoft Entra-arbetsbelastnings-ID:

Följande diagram sammanfattar autentiseringssekvensen med OIDC:

Automatisk rotation av Webhook-certifikat

På samma sätt som andra webhook-tillägg roterar åtgärden automatisk rotation av klustercertifikatet certifikatet för workload identity-webhooken.

Tjänstkontoetiketter och anteckningar

Microsoft Entra-arbetsbelastnings-ID stöder följande mappningar relaterade till ett tjänstkonto:

• En-till-en, där ett tjänstkonto refererar till ett Microsoft Entra-objekt.
• Många-till-en, där flera tjänstkonton refererar till samma Microsoft Entra-objekt.
• En-till-många, där ett tjänstkonto refererar till flera Microsoft Entra-objekt genom att ändra klient-ID-annoteringen. Mer information finns i Så här federerar du flera identiteter med ett Kubernetes-tjänstkonto.

Om du har använt Microsoft Entra-poddhanterad identitet bör du tänka på ett tjänstkonto som ett Azure-säkerhetsobjekt, men ett tjänstkonto är en del av Kubernetes-kärn-API:et i stället för en anpassad resursdefinition (CRD). I följande avsnitt beskrivs en lista över tillgängliga etiketter och anteckningar som du kan använda för att konfigurera beteendet när du utbyter tjänstkontotoken mot en Microsoft Entra-åtkomsttoken.

Anteckningar för tjänstkonto

Alla anteckningar är valfria. Om anteckningen inte har angetts används standardvärdet.

Poddetiketter

Pod-anmärkningar

Alla anteckningar är valfria. Om anteckningen inte har angetts används standardvärdet.

Använda identitetsbindningar och direkt federation i samma arbetsbelastning

Identitetskopplingar är en funktion i förhandsversion som utökar stödet för arbetsbelastningsidentitet för att stödja storskaliga AKS-miljöer. I stället för att skapa en federerad identitetsautentiseringsuppgift (FIC) för varje kluster låter identitetsbindningar flera kluster dela en enda användartilldelad hanterad identitet via en FIC. När det är aktiverat dirigerar AKS poddtokenbegäranden via en webbhook för identitetsbindningsproxy som hanterar tokenutbyte för arbetsbelastningens räkning.

En projicerad token för tjänstkonto har en enda målgrupp. När identitetsbindningar är aktiverade anger webhooken för identitetsbindning standardtoken som refereras av AZURE_FEDERATED_TOKEN_FILE till målgruppen api://AKSIdentityBinding, som identitetsbindningsproxyn använder.

Direkt Microsoft Entra Workload ID-federering (utan identitetsbindningar) kräver en token med målgruppen api://AzureADTokenExchange. Det går AADSTS700212 inte att återanvända tokenfilen för identitetsbindning för direkt federation eftersom målgruppen för federerade identitetsautentiseringsuppgifter inte matchar tokenpubliken.

Om du vill använda identitetsbindningar för en hanterad identitet och direkt federation för en annan i samma arbetsbelastning, projicerar du en andra tjänstkontotoken med målgruppen api://AzureADTokenExchange och pekar den direkta federationskoden på filen:

apiVersion: v1
kind: Pod
metadata:
  name: workload-with-ib-and-direct-fic
  labels:
    azure.workload.identity/use: "true"
spec:
  serviceAccountName: workload-sa
  containers:
  - name: app
    image: <image>
    volumeMounts:
    - name: direct-fic-token
      mountPath: /var/run/secrets/direct-fic
      readOnly: true
    env:
    - name: DIRECT_FIC_TOKEN_FILE
      value: /var/run/secrets/direct-fic/token
  volumes:
  - name: direct-fic-token
    projected:
      sources:
      - serviceAccountToken:
          path: token
          audience: api://AzureADTokenExchange
          expirationSeconds: 3600

Används AZURE_FEDERATED_TOKEN_FILE för identitetsbindningsflödet och den anpassade tokenfilen, till exempel DIRECT_FIC_TOKEN_FILE, för flödet för direkt federerade identitetsautentiseringsuppgifter.

Migrera till Microsoft Entra-arbetsbelastnings-ID

Du kan konfigurera kluster som redan kör en poddhanterad identitet för att använda Microsoft Entra-arbetsbelastnings-ID på något av två sätt:

• Använd samma konfiguration som du implementerade för podhanterad identitet. Du kan annotera tjänstkontot inom namnområdet med identiteten för att aktivera Microsoft Entra Workload-ID och injicera annotationerna i poddarna.
• Skriv om programmet så att det använder den senaste versionen av Azure Identity-klientbiblioteket.

För att effektivisera och underlätta migreringsprocessen har vi utvecklat en sidovagn för migrering som konverterar imds-transaktionerna (Instance Metadata Service) som ditt program gör till OIDC. Migreringssidovagn är inte avsedd att vara en långsiktig lösning, utan ett sätt att komma igång snabbt med Microsoft Entra Workload ID. Genom att köra sidovagnen för migrering inom applikationen förmedlas applikationens IMDS-transaktioner till OIDC. Den alternativa metoden är att uppgradera till en version som stöds av Azure Identity-klientbiblioteket , som stöder OIDC-autentisering.

I följande tabell sammanfattas våra migrerings- eller distributionsrekommendationer för ditt AKS-kluster:

Relaterat innehåll

• Information om hur du konfigurerar podden för att autentisera med hjälp av en arbetsbelastningsidentitet som migreringsalternativ finns i Modernisera programautentisering med Microsoft Entra-arbetsbelastnings-ID.
• Se Distribuera och konfigurera ett AKS-kluster med Microsoft Entra-arbetsbelastnings-ID, som hjälper dig att distribuera ett kluster och konfigurera ett exempelprogram för att använda en arbetsbelastningsidentitet.
• Mer information om AKS Automatics förkonfigurerade säkerhetsstandarder, inklusive arbetsbelastningsidentitet, finns i Vad är Azure Kubernetes Service Automatisk?