Freigeben über

Problembehandlung für das Istio-Dienstnetz-Add-On-Plug-In-ZS-Zertifikat

  • Artikel

In diesem Artikel werden häufige Probleme im Zusammenhang mit Plug-In-Zertifizierungsstellenzertifikaten (Ca) für das Istio-Dienstnetz-Add-On behandelt, und er bietet Lösungen zum Beheben dieser Probleme. In diesem Artikel wird auch der allgemeine Prozess zum Einrichten von Plug-In-Zertifizierungsstellenzertifikaten für das Service Mesh-Add-On erläutert.

Hinweis

In diesem Artikel wird davon ausgegangen, dass die Istio-Revision asm-1-17 im Cluster bereitgestellt wird.

Voraussetzungen

  • Azure CLI.

  • Das Kubernetes kubectl-Tool oder ein ähnliches Tool, um eine Verbindung mit dem Cluster herzustellen. Um kubectl mithilfe der Azure CLI zu installieren, führen Sie den Befehl az aks install-cli aus.

  • Die folgenden Standardshelltools im Linux-Stil:

    • grep
    • sort
    • tail
    • awk
    • xargs

  • Das jq-Tool zum Abfragen von JSON-Daten.

Allgemeiner Einrichtungsprozess

  • Bevor Sie das Istio-Add-On für die Verwendung des Plug-In-Zertifizierungsstellenzertifikatfeatures aktivieren, müssen Sie das Azure Key Vault-Anbieter für Secrets Store-Add-On im Cluster aktivieren. Stellen Sie sicher, dass sich die Azure Key Vault und der Cluster auf demselben Azure-Mandanten befinden.

  • Nachdem das Azure Key Vault-Geheimnisanbieter-Add-On aktiviert wurde, müssen Sie den Zugriff auf die Azure-Key Vault für die benutzerseitig zugewiesene verwaltete Identität einrichten, die das Add-On erstellt.

  • Nachdem Sie der benutzerseitig zugewiesenen verwalteten Identität die Berechtigung für den Zugriff auf die Azure Key Vault erteilt haben, können Sie das Plug-In-Zertifizierungsstellenzertifikat-Feature zusammen mit dem Istio-Add-On verwenden. Weitere Informationen finden Sie im Abschnitt Aktivieren des Istio-Add-Ons für die Verwendung eines Plug-In-Zertifizierungsstellenzertifikats .

  • Damit der Cluster Änderungen in den Geheimnissen von Azure Key Vault automatisch erkennen kann, müssen Sie die automatische Rotation aktivieren.

  • Obwohl Änderungen am Zwischenzertifikat automatisch angewendet werden, muss die istiod Bereitstellung neu gestartet werden, nachdem Sie Änderungen am Stammzertifikat vorgenommen haben. Der Neustart der Bereitstellung erfolgt mithilfe eines Cronjobs, wie im Abschnitt Bereitgestellte Ressourcen erläutert.

Aktivieren des Istio-Add-Ons für die Verwendung eines Plug-In-Zertifizierungsstellenzertifikats

Mit dem Istio-Add-On Istio-Plug-In-Zertifizierungsstellenzertifikat können Sie Plug-In-Stamm- und -Zwischenzertifikate auf dem Mesh ihres Clusters konfigurieren. Wenn Sie beim Aktivieren des Add-Ons Informationen zum Plug-In-Zertifikat bereitstellen möchten, geben Sie die folgenden Parameter für den Befehl az aks mesh enable in der Azure CLI an.

Parameter Beschreibung
--key-vault-id<resource-id> Die Azure Key Vault-Ressourcen-ID. Es wird erwartet, dass sich diese Ressource im selben Mandanten wie der verwaltete Cluster befindet. Diese Ressourcen-ID muss im Ressourcen-ID-Format der Azure Resource Manager-Vorlage (ARM-Vorlage) vorliegen.
--root-cert-object-name<root-cert-obj-name> Der Name des Stammzertifikatobjekts im Azure-Schlüsseltresor.
--ca-cert-object-name<inter-cert-obj-name> Der Zwischenzertifikatobjektname im Azure-Schlüsseltresor.
--ca-key-object-name<inter-key-obj-name> Der Objektname des privaten Schlüssels des Zwischenzertifikats im Azure-Schlüsseltresor.
--cert-chain-object-name<cert-chain-obj-name> Der Name des Zertifikatkettenobjekts im Azure-Schlüsseltresor.

