Bereitstellen und Konfigurieren des Workload-Identitätsverbunds in Azure Arc-fähigen Kubernetes

Sie können die Workload-Identitätsfunktion auf einem Azure Arc-fähigen Kubernetes Cluster aktivieren, indem Sie Azure CLI verwenden. Der Prozess folgt diesen allgemeinen Schritten:

1. Aktivieren Sie die Workload-Identitätsfunktion auf einem neuen oder bestehenden Arc-fähigen Kubernetes Cluster.
2. Erstellen Sie eine verwaltete Identität (oder eine App-Registrierung) und ein Kubernetes Dienst-Konto.
3. Konfigurieren der verwalteten Identität für den Tokenverbund
4. Konfigurieren Sie die Annotationen des Dienstkontos und die Kennzeichnungen der Anwendungs-Pods für die Verwendung der Workload-Identität.
5. Konfigurieren Sie die Workload-Identitätseinstellungen auf dem Kubernetes-Cluster.
6. Deaktivieren Sie die Workload-Identität auf dem Cluster.

Eine Übersicht über dieses Feature finden Sie unter Workload Identity Federation in Azure Arc-fähigen Kubernetes.

Voraussetzungen

• Workload-Identität für Azure Arc-aktivierte Kubernetes-Cluster unterstützt die folgenden Kubernetes-Distributionen:
  • Ubuntu Linux Cluster, der K3s ausführt
  • AKS durch Azure Arc aktiviert
  • Red Hat OpenShift
  • VMware Tanzu TKGm
  • AKS auf Edge Essentials

Um die Funktion der Workload-Identität zu nutzen, benötigen Sie Azure CLI Version 2.64 oder höher und az connectedk8s Version 1.10.0 oder höher. Aktualisieren Sie Ihre Azure CLI-Version, bevor Sie Ihre az connectedk8s-Version aktualisieren. Wenn Sie Azure Cloud Shell verwenden, wird die neueste Version von Azure CLI installiert.

Aktivieren Sie die Workload-Identität auf Ihrem Cluster

Führen Sie die entsprechenden Schritte aus, um die Funktion Workload-Identität entweder für einen neuen Arc-fähigen Kubernetes Cluster oder für einen bestehenden Cluster zu aktivieren. Ersetzen Sie in beiden Fällen den Namen und die Ressourcengruppe durch Ihre Werte, und konfigurieren Sie Die Parameter nach Bedarf.

Festlegen von Umgebungsvariablen

Aus Gründen der Einfachheit beziehen sich die Beispiele in diesem Artikel auf die im folgenden Abschnitt definierten Umgebungsvariablen. Ersetzen Sie diese Werte durch Ihre eigenen Werte:

export RESOURCE_GROUP="myRG"
export LOCATION="eastus"
export CLUSTER_NAME="mycluster"
export SERVICE_ACCOUNT_NAMESPACE="myKubernetesnamespace"
export SERVICE_ACCOUNT_NAME="mysa"
export SUBSCRIPTION="$(az account show --query id --output tsv)"
export USER_ASSIGNED_IDENTITY_NAME="myIdentity"
export FEDERATED_IDENTITY_CREDENTIAL_NAME="myFedIdentity"

Um einen Azure Arc-fähigen Cluster mit aktivierter Workload-Identität zu erstellen, verwenden Sie den folgenden Befehl:

az connectedk8s connect --name "${CLUSTER_NAME}" --resource-group "${RESOURCE_GROUP}" --enable-oidc-issuer --enable-workload-identity

Um die Workload-Identität auf einem bestehenden Arc-fähigen Kubernetes Cluster zu aktivieren, verwenden Sie den update-Befehl.

az connectedk8s update --name "${CLUSTER_NAME}" --resource-group "${RESOURCE_GROUP}" --enable-oidc-issuer --enable-workload-identity

Abrufen der OIDC-Zertifikataussteller-URL

Rufen Sie die OIDC-Aussteller-URL ab, und speichern Sie sie in einer Umgebungsvariable. Verwenden Sie diese Aussteller-URL im folgenden Schritt.

export OIDC_ISSUER="$(az connectedk8s show --name "${CLUSTER_NAME}" --resource-group "${RESOURCE_GROUP}" \ 
    --query "oidcIssuerProfile.issuerUrl" \  
    --output tsv)"

Um die Umgebungsvariable anzuzeigen, geben Sie echo ${OIDC_ISSUER} ein. Die Umgebungsvariable sollte die URL des Zertifikatausstellers enthalten, ähnlich wie im folgenden Beispiel:

