Verwenden der Microsoft Entra-Workload-ID mit Azure Kubernetes Service (AKS)

Artikel
08/02/2024

Workloads, die in einem Azure Kubernetes Services(AKS)-Cluster bereitgestellt werden, erfordern Microsoft Entra-Anwendungsanmeldeinformationen oder verwaltete Identitäten, um auf geschützte Microsoft Entra-Ressourcen wie Azure Key Vault und Microsoft Graph zuzugreifen. Die Microsoft Entra-Workload-ID lässt sich in die nativen Funktionen von Kubernetes integrieren, um mit externen Identitätsanbietern einen Verbund zu bilden.

Microsoft Entra Workload ID verwendet die Volumeprojektion für Dienstkontotoken (also ein Dienstkonto), damit Pods eine Kubernetes-Identität verwenden können. Ein Kubernetes-Token wird ausgegeben, und der OIDC-Verbund ermöglicht Kubernetes-Anwendungen den sicheren Zugriff auf Azure-Ressourcen mit Microsoft Entra ID basierend auf mit Anmerkungen versehenen Dienstkonten.

Microsoft Entra Workload ID funktioniert besonders gut mit den Azure Identity-Clientbibliotheken oder der Sammlung der Microsoft Authentication Library (MSAL), wenn Sie die Anwendungsregistrierung verwenden. Ihre Workload kann eine dieser Bibliotheken verwenden, um Azure-Cloudressourcen nahtlos zu authentifizieren und darauf zuzugreifen.

Dieser Artikel hilft Ihnen dabei, Microsoft Entra Workload ID kennenzulernen und die verfügbaren Optionen zur Planung Ihrer Projektstrategie und einer möglichen Migration von einer podseitig verwalteten Microsoft Entra-Identität zu prüfen.

Hinweis

Sie können den Dienstconnector verwenden, um einige Schritte automatisch zu konfigurieren. Siehe auch: Was ist der Dienstconnector?

Abhängigkeiten

AKS unterstützt Microsoft Entra-Workload-IDs ab Version 1.22.
Azure CLI-Version 2.47.0 oder höher. Führen Sie az --version aus, um die Version zu finden, und führen Sie az upgrade aus, um ein Upgrade für die Version durchzuführen. Informationen zum Durchführen einer Installation oder eines Upgrades finden Sie bei Bedarf unter Installieren der Azure CLI.

Azure Identity-Clientbibliotheken

Wählen Sie in den Azure Identity-Clientbibliotheken einen der folgenden Ansätze aus:

Verwenden Sie DefaultAzureCredential, die versucht, die WorkloadIdentityCredential zu verwenden.
Erstellen Sie eine ChainedTokenCredential-Instanz, die WorkloadIdentityCredential enthält.
Verwenden Sie WorkloadIdentityCredential direkt.

Die folgende Tabelle enthält die Mindestpaketversion, die für die Clientbibliothek der einzelnen Sprach-Ökosysteme erforderlich ist.

Ökosystem	Bibliothek	Mindestversion
.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

In den folgenden Codebeispielen DefaultAzureCredential wird verwendet. Dieser Anmeldeinformationstyp verwendet die Umgebungsvariablen, die vom Webhook zum Ändern der Azure-Workloadidentität eingeschleust werden, um sich bei Azure Key Vault zu authentifizieren.

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)

Die folgenden Clientbibliotheken sind die erforderliche Mindestversion.

Ökosystem	Bibliothek	Image	Beispiel	Verfügt über Windows
.NET	microsoft-authentication-library-for-dotnet	`ghcr.io/azure/azure-workload-identity/msal-net:latest`	Link	Ja
Go	microsoft-authentication-library-for-go	`ghcr.io/azure/azure-workload-identity/msal-go:latest`	Link	Ja
Java	microsoft-authentication-library-for-java	`ghcr.io/azure/azure-workload-identity/msal-java:latest`	Link	Nein
JavaScript	microsoft-authentication-library-for-js	`ghcr.io/azure/azure-workload-identity/msal-node:latest`	Link	Nein
Python	microsoft-authentication-library-for-python	`ghcr.io/azure/azure-workload-identity/msal-python:latest`	Link	Nein

Begrenzungen

Jede verwaltete Identität kann nur 20 Anmeldeinformationen für Verbundidentitäten aufweisen.
Es dauert einige Sekunden, bis die Verbundidentitäts-Anmeldeinformationen nach dem erstmaligen Hinzufügen weitergegeben werden.
Das Add-On für virtuelle Knoten, das auf dem Open-Source-Projekt Virtual Kubelet basiert, wird nicht unterstützt.
In den folgenden Regionen wird die Erstellung von Anmeldeinformationen für Verbundidentitäten für benutzerseitig zugewiesene verwaltete Identitäten nicht unterstützt.

Funktionsweise

In diesem Sicherheitsmodell fungiert der AKS-Cluster als Tokenaussteller. Microsoft Entra ID verwendet OpenID Connect, um öffentliche Signaturschlüssel zu ermitteln und die Authentizität des Dienstkontotokens zu überprüfen, bevor es gegen ein Microsoft Entra-Token ausgetauscht wird. Ihre Workload kann mithilfe der Azure Identity-Clientbibliothek oder der Microsoft Authentication Library (MSAL) ein auf ihr Volume projiziertes Dienstkontotoken gegen ein Microsoft Entra-Token austauschen.