Wenn Sie das Plug-In-Zertifizierungsstellenzertifikatfeature verwenden möchten, müssen Sie alle fünf Parameter angeben. Es wird erwartet, dass alle Azure Key Vault-Objekte den Typ Geheimnis aufweisen.

Weitere Informationen finden Sie unter Plug-in-Zertifizierungsstellenzertifikate für istio-basiertes Service Mesh-Add-On auf Azure Kubernetes Service.

Bereitgestellte Ressourcen

Im Rahmen der Add-On-Bereitstellung für das Plug-In-Zertifikatfeature werden die folgenden Ressourcen im Cluster bereitgestellt:

  • Das cacerts Kubernetes-Geheimnis wird zum Zeitpunkt der aks-istio-system Add-On-Bereitstellung im Namespace erstellt. Dieses Geheimnis enthält synchronisierte Azure Key Vault-Geheimnisse:

    kubectl describe secret cacerts --namespace aks-istio-system

    Name:         cacerts
Namespace:    aks-istio-system
Labels:       secrets-store.csi.k8s.io/managed=true
Annotations:  <none>

Type:  opaque

Data
====
ca-cert.pem:     1968 bytes
ca-key.pem:      3272 bytes
cert-chain.pem:  3786 bytes
root-cert.pem:   3636 bytes

  • Das istio-spc-asm-1-17SecretProviderClass-Objekt wird zum Zeitpunkt der aks-istio-system Add-On-Bereitstellung im Namespace erstellt. Diese Ressource enthält Azure-spezifische Parameter für den CSI-Treiber (Secrets Store Container Storage Interface):

    kubectl get secretproviderclass --namespace aks-istio-system

    NAME                 AGE
istio-spc-asm-1-17   14h

  • Die istio-ca-root-cert Konfigurationszuordnung wird im aks-istio-system Namespace und allen anderen benutzerseitig verwalteten Namespaces erstellt. Diese Konfigurationszuordnung enthält das Stammzertifikat, das von der Zertifizierungsstelle verwendet wird, und wird von Workloads in den Namespaces wie folgt verwendet, um die Kommunikation zwischen Workloads zu überprüfen:

    kubectl describe configmap istio-ca-root-cert --namespace aks-istio-system

    Name:         istio-ca-root-cert
Namespace:    aks-istio-system
Labels:       istio.io/config=true
Annotations:  <none>

Data
====
root-cert.pem:
----
-----BEGIN CERTIFICATE-----
<certificate data>
-----END CERTIFICATE-----

  • Das istio-cert-validator-cronjob-asm-1-17Cronjob-Objekt wird im aks-istio-system -Namespace erstellt. Dieser Cronjob wird alle 10 Minuten ausgeführt, um nach Updates für das Stammzertifikat zu suchen. Wenn das Stammzertifikat, das cacerts sich im Kubernetes-Geheimnis befindet, nicht mit der istio-ca-root-cert Konfigurationszuordnung im aks-istio-system Namespace übereinstimmt, wird die istiod-asm-1-17 Bereitstellung neu gestartet:

    kubectl get cronjob --namespace aks-istio-system

    NAME                                    SCHEDULE       SUSPEND   ACTIVE
istio-cert-validator-cronjob-asm-1-17   */10 * * * *   False     0

    Sie können den folgenden Befehl ausführen, um die Cronjob-Protokolle für die letzte Ausführung zu überprüfen:

    kubectl logs --namespace aks-istio-system $(kubectl get pods --namespace aks-istio-system | grep 'istio-cert-validator-cronjob-' | sort -k8 | tail -n 1 | awk '{print $1}')

    Dieser Befehl generiert eine der folgenden Ausgabemeldungen, je nachdem, ob ein Stammzertifikatupdate erkannt wurde:

    Root certificate update not detected.

    Root certificate update detected. Restarting deployment...
deployment.apps/istiod-asm-1-17 restarted
Deployment istiod-asm-1-17 restarted.

Bestimmen des Zertifikattyps in Bereitstellungsprotokollen

Sie können die Bereitstellungsprotokolle anzeigen, um zu ermitteln, ob Sie über ein selbstsigniertes Zertifizierungsstellenzertifikat oder ein BYO-Zertifikat (Plug-In) einer Zertifizierungsstelle verfügen. Führen Sie den folgenden Befehl aus, um die Protokolle anzuzeigen:

