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

Arbetsbelastningar som distribueras i ett AKS-kluster (Azure Kubernetes Services) kräver microsoft Entra-programautentiseringsuppgifter eller hanterade identiteter för åtkomst till Microsoft Entra-skyddade resurser, till exempel Azure Key Vault och Microsoft Graph. Microsoft Entra Workload ID integreras med funktionerna som är inbyggda i Kubernetes för att federera med externa identitetsprovidrar.

Microsoft Entra-arbetsbelastnings-ID använder volymprojektion för tjänstkontotoken (dvs. ett tjänstkonto) för att göra det möjligt för poddar att använda en Kubernetes-identitet. En Kubernetes-token utfärdas och OIDC-federation 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.

Microsoft Entra-arbetsbelastnings-ID fungerar särskilt bra med Azure Identity-klientbiblioteken eller MSAL-samlingen (Microsoft Authentication Library ) tillsammans med programregistrering. Din arbetsbelastning kan använda något av dessa bibliotek för att smidigt autentisera och komma åt Azure-molnresurser.

Den här artikeln hjälper dig att förstå Microsoft Entra-arbetsbelastnings-ID och granskar de alternativ som är tillgängliga för att planera din projektstrategi och potentiella migrering från Microsoft Entra poddhanterad identitet.

Beroenden

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

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.

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

I följande kodexempel DefaultAzureCredential används. Den här typen av autentiseringsuppgifter använder miljövariablerna som matas in av Azure Workload Identity som muterar webhooken för att autentisera med 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()

Microsoft Authentication Library (MSAL)

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

Begränsningar

• Du kan ha högst 20 federerade identitetsuppgifter per hanterad identitet.
• När autentiseringsuppgifterna för federerade identiteter har lagts till tar det några sekunder innan de sprids.
• De virtuella noderna som läggs till, baserat på öppen källkod projektet Virtual Kubelet, stöds inte.
• Skapande av federerade identitetsuppgifter stöds inte för användartilldelade hanterade identiteter i dessa regioner.

Hur det fungerar

I den här säkerhetsmodellen fungerar AKS-klustret som tokenutfärdare. Microsoft Entra ID använder OpenID Connect för att identifiera offentliga signeringsnycklar och verifiera autenticiteten för tjänstkontotoken innan du utbyter den mot en Microsoft Entra-token. Din arbetsbelastning kan byta ut en tjänstkontotoken som projiceras till dess volym mot en Microsoft Entra-token med hjälp av Azure Identity-klientbiblioteket eller Microsoft Authentication Library (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 OpenID Connect.

Automatisk rotation av Webhook-certifikat

På samma sätt som andra webhook-tillägg roteras certifikatet av automatisk rotationsåtgärd för klustercertifikat.

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-anteckningen. 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, förutom att 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 kan användas för att konfigurera beteendet vid utbyte av tjänstkontotoken för en Microsoft Entra-åtkomsttoken.

Anteckningar för tjänstkonto

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

Poddetiketter

Poddanteckningar

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

¹ Har företräde om tjänstkontot också kommenteras.

Migrera till Microsoft Entra-arbetsbelastnings-ID

I ett kluster som redan kör en poddhanterad identitet kan du konfigurera den så att den använder arbetsbelastningsidentitet på ett av två sätt. Med det första alternativet kan du använda samma konfiguration som du har implementerat för poddhanterad identitet. Du kan kommentera tjänstkontot i namnområdet med identiteten för att aktivera Microsoft Entra-arbetsbelastnings-ID och mata in anteckningarna i poddarna.

Det andra alternativet är att skriva 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 de IMDS-transaktioner som ditt program gör till OpenID Connect (OIDC). Sidovagnen för migrering är inte avsedd att vara en långsiktig lösning, utan ett sätt att snabbt komma igång med arbetsbelastningsidentiteten. Om du kör sidovagnen för migrering i programmet skickas imds-transaktionerna över 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 arbetsbelastningsidentitet.

Nästa steg

• Information om hur du konfigurerar podden för att autentisera med hjälp av en arbetsbelastningsidentitet som migreringsalternativ finns i Modernisera programautentisering med arbetsbelastningsidentitet.
• Se Distribuera och konfigurera ett AKS-kluster med arbetsbelastningsidentitet, som hjälper dig att distribuera ett Azure Kubernetes Service-kluster och konfigurera ett exempelprogram för att använda en arbetsbelastningsidentitet.