https://northamerica.oic.prod-arc.azure.com/00000000-0000-0000-0000-000000000000/12345678-1234-1234-1234-123456789123/

Standardmäßig verwendet der Ausgeber die Basis-URL https://{region}.oic.prod-arc.azure.com/{tenant_id}/{uuid}, wobei der Wert für {region} dem Speicherort entspricht, an dem Sie den Arc-aktivierten Kubernetes-Cluster erstellt haben. Der Wert {uuid} stellt den OpenID Connect (OIDC)-Schlüssel dar, bei dem es sich um eine unveränderliche, zufällig generierte GUID für jeden Cluster handelt.

Erstellen einer verwalteten Identität

Verwenden Sie den Befehl az identity create zum Erstellen einer benutzerseitig zugewiesenen verwaltete Identität. Mithilfe der Workload-Identität richten Sie eine Vertrauensstellung zwischen dem Token der vom Benutzer zugewiesenen verwalteten Identität und dem Dienstkontotoken des Kubernetes-Clusters ein.

az identity create \ 
    --name "${USER_ASSIGNED_IDENTITY_NAME}" \
    --resource-group "${RESOURCE_GROUP}" \
    --location "${LOCATION}" \
    --subscription "${SUBSCRIPTION}"

Rufen Sie die Client-ID der verwalteten Identität ab, und speichern Sie sie in einer Umgebungsvariable.

export USER_ASSIGNED_CLIENT_ID="$(az identity show \ 
    --resource-group "${RESOURCE_GROUP}" \
    --name "${USER_ASSIGNED_IDENTITY_NAME}" \
    --query 'clientId' \
    --output tsv)"

Erstellen eines Kubernetes-Dienstkontos

Erstellen Sie ein Kubernetes-Dienstkonto, und kommentieren Sie es mit der Client-ID der verwalteten Identität, die Sie im vorherigen Schritt erstellt haben. Nachdem Sie die Vertrauensstellung zwischen den beiden hergestellt haben, werden die signierten Token, die dem Kubernetes-Dienstkonto zugeordnet sind, für ein Microsoft Entra ID-Token ausgetauscht.

Wenden Sie den folgenden YAML-Codeausschnitt an, um ein Dienstkonto mit der hinzugefügten Workloadidentitätsanmerkung zu erstellen.

apiVersion: v1 
kind: ServiceAccount 
metadata: 
  annotations: 
    azure.workload.identity/client-id: "${USER_ASSIGNED_CLIENT_ID}" 
  name: "${SERVICE_ACCOUNT_NAME}" 
  namespace: "${SERVICE_ACCOUNT_NAMESPACE}" 

Erstellen von Anmeldeinformationen für eine Verbundidentität

Verwenden Sie den az identity federated-credential create-Befehl, um die Verbundidentitäts-Anmeldeinformationen zwischen der verwalteten Identität, dem Aussteller des Servicekontos und dem Subjekt zu erstellen. Dieser Schritt stellt die Vertrauensbeziehung zwischen dem Kubernetes Cluster und Microsoft Entra für den Austausch von Token her. Weitere Informationen zu Anmeldeinformationen für eine Verbundidentität in Microsoft Entra finden Sie unter Übersicht über die Anmeldeinformationen für Verbundidentitäten in Microsoft Entra ID.

az identity federated-credential create \ 
    --name ${FEDERATED_IDENTITY_CREDENTIAL_NAME} \ 
    --identity-name "${USER_ASSIGNED_IDENTITY_NAME}" \ 
    --resource-group "${RESOURCE_GROUP}" \ 
    --issuer "${OIDC_ISSUER}" \ 
    --subject system:serviceaccount:"${SERVICE_ACCOUNT_NAMESPACE}":"${SERVICE_ACCOUNT_NAME}" \ 
    --audience api://AzureADTokenExchange 

Konfigurieren Sie Annotationen für Dienstkonten und Pod-Bezeichnungen

Für die Konfiguration der Workload-Identität auf der Grundlage der Anwendungsanforderungen stehen die folgenden Annotationen für Dienstkonten und Pods zur Verfügung. Die im folgenden Abschnitt angegebene Pod-Bezeichnung ist obligatorisch, wenn Sie --enable-workload-identity auf true setzen.

Dienstkontoanmerkungen

Alle Annotationen zum Dienstkonto sind optional. Wenn Sie keine Anmerkung angeben, wird der Standardwert verwendet.

Podbezeichnungen