kubectl logs deploy/istiod-asm-1-17 --container discovery --namespace aks-istio-system | grep -v validationController

Unmittelbar vor jedem Zertifikatprotokolleintrag befindet sich ein weiterer Protokolleintrag, der diese Art von Zertifikat beschreibt. Für ein selbstsigniertes Zertifizierungsstellenzertifikat lautet der Eintrag "No plugged-in cert at etc/cacerts/ca-key.pem; Es wird ein selbstsigniertes Zertifikat verwendet." Für ein Plug-In-Zertifikat lautet der Eintrag "Use plugged-in cert at etc/cacerts/ca-key.pem". Beispielprotokolleinträge, die sich auf die Zertifikate beziehen, sind in den folgenden Tabellen aufgeführt.

  • Protokolleinträge für ein selbstsigniertes Zertifizierungsstellenzertifikat

    Zeitstempel Protokollebene Nachricht
    2023-11-20T23:27:36.649019Z info Verwenden des istiod-Dateiformats zum Signieren von CA-Dateien
    2023-11-20T23:27:36.649032Z info Kein eingestecktes Zertifikat unter etc/cacerts/ca-key.pem; Selbstsigniertes Zertifikat wird verwendet
    2023-11-20T23:27:36.649536Z info x509-Zertifikat – <Zertifikatdetails>
    2023-11-20T23:27:36.649552Z info Istiod-Zertifikate werden neu geladen
    2023-11-20T23:27:36.649613Z info spiffe 1 Zertifikate hinzugefügt, um der Domäne cluster.local in peer cert verifier zu vertrauen

  • Protokolleinträge für ein BYO-Zertifizierungsstellenzertifikat (Plug-In)

    Zeitstempel Protokollebene Nachricht
    2023-11-21T00:20:25.808396Z info Verwenden des istiod-Dateiformats zum Signieren von CA-Dateien
    2023-11-21T00:20:25.808412Z info Verwenden des angeschlossenen Zertifikats unter etc/cacerts/ca-key.pem
    2023-11-21T00:20:25.808731Z info x509-Zertifikat – <Zertifikatdetails>
    2023-11-21T00:20:25.808764Z info x509-Zertifikat – <Zertifikatdetails>
    2023-11-21T00:20:25.808799Z info x509-Zertifikat – <Zertifikatdetails>
    2023-11-21T00:20:25.808803Z info Istiod-Zertifikate werden neu geladen
    2023-11-21T00:20:25.808873Z info spiffe 1 Zertifikate hinzugefügt, um der Domäne cluster.local in peer cert verifier zu vertrauen

Die Zertifikatdetails in einem Protokolleintrag werden als durch Trennzeichen getrennte Werte für den Aussteller, den Antragsteller, die Seriennummer (SN– eine lange hexadezimale Zeichenfolge) und die Werte für den Anfangs- und Endzeitstempel angezeigt, die definieren, wann das Zertifikat gültig ist.

Für ein selbstsigniertes Zertifizierungsstellenzertifikat gibt es einen Detaileintrag. Beispielwerte für dieses Zertifikat sind in der folgenden Tabelle aufgeführt.

Aussteller Betreff SN NotBefore NotAfter
"O=cluster.local" "" <32-stelliger Hexadezimalwert> "2023-11-20T23:25:36Z" "2033-11-17T23:27:36Z"

Für ein BYO-Zertifizierungsstellenzertifikat (Plug-In) gibt es drei Detaileinträge. Die anderen beiden Einträge beziehen sich auf ein Stammzertifikatupdate und eine Änderung am Zwischenzertifikat. Beispielwerte für diese Einträge sind in der folgenden Tabelle aufgeführt.

Aussteller Betreff SN NotBefore NotAfter
CN=Zwischenzertifizierungsstelle – A1,O=Istio,L=cluster-A1" "" <32-stelliger Hexadezimalwert> "2023-11-21T00:18:25Z" "2033-11-18T00:20:25Z"
CN=Root A,O=Istio" "CN=Intermediate CA - A1,O=Istio,L=cluster-A1" <40-stelliger Hexadezimalwert> "2023-11-04T01:40:22Z" "2033-11-01T01:40:22Z"
CN=Root A,O=Istio" "CN=Root A,O=Istio" <40-stelliger Hexadezimalwert> "2023-11-04T01:38:27Z" "2033-11-01T01:38:27Z"