In der folgenden Tabelle werden die erforderlichen OIDC-Ausstellerendpunkte für die Microsoft Entra-Workload-ID beschrieben:

Endpunkt	BESCHREIBUNG
`{IssuerURL}/.well-known/openid-configuration`	Auch als OIDC-Ermittlungsdokument bezeichnet. Es enthält die Metadaten zu den Konfigurationen des Ausstellers.
`{IssuerURL}/openid/v1/jwks`	Es enthält die öffentlichen Signaturschlüssel, die Microsoft Entra ID verwendet, um die Authentizität des Dienstkontotokens zu überprüfen.

Im folgenden Diagramm wird die Authentifizierungssequenz mit OpenID Connect zusammengefasst dargestellt.

Automatische Webhook-Zertifikatrotation

Ähnlich wie bei anderen Webhook-Add-Ons wird das Zertifikat durch automatische Rotation des Clusterzertifikats rotiert.

Dienstkontobezeichnungen und -anmerkungen

Die Microsoft Entra-Workload-ID unterstützt die folgenden Zuordnungen im Zusammenhang mit einem Dienstkonto:

1:1, wobei ein Dienstkonto auf ein Microsoft Entra-Objekt verweist
n:1, wobei mehrere Dienstkonten auf dasselbe Microsoft Entra-Objekt verweisen
1:n, wobei ein Dienstkonto auf mehrere Microsoft Entra-Objekte verweist, indem die Client-ID-Anmerkung geändert wird. Weitere Informationen finden Sie unter Verbinden mehrerer Identitäten mit einem Kubernetes-Dienstkonto.

Hinweis

Wenn die Anmerkungen des Dienstkontos aktualisiert werden, müssen Sie den Pod neu starten, damit die Änderungen wirksam werden.

Wenn Sie eine podseitig verwaltete Microsoft Entra-Identität verwendet haben, können Sie sich das Dienstkonto wie einen Azure-Dienstprinzipal vorstellen, mit dem Unterschied, dass ein Dienstkonto Teil der Kubernetes-Kern-API ist und keine benutzerdefinierte Ressourcendefinition. Die folgenden Abschnitte enthalten eine Liste der verfügbaren Bezeichnungen und Anmerkungen, die zum Konfigurieren des Verhaltens beim Austausch des Dienstkontotokens gegen ein Microsoft Entra-Zugriffstoken verwendet werden können.

Dienstkontoanmerkungen

Alle Anmerkungen sind optional. Wenn die Anmerkung nicht angegeben ist, wird der Standardwert verwendet.

Anmerkung	BESCHREIBUNG	Standard
`azure.workload.identity/client-id`	Stellt die Client-ID der Microsoft Entra-Anwendung dar die mit dem Pod verwendet werden soll.
`azure.workload.identity/tenant-id`	Stellt die Azure-Mandanten-ID dar, in der die Microsoft Entra-Anwendung registriert ist.	Umgebungsvariable AZURE_TENANT_ID, aus ConfigMap `azure-wi-webhook-config` extrahiert
`azure.workload.identity/service-account-token-expiration`	Stellt das Feld `expirationSeconds` für das projizierte Dienstkontotoken dar. Es ist ein optionales Feld, das Sie konfigurieren können, um Ausfallzeiten zu verhindern, die durch Fehler während der Aktualisierung des Dienstkontotokens verursacht werden. Ablaufdatum des Kubernetes-Dienstkontotokens korreliert nicht mit Microsoft Entra-Token. Microsoft Entra-Token sind 24 Stunden gültig, nachdem sie ausgestellt wurden.	3600 Der unterstützte Bereich ist 3600-86400.

Podbezeichnungen

Hinweis

Für Anwendungen, die eine Workloadidentität verwenden, muss die Bezeichnung azure.workload.identity/use: "true" zu den Podspezifikationen für AKS hinzugefügt werden. So kann AKS die Workloadidentität in ein Szenario vom Typ Fail Close überführen, um für Pods, die die Workloadidentität verwenden müssen, ein konsistentes und zuverlässiges Verhalten zu gewährleisten. Andernfalls schlagen die Pods nach dem Neustart fehl.

Bezeichnung	BESCHREIBUNG	Empfohlener Wert	Erforderlich
`azure.workload.identity/use`	Diese Bezeichnung ist in der Podvorlagenspezifikation erforderlich. Nur Pods mit dieser Bezeichnung werden durch den Webhook für mutierende Zulassungen „azure-workload-identity“ verändert, um die Azure-spezifischen Umgebungsvariablen und das angepasste Dienstkontotoken-Volumen einzuschleusen.	true	Ja

Podanmerkungen

Alle Anmerkungen sind optional. Wenn die Anmerkung nicht angegeben ist, wird der Standardwert verwendet.