Podanmerkungen

Alle Pod Annotationen sind optional. Wenn Sie keine Anmerkung angeben, wird der Standardwert verwendet.

Konfigurieren Sie die Workload-Identitätseinstellungen auf dem Kubernetes-Cluster

Der API-Server auf dem Kubernetes Cluster muss so konfiguriert werden, dass er Token für Dienstkonten ausgibt, die die öffentlich zugängliche URL des OIDC-Ausstellers enthalten (damit Entra weiß, wo die öffentlichen Schlüssel zur Validierung des Tokens zu finden sind).

Führen Sie die folgenden Schritte aus, um die Workload-Identitätseinstellungen für die verschiedenen Kubernetes-Verteilungen zu konfigurieren.

K3s-Cluster

1. Erstellen Sie ihre k3s-Konfigurationsdatei.

2. Bearbeiten Sie /etc/rancher/k3s/config.yaml, um diese Einstellungen hinzuzufügen:

      kube-apiserver-arg:  
        - "service-account-issuer=${OIDC_ISSUER}"
        - "service-account-max-token-expiration=24h"
   

3. Speichern Sie die config.yaml.

4. Starten Sie den k3s-API-Server neu, indem Sie folgendes ausführen systemctl restart k3s.

   Wechseln Sie die Schlüssel des Dienstkontos häufig. Weitere Informationen finden Sie unter Signierschlüssel für Servicekonten in K3s-Clustern rotieren.

Red Hat OpenShift-Cluster

1. Bearbeiten Sie die Authentifizierungskonfiguration für den Cluster:

   1. Öffnen Sie die Authentifizierungskonfiguration für den Cluster:

      kubectl edit authentications cluster
      

   2. Suchen Sie den Abschnitt für den Ausstellerwert, und aktualisieren Sie ihn.

   3. Speichern Sie die Datei, und beenden Sie den Editor.

2. Starten Sie die relevanten Bereitstellungen in den erforderlichen Namespaces neu:

   kubectl rollout restart deployment -n azure-arc
   kubectl rollout restart deployment -n arc-workload-identity
   

3. Alternativ können Sie Änderungen über einen Patchbefehl anwenden, um den Ausstellerwert ohne manuelle Bearbeitung zu aktualisieren:

   kubectl patch authentication cluster \ 
   --type merge \ 
   -p '{"spec":{"serviceAccountIssuer":"<NEW_ISSUER_VALUE>"}}' \ 
   --kubeconfig /etc/kubernetes/admin.conf
   

4. Bestätigen Sie Ihre Änderungen:

   1. Überprüfen Sie den Ausstellerwert:

      kubectl get authentications cluster
      

   2. Überprüfen Sie den Status der neu gestarteten Bereitstellungen:

      kubectl get pods -n azure-arc
      kubectl get pods -n arc-workload-identity 
      

VMware Tanzu TKGm-Cluster

1. Verbinden Sie Ihren Cluster mit Azure Arc mit aktivierter Workloadidentität:

   1. Aktivieren Sie die Workload-Identität während des Arc-Verbindungsvorgangs.
   2. Rufen Sie nach der Verbindung die OIDC-Aussteller-URL ab.

2. Workload-Cluster-Konfiguration bearbeiten

   1. Wechseln des Kontexts zum Verwaltungscluster:

      kubectl config use-context mgmt-cluster-admin@mgmt-cluster 
      

   2. Cluster anzeigen

      kubectl get cluster
      

   3. Bearbeiten sie die Zielclusterkonfiguration:

      1. Suchen Sie nach apiServerExtraArgs.
      2. Wenn der Wert vorhanden ist, aktualisieren Sie ihn so, dass er die Aussteller-URL enthält.
      3. Wenn sie nicht vorhanden ist, fügen Sie sie unter spec:topology:variables wie gezeigt hinzu.

      name: apiServerExtraArgs
      value:
        - 'service-account-issuer=<OIDC_ISSUER_URL>'
      

3. Wechseln des Kontexts zurück zum Workload-Cluster:

   kubectl config use-context <WORKLOAD_CLUSTER_CONTEXT>
   

4. Dienstkonto und Testtoken erstellen:

   1. Erstellen Sie ein Token für das Dienstkonto:

      kubectl create token <SERVICE_ACCOUNT_NAME> -n <NAMESPACE>
      

   2. Stellen Sie sicher, dass der Tokenherausgeber der erwarteten OIDC-URL entspricht.