Häufig auftretende Probleme

Problem 1: Der Zugriff auf Azure Key Vault wurde falsch eingerichtet

Nachdem Sie das Azure Key Vault-Geheimnisanbieter-Add-On aktiviert haben, müssen Sie der benutzerseitig zugewiesenen verwalteten Identität des Add-Ons Zugriff auf die Azure-Key Vault gewähren. Das Einrichten des Zugriffs auf Azure Key Vault fälschlicherweise bewirkt, dass die Add-On-Installation angehalten wird.

kubectl get pods --namespace aks-istio-system

In der Liste der Pods sehen Sie, dass die istiod-asm-1-17 Pods in einem Init:0/2 Zustand hängen bleiben.

NAMEN BEREIT STATUS NEUSTART ALTER
istiod-asm-1-17-6fcfd88478-2x95b 0/1 Beenden 0 5m55s
istiod-asm-1-17-6fcfd88478-6x5hh 0/1 Beenden 0 5m40s
istiod-asm-1-17-6fcfd88478-c48f9 0/1 Init:0/2 0 54 s
istiod-asm-1-17-6fcfd88478-wl8mw 0/1 Init:0/2 0 39s

Um das Azure Key Vault-Zugriffsproblem zu überprüfen, führen Sie den kubectl get pods Befehl aus, um Pods zu suchen, die die secrets-store-provider-azurekube-system Bezeichnung im Namespace aufweisen:

kubectl get pods --selector app=secrets-store-provider-azure --namespace kube-system --output name | xargs -I {} kubectl logs --namespace kube-system {}

Die folgende Beispielausgabe zeigt, dass der Fehler "403 Verboten" aufgetreten ist und Ihnen die Berechtigung "get" für Geheimnisse im Schlüsseltresor verweigert wird:

"failed to process mount request" err="failed to get objectType:secret, objectName:<secret-object-name>, objectVersion:: keyvault. BaseClient#GetSecret: Fehler beim Reagieren auf Anforderung: StatusCode=403 - Ursprünglicher Fehler: autorest/azure: Der Dienst hat einen Fehler zurückgegeben. Status=403 Code=\"Forbidden\" Message=\"Der Benutzer, die Gruppe oder die Anwendung 'appid=<appid>; oid=<oid>; iss=<iss' verfügt nicht über die Berechtigung zum Abrufen von Geheimnissen> für den Schlüsseltresor "MyAzureKeyVault; location=eastus'. Hilfe zur Behebung dieses Problems finden Sie unter https://go.microsoft.com/fwlink/?linkid=2125287\" InnerError={\"code\":\"AccessDenied\"}"

Um dieses Problem zu beheben, richten Sie den Zugriff auf die benutzerseitig zugewiesene verwaltete Identität für das Azure Key Vault-Add-On ein, indem Sie die Berechtigungen Abrufen und Auflisten für Azure Key Vault Geheimnisse abrufen und das Istio-Add-On erneut installieren. Rufen Sie zunächst die Objekt-ID der benutzerseitig zugewiesenen verwalteten Identität für das Azure Key Vault-Add-On ab, indem Sie den Befehl az aks show ausführen:

OBJECT_ID=$(az aks show --resource-group <my-resource-group> --name <my-managed-cluster> --query 'addonProfiles.azureKeyvaultSecretsProvider.identity.objectId')

Führen Sie zum Festlegen der Zugriffsrichtlinie den folgenden Az keyvault set-policy-Befehl aus, indem Sie die objekt-ID angeben, die Sie abgerufen haben:

az keyvault set-policy --name MyAzureKeyVault --object-id $OBJECT_ID --secret-permissions get list

Hinweis

Haben Sie Ihre Key Vault erstellt, indem Sie die Azure RBAC-Autorisierung für Ihr Berechtigungsmodell anstelle der Tresorzugriffsrichtlinie verwendet haben? Informationen zum Erstellen von Berechtigungen für die verwaltete Identität finden Sie in diesem Fall unter Gewähren des Zugriffs auf Key Vault Schlüssel, Zertifikate und Geheimnisse mit einer rollenbasierten Zugriffssteuerung in Azure. Fügen Sie eine Azure-Rollenzuweisung für Key Vault Leser für die benutzerseitig zugewiesene verwaltete Identität des Add-Ons hinzu.

