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

Artikel
11/17/2023

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.

Die Microsoft Entra-Workload-ID verwendet die Volumenprojektion des Dienstkontotokens, damit Pods eine Kubernetes-Identität (also ein Dienstkonto) 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.

Die Microsoft Entra-Workload-ID funktioniert besonders gut mit den Azure Identity-Clientbibliotheken und der Microsoft-Authentifizierungsbibliothek (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, dieses neue Authentifizierungsfeature 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

Anstatt alle Schritte manuell zu konfigurieren, gibt es eine weitere Implementierung namens Dienstconnector, die Ihnen dabei hilft, 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

Einschränkungen

Sie können nur über 20 Verbundidentitätsanmeldeinformationen pro verwalteter Identität verfügen.
Es dauert einige Sekunden, bis die Verbundidentitäts-Anmeldeinformationen nach dem erstmaligen Hinzufügen weitergegeben werden.
Das Add-On 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-Authentifizierungsbibliothek ein ihrem Volumen angepasstes Dienstkontotoken gegen ein Microsoft Entra-Token austauschen.

Diagramm des AKS-Identitätssicherheitsmodells

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.

Diagramm der OIDC-Authentifizierungssequenz der AKS-Workloadidentität

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 – Ein Dienstkonto verweist auf ein Microsoft Entra-Objekt.
n:1 – Mehrere Dienstkonten verweisen auf dasselbe Microsoft Entra-Objekt.
1:n – Ein Dienstkonto verweist auf mehrere Microsoft Entra-Objekte, 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 eine Azure-Identität vorstellen, mit dem Unterschied, dass ein Dienstkonto Teil der Kern-Kubernetes-API ist und keine benutzerdefinierte Ressourcendefinition (Custom Ressource Definition, CRD). Im Folgenden sehen Sie 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.

So migrieren Sie die Workloadidentität

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 heute für die podseitig verwaltete Identität implementiert haben. Dazu müssen Sie dem Dienstkonto im Namespace lediglich eine Anmerkung mit der Identität hinzufügen, und schon kann die Workloadidentität die Anmerkungen in die Pods einfü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. Beispiele für Bereitstellungsressourcen: - Bereitstellen und Konfigurieren der Workloadidentität auf einem neuen Cluster - Tutorial: Verwenden einer Workloadidentität mit einer Anwendung in AKS
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 zum Konfigurieren einer Beispielanwendung für die Verwendung einer Workloadidentität finden Sie im Tutorial Verwenden einer Workloadidentität mit einer Anwendung auf Azure Kubernetes Service (AKS).

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

Abhängigkeiten

Azure Identity-Clientbibliotheken

Microsoft Authentication Library (MSAL)

Einschränkungen

Funktionsweise

Automatische Webhook-Zertifikatrotation

Dienstkontobezeichnungen und -anmerkungen

Dienstkontoanmerkungen

Podbezeichnungen

Podanmerkungen

So migrieren Sie die Workloadidentität

Nächste Schritte

Zusätzliche Ressourcen