5. Starten Sie die Bereitstellung neu, um Ihre Änderungen anzuwenden:

   kubectl rollout restart deployment -n azure-arc
   

Drehen des Dienstkontosignaturschlüssels auf K3s-Clustern

Für K3s-Cluster, die Sie in Azure Arc integrieren, wobei der Arbeitslast-Identitätsverbund aktiviert ist, ist die Rotation des Emittentenschlüssels für das Dienstkonto ein wichtiger Sicherheitsvorgang. Schlüsselrotation ist für die Sicherheitshygiene erforderlich und kann als Teil der Vorfallbehebung notwendig sein.

Der Emittentschlüssel des Dienstkontos (service.key) ist ein privater RSA-Schlüssel, der zum Signieren von Dienstkontotoken verwendet wird. Wenn Sie den Schlüssel drehen, behalten Sie den alten Schlüssel in der Datei bei, damit vorhandene Token gültig bleiben. Beide Schlüssel sollten koexistieren, bis alle vorhandenen Token ablaufen oder aktualisiert werden (mindestens 24 Stunden).

Als bewährte Methode sollten Sie die Emittentenschlüssel des Dienstkontos mindestens einmal alle drei Monate austauschen.

Voraussetzungen

Um den Service-Account-Ausstellerschlüssel in einem K3s-Cluster zu wechseln, stellen Sie sicher, dass Sie über die folgenden Voraussetzungen verfügen:

• K3s-Cluster in Azure Arc integriert mit aktivierter Workload-Identitätsföderation.
• sudo Stammzugriff auf den K3s-Serverknoten
• OpenSSL 3 auf dem Knoten installiert
• Vertrautheit mit der K3s-Zertifikat-CLI

Generieren eines neuen Schlüssels und Ausführen der Rotation

Führen Sie die folgenden Befehle auf dem K3s-Serverknoten aus, um einen neuen Schlüssel zu generieren und ihn für die Rotation vorzubereiten.

# Create a temporary directory for staging
mkdir -p /opt/k3s/server/tls

# Check OpenSSL version (OpenSSL 3.x requires -traditional flag)
openssl version | grep -qF 'OpenSSL 3' && OPENSSL_GENRSA_FLAGS=-traditional

# Generate a new RSA key
openssl genrsa ${OPENSSL_GENRSA_FLAGS:-} -out /opt/k3s/server/tls/service.key 2048

# Append the existing (old) key to preserve validity of current tokens
cat /var/lib/rancher/k3s/server/tls/service.key >> /opt/k3s/server/tls/service.key

# Load the updated key into the K3s datastore
k3s certificate rotate-ca --path=/opt/k3s/server

# Restart K3s to apply
sudo systemctl restart k3s

Nach dem Neustart:

• Neue Token werden mithilfe des neuen Schlüssels geprägt.
• Vorhandene Token bleiben gültig, da sich der alte Schlüssel noch in der Datei befindet.

Weitere Informationen zur Rotation des Emittentenschlüssels für das Dienstkonto finden Sie in der K3s-Dokumentation unter Rotation des Dienstkonto-Emittentenschlüssels.

Entfernen des alten Emittentenschlüssels des Dienstkontos

Führen Sie die folgenden Befehle auf dem K3s-Serverknoten aus, um den alten Schlüssel sicher zu entfernen:

# Backup the current key file
sudo cp /var/lib/rancher/k3s/server/tls/service.key /var/lib/rancher/k3s/server/tls/service.key.bak.$(date +%s)

# Split the keys into individual files
csplit -f /tmp/service-key- /var/lib/rancher/k3s/server/tls/service.key '/BEGIN RSA PRIVATE KEY/' '{*}'

# Copy only the new key (first key in the file) to staging
sudo cp /tmp/service-key-01 /opt/k3s/server/tls/service.key

# Load the updated key into the datastore
k3s certificate rotate-ca --path=/opt/k3s/server

# Restart K3s
sudo systemctl restart k3s

Deaktivieren der Workloadidentität

Führen Sie den folgenden Befehl aus, um das Workload-Identitätsfeature in einem Azure Arc-aktivierten Kubernetes-Cluster zu deaktivieren:

az connectedk8s update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${CLUSTER_NAME}" \
    --disable-workload-identity

Nächste Schritte

• Entdecken Sie ein Beispiel für die Konfiguration einer Anwendung zur Verwendung der Workload-Identität.
• Schützen Sie Ihren Cluster auf andere Weise, indem Sie den Anweisungen im Security Book für Azure Arc-fähige Kubernetes folgen.