Problem 2: Die automatische Erkennung von Key Vault Geheimnisänderungen ist nicht eingerichtet

Damit ein Cluster Änderungen im Azure Key Vault Geheimnisse automatisch erkennen kann, müssen Sie die automatische Rotation für das Azure Key Vault-Anbieter-Add-On aktivieren. Die automatische Rotation kann Änderungen an Zwischen- und Stammzertifikaten automatisch erkennen. Führen Sie für einen Cluster, der das Azure Key Vault-Anbieter-Add-On aktiviert, den folgenden az aks show Befehl aus, um zu überprüfen, ob die automatische Rotation aktiviert ist:

az aks show --resource-group <my-resource-group> --name <my-managed-cluster> | jq -r '.addonProfiles.azureKeyvaultSecretsProvider.config.enableSecretRotation'

Wenn der Cluster das Azure Key Vault-Anbieter-Add-On aktiviert hat, führen Sie den folgenden az aks show Befehl aus, um das Rotationsabrufintervall zu bestimmen:

az aks show --resource-group <my-resource-group> --name <my-managed-cluster> | jq -r '.addonProfiles.azureKeyvaultSecretsProvider.config.rotationPollInterval'

Azure Key Vault Geheimnisse werden mit dem Cluster synchronisiert, wenn das Abrufintervall nach der vorherigen Synchronisierung verstrichen ist. Der Standardwert für das Intervall beträgt zwei Minuten.

Problem 3: Zertifikatwerte fehlen oder sind falsch konfiguriert

Wenn geheime Objekte in Azure Key Vault fehlen oder diese Objekte falsch konfiguriert sind, kann die Installation des Add-Ons verzögert werden. Die istiod-asm-1-17 Pods gehen nicht über status hinaus Init:0/2 . Um die zugrunde liegende Ursache für dieses Problem zu ermitteln, zeigen Sie die Bereitstellungsprotokolle für diesen Pod an, indem Sie den folgenden kubectl describe Befehl ausführen:

kubectl describe deploy/istiod-asm-1-17 --namespace aks-istio-system

Der Befehl zeigt Ereignisse an, die der folgenden Ausgabetabelle ähneln könnten. In diesem Beispiel ist ein fehlendes Geheimnis die Ursache des Problems.

Typ Grund Alter Von Nachricht
Standard Geplant 3m9s default-scheduler aks-istio-system/istiod-asm-1-17-6fcfd88478-hqdjj wurde aks-userpool-24672518-vmss0000000 erfolgreich zugewiesen.
Warnung FailedMount 66s kubelet Volumes können nicht angefügt oder eingebunden werden: unmounted volumes=[cacerts], unattached volumes=[], failed to process volumes=[]: timed out waiting for the condition
Warnung FailedMount 61s (x9 über 3m9s) kubelet Fehler bei MountVolume.SetUp für Volume "cacerts": rpc-Fehler: code = Unknown desc = failed to mount secrets store objects for pod aks-istio-system/istiod-asm-1-17-6fcfd88478-hqdjj, err: rpc error: code = Unknown desc = failed to mount objects, error: failed to get objectType:secret, objectName:test-cert-chain, objectVersion:: keyvault. BaseClient#GetSecret: Fehler beim Reagieren auf Anforderung: StatusCode=404 - Ursprünglicher Fehler: autorest/azure: Der Dienst hat einen Fehler zurückgegeben. Status=404 Code="SecretNotFound" Message="Ein Geheimnis mit (Name/ID) test-cert-chain wurde in diesem Schlüsseltresor nicht gefunden. Wenn Sie dieses Geheimnis kürzlich gelöscht haben, können Sie es möglicherweise mit dem richtigen Wiederherstellungsbefehl wiederherstellen. Hilfe zum Beheben dieses Problems finden Sie unter https://go.microsoft.com/fwlink/?linkid=2125182"

Ressourcen

Informationen zum Haftungsausschluss von Drittanbietern

Die in diesem Artikel genannten Drittanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.

Haftungsausschluss für Kontaktinformationen von Drittanbietern

Die Kontaktinformationen zu den in diesem Artikel erwähnten Drittanbietern sollen Ihnen helfen, zusätzliche Informationen zu diesem Thema zu finden. Diese Kontaktinformationen können ohne vorherige Ankündigung geändert werden. Sie werden von Microsoft ohne jede Gewähr weitergegeben.

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.