Anmerkung	BESCHREIBUNG	Standard
`azure.workload.identity/service-account-token-expiration`	Stellt das `expirationSeconds`-Feld für das projizierte Dienstkontotoken dar. Es ist ein optionales Feld, das Sie konfigurieren können, um Ausfallzeiten zu verhindern, die durch Fehler während der Aktualisierung des Dienstkontotokens verursacht werden. Ablaufdatum des Kubernetes-Dienstkontotokens korreliert nicht mit Microsoft Entra-Token. Microsoft Entra-Token sind 24 Stunden gültig, nachdem sie ausgestellt wurden. ¹	3600 Der unterstützte Bereich ist 3600-86400.
`azure.workload.identity/skip-containers`	Stellt eine durch Semikolons getrennte Containerliste dar, um das Hinzufügen von projizierten Dienstkontotokenvolumes zu überspringen. Beispiel: `container1;container2`.	Standardmäßig wird das projizierte Dienstkontotokenvolume allen Containern hinzugefügt, wenn das Dienstkonto die Bezeichnung `azure.workload.identity/use: true` hat.
`azure.workload.identity/inject-proxy-sidecar`	Fügt einen Proxy-Init-Container und einen Proxy-Sidecar in den Pod ein. Der Proxy-Sidecar wird verwendet, um Tokenanforderungen an IMDS abzufangen und ein Microsoft Entra-Token im Auftrag des Benutzers bzw. der Benutzerin mit Anmeldeinformationen für eine Verbundidentität zu erwerben.	true
`azure.workload.identity/proxy-sidecar-port`	Stellt den Port des Proxy-Sidecars dar.	8.000

¹ Hat Vorrang, wenn das Dienstkonto ebenfalls mit der Anmerkung versehen ist.

Migrieren zu Microsoft Entra Workload ID

Sie können einen Cluster, der bereits eine podseitig verwaltete Identität ausführt, auf zwei Arten für die Verwendung der Workloadidentität konfigurieren. Die erste Option ermöglicht es Ihnen, die gleiche Konfiguration zu verwenden, die Sie für die podseitig verwaltete Identität implementiert haben. Sie können dem Dienstkonto im Namespace eine Anmerkung mit der Identität hinzufügen, um Microsoft Entra Workload ID zu aktivieren und die Anmerkungen in die Pods einzufügen.

Die zweite Option besteht darin, Ihre Anwendung neu zu schreiben, um die neueste Version der Azure Identity-Clientbibliothek zu verwenden.

Zur Optimierung und Vereinfachung des Migrationsprozesses haben wir einen Migrations-Sidecar entwickelt, der die IMDS-Transaktionen konvertiert, die Ihre Anwendung in OpenID Connect (OIDC) erstellt. Der Migrations-Sidecar ist nicht als langfristige Lösung gedacht, sondern als eine Möglichkeit, Workloadidentitäten schnell einzurichten und auszuführen. Wenn Sie den Migrations-Sidecar innerhalb Ihrer Anwendung ausführen, werden die IMDS-Transaktionen der Anwendung an OIDC weitergeleitet. Ein anderer Ansatz besteht darin, ein Upgrade einer unterstützten Version der Azure Identity-Clientbibliothek durchzuführen, die die OIDC-Authentifizierung unterstützt.

In der folgenden Tabelle werden unsere Migrations- bzw. Bereitstellungsempfehlungen für die Workloadidentität zusammengefasst.

Szenario	BESCHREIBUNG
Neue oder vorhandene Clusterbereitstellung führt eine unterstützte Version der Azure Identity-Clientbibliothek aus.	Es sind keine Migrationsschritte erforderlich. Beispielbereitstellungsressourcen: Bereitstellen und Konfigurieren der Workloadidentität auf einem neuen Cluster
Neue oder vorhandene Clusterbereitstellung führt eine nicht unterstützte Version der Azure Identity-Clientbibliothek aus.	Aktualisieren Sie das Containerimage, um eine unterstützte Version des Azure Identity SDK zu verwenden, oder verwenden Sie den Migrations-Sidecar.

Nächste Schritte

Weitere Informationen zum Einrichten Ihres Pods zur Authentifizierung mithilfe einer Workloadidentität als Migrationsoption finden Sie unter Modernisieren der Anwendungsauthentifizierung mit Workloadidentität.
Weitere Informationen zum Bereitstellen eines Azure Kubernetes Service-Clusters und Konfigurieren einer Beispielanwendung für die Verwendung einer Workloadidentität finden Sie unter Bereitstellen und Konfigurieren eines AKS-Clusters mit einer Workloadidentität.

Freigeben über

Verwenden der Microsoft Entra-Workload-ID mit Azure Kubernetes Service (AKS)

Abhängigkeiten

Azure Identity-Clientbibliotheken

Microsoft Authentication Library (MSAL)

Begrenzungen

Funktionsweise

Automatische Webhook-Zertifikatrotation

Dienstkontobezeichnungen und -anmerkungen

Dienstkontoanmerkungen

Podbezeichnungen

Podanmerkungen

Migrieren zu Microsoft Entra Workload ID

Nächste Schritte

Zusätzliche Ressourcen