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

Workloads, die auf einem AKS-Cluster bereitgestellt werden, erfordern Microsoft Entra-Anwendungsanmeldeinformationen oder verwaltete Identitäten für den Zugriff auf geschützte Microsoft Entra-Ressourcen, z. B. Azure Key Vault und Microsoft Graph. Die Microsoft Entra Workload-ID ist in die funktionen integriert, die für Kubernetes nativ sind, um mit externen Identitätsanbietern zu verbinden, sodass Sie Ihren Workloads Arbeitsauslastungsidentitäten zuweisen können, um andere Dienste und Ressourcen zu authentifizieren und darauf zuzugreifen.

Microsoft Entra Workload ID verwendet die Dienstkontotoken-Volumenprojektion (oder ein Dienstkonto), um Pods die Nutzung einer Kubernetes-Identität zu ermöglichen. Ein Kubernetes-Token wird ausgegeben, und der OpenID Connect (OIDC)-Partnerverbund ermöglicht Kubernetes-Anwendungen den sicheren Zugriff auf Azure-Ressourcen mit Microsoft Entra-ID basierend auf kommentierten Dienstkonten.

Sie können microsoft Entra Workload ID mit Azure Identity-Clientbibliotheken oder der MsAL-Sammlung ( Microsoft Authentication Library ) zusammen mit der Anwendungsregistrierung verwenden, um Azure Cloud-Ressourcen nahtlos zu authentifizieren und darauf zuzugreifen.

Voraussetzungen

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

Einschränkungen

• Jede verwaltete Identität kann nur 20 Anmeldeinformationen für Verbundidentitäten aufweisen.
• Es dauert ein paar Sekunden, bis der Verbundidentitätsnachweis nach dem anfänglichen Hinzufügen verbreitet wird.
• Das Add-On für virtuelle Knoten , das auf dem Open Source-Projekt Virtual Kubelet basiert, wird nicht unterstützt.
• Die Erstellung von Verbundidentitätsanmeldeinformationen wird für von Benutzern zugewiesene verwaltete Identitäten in diesen Regionen nicht unterstützt.

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 jedes Sprachökosystems erforderlich ist:

Codebeispiele für die Azure Identity-Clientbibliothek

Die folgenden Codebeispiele verwenden die DefaultAzureCredential. Dieser Typ von Anmeldeinformationen verwendet die Umgebungsvariablen, die von der Workload-Identitätsmutation Webhook injiziert werden, um sich mit Azure Key Vault zu authentifizieren. Um Beispiele mit einem der anderen Ansätze zu sehen, konsultieren Sie die ökosystemspezifischen Clientbibliotheken.

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

Microsoft Authentication Library (MSAL)

Die folgenden Clientbibliotheken sind die Mindestversion erforderlich:

Funktionsweise

In diesem Sicherheitsmodell fungiert der AKS-Cluster als Tokenaussteller. Microsoft Entra ID verwendet OIDC, um öffentliche Signierschlüssel zu ermitteln und die Authentizität des Tokens für das Dienstkonto zu überprüfen, bevor es gegen ein Microsoft Entra Token ausgetauscht wird. Ihr Workload kann ein auf sein Volume projiziertes Dienstkonto-Token mit Hilfe der Azure Identity Client-Bibliothek oder der MSAL gegen ein Microsoft Entra-Token austauschen.

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

Das folgende Diagramm fasst die Authentifizierungssequenz mithilfe von OIDC zusammen:

Automatische Drehung des Webhook-Zertifikats

Ähnlich wie bei anderen Webhook-Add-Ons dreht der Automatische Drehungsvorgang des Clusterzertifikats das Zertifikat.

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.
• Many-to-one, bei dem mehrere Dienstkonten auf das gleiche Microsoft Entra-Objekt verweisen.
• One-to-many, bei dem ein Dienstkonto auf mehrere Microsoft Entra-Objekte verweist, indem es die Annotation der Client ID ändert. Weitere Informationen finden Sie unter Verbinden mehrerer Identitäten mit einem Kubernetes-Dienstkonto.

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. In den folgenden Abschnitten wird eine Liste der verfügbaren Bezeichnungen und Anmerkungen beschrieben, mit denen Sie das Verhalten beim Austauschen des Dienstkontotokens für ein Microsoft Entra-Zugriffstoken konfigurieren können.

Dienstkontoanmerkungen

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

Podbezeichnungen

Podanmerkungen

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

Migrieren zur Microsoft Entra Workload-ID

Sie können Cluster konfigurieren, die bereits eine podverwaltete Identität ausführen, um die Microsoft Entra Workload-ID auf eine von zwei Arten zu verwenden:

• Verwenden Sie dieselbe Konfiguration, die Sie für die verwaltete Pod-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.
• Schreiben Sie Ihre Anwendung neu, um die neueste Version der Azure Identity-Clientbibliothek zu verwenden.

Um den Migrationsprozess zu optimieren und zu vereinfachen, haben wir ein Migrations-Sidecar entwickelt, mit dem die Transaktionen des Instanzmetadatendiensts (Instance Metadata Service, IMDS) konvertiert werden, die Ihre Anwendung in OIDC übergibt. Der Migrations-Sidecar ist nicht als langfristige Lösung gedacht, sondern als eine Möglichkeit, schnell mit Microsoft Entra Workload ID zu arbeiten. 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 sind unsere Migrations- oder Bereitstellungsempfehlungen für Ihren AKS-Cluster zusammengefasst:

Nächste Schritte

• Informationen zum Einrichten Ihres Pods zur Authentifizierung mithilfe einer Workload-Identität als Migrationsoption finden Sie unter Modernisieren der Anwendungsauthentifizierung mit microsoft Entra Workload ID.
• Siehe Bereitstellen und Konfigurieren eines AKS-Clusters mit Microsoft Entra Workload ID, mit dem Sie einen Cluster bereitstellen und eine Beispielanwendung für die Verwendung einer Workloadidentität konfigurieren können.