Fehlerbehebung bei privilegierten Autopilot-Arbeitslasten und Zulassungslisten

Privilegierte Arbeitslasten in Google Kubernetes Engine (GKE) Autopilot-Clustern müssen richtig konfiguriert werden, um Probleme zu vermeiden. Fehlkonfigurationen können zu Synchronisierungsfehlern bei Zulassungslisten führen oder dazu, dass die Arbeitslast abgelehnt wird. Diese Probleme können verhindern, dass wichtige Agents oder Dienste mit den erforderlichen Berechtigungen ausgeführt werden.

In diesem Dokument erfahren Sie, wie Sie Probleme bei der Bereitstellung privilegierter Arbeitslasten in Autopilot beheben. Hier finden Sie Informationen zum Beheben von Fehlern bei der Synchronisierung der Zulassungsliste und zur Diagnose, warum eine privilegierte Arbeitslast möglicherweise abgelehnt wird.

Diese Informationen sind wichtig für Plattformadministratoren und ‑operatoren sowie Sicherheitsteams, die Arbeitslasten mit erhöhten Berechtigungen in Autopilot-Clustern bereitstellen. Weitere Informationen zu den gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Probleme bei der Synchronisierung der Zulassungsliste

Wenn Sie einen AllowlistSynchronizer bereitstellen, versucht GKE, die von Ihnen angegebenen Zulassungslistendateien zu installieren und zu synchronisieren. Wenn diese Synchronisierung fehlschlägt, wird der Fehler im Feld status des AllowlistSynchronizer gemeldet.

Rufen Sie den Status des AllowlistSynchronizer-Objekts ab:

kubectl get allowlistsynchronizer ALLOWLIST_SYNCHRONIZER_NAME -o yaml

Ersetzen Sie ALLOWLIST_SYNCHRONIZER_NAME durch den Namen des AllowlistSynchronizer.

Die Ausgabe sieht etwa so aus:

...
status:
  conditions:
  - type: Ready
    status: "False"
    reason: "SyncError"
    message: "some allowlists failed to sync: example-allowlist-1.yaml"
    lastTransitionTime: "2024-10-12T10:00:00Z"
    observedGeneration: 2
  managedAllowlistStatus:
    - filePath: "gs://path/to/allowlist1.yaml"
      generation: 1
      phase: Installed
      lastSuccessfulSync: "2024-10-10T10:00:00Z"
    - filePath: "gs://path/to/allowlist2.yaml"
      phase: Failed
      lastError: "Initial install failed: invalid contents"
      lastSuccessfulSync: "2024-10-08T10:00:00Z"

Die Felder conditions.message und managedAllowlistStatus.lastError enthalten detaillierte Informationen zum Fehler. Anhand dieser Informationen können Sie das Problem beheben.

Mehrere AllowlistSynchronizer

In GKE-Clustern mit Versionen vor 1.33.4-gke.1035000 kann die Installation von WorkloadAllowlists fehlschlagen, wenn mehr als ein AllowlistSynchronizer vorhanden ist.

Verwenden Sie nur einen einzigen AllowlistSynchronizer, der mehrere allowlistPaths enthält, um das Problem zu beheben.

Alternativ können Sie ein Upgrade Ihres Clusters auf eine neuere Version durchführen.

Sortierung von Arbeitslastcontainern

In GKE-Clustern mit Versionen vor 1.34.0-gke.0000000 werden Arbeitslastcontainer möglicherweise erstellt und in umgekehrter alphabetischer Reihenfolge sortiert, wenn ein oder mehrere Arbeitslastcontainer-Images mit einem Container-Image übereinstimmen, das in einer WorkloadAllowlist im Cluster angegeben ist.

Versuchen Sie Folgendes, um dieses Problem zu beheben:

  • Aktualisieren Sie Ihren Cluster auf Version 1.34.0-gke.0000000 oder höher.
  • Benennen Sie die Container Ihrer Arbeitslast um, damit sie in der richtigen Reihenfolge sortiert werden.

Probleme bei der Bereitstellung privilegierter Arbeitslasten

Nachdem Sie eine Zulassungsliste erfolgreich installiert haben, stellen Sie die entsprechende privilegierte Arbeitslast in Ihrem Cluster bereit. In einigen Fällen lehnt GKE die Arbeitslast möglicherweise ab.

Versuchen Sie Folgendes:

  • Achten Sie darauf, dass die GKE-Version Ihres Clusters die Versionsanforderung der Arbeitslast erfüllt.
  • Prüfen Sie, ob die Arbeitslast, die Sie bereitstellen, die Arbeitslast ist, für die die Zulassungslistendatei gilt.

Wenn Sie wissen möchten, warum eine privilegierte Arbeitslast abgelehnt wurde, fordern Sie detaillierte Informationen von GKE zu Verstößen gegen die Zulassungsliste an:

  1. Rufen Sie eine Liste der installierten Zulassungslisten im Cluster ab:

    kubectl get workloadallowlist

    Suchen Sie den Namen der Zulassungsliste, die für die privilegierte Arbeitslast gelten soll.

  2. Öffnen Sie das YAML-Manifest der privilegierten Arbeitslast in einem Texteditor. Wenn Sie nicht auf die YAML-Manifeste zugreifen können, z. B. wenn beim Bereitstellungsprozess der Arbeitslast andere Tools verwendet werden, wenden Sie sich an den Arbeitslastanbieter, um ein Problem zu melden. Überspringen Sie die restlichen Schritte.

  3. Fügen Sie der Pod-Spezifikation der privilegierten Arbeitslast im Abschnitt spec.metadata.labels das folgende Label hinzu:

    labels:
  cloud.google.com/matching-allowlist: ALLOWLIST_NAME

    Ersetzen Sie ALLOWLIST_NAME durch den Namen der Zulassungsliste, die Sie im vorherigen Schritt erhalten haben. Verwenden Sie den Namen aus der Ausgabe des Befehls kubectl get workloadallowlist, nicht den Pfad zur Zulassungslistendatei.

  4. Speichern Sie das Manifest und wenden Sie die Arbeitslast auf den Cluster an:

    kubectl apply -f WORKLOAD_MANIFEST_FILE

    Ersetzen Sie WORKLOAD_MANIFEST_FILE durch den Pfad zur Manifestdatei.

    Die Ausgabe enthält detaillierte Informationen dazu, welche Felder in der Arbeitslast nicht mit der angegebenen Zulassungsliste übereinstimmen, wie im folgenden Beispiel:

    Error from server (GKE Warden constraints violations): error when creating "STDIN": admission webhook "warden-validating.common-webhooks.networking.gke.io" denied the request:

===========================================================================
Workload Mismatches Found for Allowlist (example-allowlist-1):
===========================================================================
HostNetwork Mismatch: Workload=true, Allowlist=false
HostPID Mismatch: Workload=true, Allowlist=false
Volume[0]: data
         - data not found in allowlist. Verify volume with matching name exists in allowlist.
Container[0]:
- Envs Mismatch:
        - env[0]: 'ENV_VAR1' has no matching string or regex pattern in allowlist.
        - env[1]: 'ENV_VAR2' has no matching string or regex pattern in allowlist.
- Image Mismatch: Workload=k8s.gcr.io/diff/image, Allowlist=k8s.gcr.io/pause2. Verify that image string or regex match.
- SecurityContext:
        - Capabilities.Add Mismatch: the following added capabilities are not permitted by the allowlist: [SYS_ADMIN SYS_PTRACE]
- VolumeMount[0]: data
        - data not found in allowlist. Verify volumeMount with matching name exists in allowlist.

    In diesem Beispiel treten die folgenden Verstöße auf:

    • In der Arbeitslast wird hostNetwork: true angegeben, in der Zulassungsliste jedoch nicht.hostNetwork: true
    • In der Arbeitslast wird hostPID: true angegeben, in der Zulassungsliste jedoch nicht.hostPID: true
    • In der Arbeitslast wird ein Volume mit dem Namen data angegeben, in der Zulassungsliste jedoch nicht.data
    • Im Container werden Umgebungsvariablen mit den Namen ENV_VAR1 und ENV_VAR2 angegeben, in der Zulassungsliste sind diese Umgebungsvariablen jedoch nicht enthalten.
    • Der Container gibt das Image k8s.gcr.io/diff/image an, die Zulassungsliste jedoch k8s.gcr.io/pause2.
    • Der Container fügt die Funktionen SYS_ADMIN und SYS_PTRACE hinzu, aber die Zulassungsliste erlaubt das Hinzufügen dieser Funktionen nicht.
    • Der Container gibt eine Volume-Bereitstellung mit dem Namen data an, aber die Zulassungsliste gibt keine Volume-Bereitstellung mit dem Namen data an.

Wenn Sie eine Arbeitslast bereitstellen, die einem Drittanbieter gehört, wenden Sie sich an diesen Anbieter, um die Verstöße zu beheben. Geben Sie die Ausgabe aus dem vorherigen Schritt im Problem an.

Inkompatible GKE-Version

GKE lehnt möglicherweise eine Arbeitslast ab, wenn in der Zulassungsliste eine GKE-Mindestversion angegeben ist, die neuer als die GKE-Version des Clusters ist.

  1. Prüfen Sie, ob in der Zulassungsliste eine GKE-Mindestversion angegeben ist:

    kubectl describe workloadallowlist ALLOWLIST_NAME | grep "minGKEVersion"

    Ersetzen Sie ALLOWLIST_NAME durch den Namen der Zulassungsliste.

    Wenn die Ausgabe leer ist, wird in der Zulassungsliste keine Mindestversion von GKE angegeben. Überspringen Sie diesen Abschnitt. Wenn die Ausgabe ein Wert ist, gibt die Zulassungsliste eine minimale GKE-Version an.

  2. GKE-Version des Clusters prüfen:

    gcloud container clusters describe CLUSTER_NAME \
    --location=CLUSTER_LOCATION \
    --format="value(currentMasterVersion)"

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME ist der Name des Clusters.
    • CLUSTER_LOCATION: Der Google Cloud Standort des Clusters.

    Die Ausgabe sieht etwa so aus:

    1.32.3-gke.1006000

  3. Wenn die GKE-Version des Clusters älter als die minimale GKE-Version der Zulassungsliste ist, führen Sie ein Upgrade des Clusters auf die minimale GKE-Version der Zulassungsliste oder höher durch. Weitere Informationen finden Sie unter Cluster upgraden.

Versuchen Sie nach Abschluss des Upgrades, die Arbeitslast im Cluster bereitzustellen.

String-Abweichungen

Bestimmte Felder in der WorkloadAllowlist-Spezifikation müssen exakte String-Übereinstimmungen der entsprechenden Felder in der Arbeitslastspezifikation sein.

  1. Referenzseite für die CustomResourceDefinition (CRD) „WorkloadAllowlist“ öffnen
  2. Prüfen Sie für jedes Feld in Ihrer WorkloadAllowlist-Spezifikation, ob für das CRD eine genaue String-Übereinstimmung erforderlich ist.

  3. Prüfen Sie für jedes Feld, für das eine genaue String-Übereinstimmung erforderlich ist, ob der Wert in Ihrer WorkloadAllowlist-Spezifikation mit dem entsprechenden Wert in Ihrer Arbeitslastspezifikation übereinstimmt.

    Beispielsweise muss jeder Befehl, der in einem Container ausgeführt wird, genau mit einem Befehl in der Zulassungsliste übereinstimmen. Jede Abweichung vom genauen Befehl führt zu einer Ablehnung.

Wenn es eine Diskrepanz gibt, aktualisieren Sie die WorkloadAllowlist-Spezifikation, damit sie mit der Spezifikation Ihrer Arbeitslast übereinstimmt.

Fehler bei regulären Ausdrücken

Bestimmte Felder in der WorkloadAllowlist-Spezifikation unterstützen den Abgleich mit regulären Ausdrücken.

  1. Suchen Sie in der WorkloadAllowlist-Spezifikation nach den Feldern, in denen reguläre Ausdrücke angegeben werden.

  2. Achten Sie darauf, dass die Syntax des regulären Ausdrucks korrekt ist. Das CRD „WorkloadAllowlist“ unterstützt die Syntax für reguläre Ausdrücke für Google RE2. Prüfen Sie, ob Ihre Ausdrücke die folgenden Eigenschaften haben:

    • Der reguläre Ausdruck beginnt mit dem Zeichen ^ und endet mit dem Zeichen $. Beispiel: ^example-auth\.google\.com\/go_[a-z0-9]+\/google\/path$.
    • Jedes Sonderzeichen wird mit dem Escape-Zeichen \ maskiert. Achten Sie auf zusätzliche oder fehlende \-Zeichen.
    • Image-Pfade in der Zulassungsliste enthalten keine Tags oder Digests. Verwenden Sie beispielsweise k8s.gcr.io/pause statt k8s.gcr.io/pause:3.1 oder k8s.gcr.io/pause@sha256:1234567890.

Nachdem Sie alle Probleme mit regulären Ausdrücken behoben haben, versuchen Sie, die Arbeitslast im Cluster bereitzustellen.

Zeichen in Befehlen und Argumenten maskieren

GKE kann Befehle und Argumente nicht abgleichen, wenn Sie die Sonderzeichen nicht mit Escapezeichen versehen. Die Anforderungen für das Escapen von Zeichen hängen davon ab, wie Sie die Zulassungsliste anwenden. Wenn Sie beispielsweise eine Zulassungsliste als YAML- oder JSON-Datei anwenden, gelten andere Anforderungen an die Escape-Sequenzen als beim Erstellen einer Zulassungslistenspezifikation mit einem Befehlszeilentool. In diesem Abschnitt werden die Anforderungen für die Escape-Sequenzen für YAML-Dateien beschrieben.

Setzen Sie jedes Sonderzeichen in den Feldern commands und args der WorkloadAllowlist-Spezifikation in Escapezeichen, auch wenn Sie keinen regulären Ausdruck verwenden. Zum Escaping von Sonderzeichen verwenden Sie das Zeichen \, wie in den folgenden Beispielen:

  • Befehl: kubectl describe \$\{POD_NAME\}
  • Argument: hostname \$NODE_NAME; dcgm-exporter --remote-hostengine-info \$\(NODE_IP\) --collectors /etc/dcgm-exporter/counters.csv

Webhook-Beeinträchtigung von Arbeitslasten auf einer Zulassungsliste

In einigen Fällen kann eine Arbeitslast von GKE abgelehnt werden, auch wenn sie korrekt konfiguriert ist und mit einer Zulassungsliste übereinstimmt. Dies kann passieren, wenn ein anderer Zugangs-Controller (Webhook) in Ihrem Cluster die von dem Workload-Controller erstellten Pods ändert, nachdem sie von der Zulassungsliste zugelassen wurden. Diese Änderungen können dazu führen, dass die Pod-Spezifikation nicht mehr mit der Zulassungsliste übereinstimmt, was zur Ablehnung durch den GKE Warden-Zugangs-Webhook führt.

Dieses Problem tritt häufig bei Überwachungs- und Sicherheits-Agents von Drittanbietern auf, die Sidecar-Container oder Umgebungsvariablen in Pods einfügen.

Das häufigste Symptom ist, dass der Controller für die Arbeitslast (z. B. ein DaemonSet oder Deployment) erfolgreich erstellt wird, aber keine Pods erstellt werden können. Wenn Sie die Ereignisse des Controllers untersuchen, sehen Sie Meldungen, die darauf hinweisen, dass die Pods vom Admission-Webhook abgelehnt wurden.

  1. Folgen Sie der Anleitung im Abschnitt Probleme bei der Bereitstellung privilegierter Arbeitslasten, um Ihrer Arbeitslast das Label cloud.google.com/matching-allowlist hinzuzufügen.
  2. Kopieren Sie die spec.template aus dem YAML-Manifest Ihrer Arbeitslast.
  3. Erstellen Sie ein neues Pod-Manifest und fügen Sie die kopierte Spezifikation in das Feld spec ein.

  4. Legen Sie die Felder apiVersion, kind und metadata.name im Pod-Manifest fest:

    apiVersion: v1
kind: Pod
metadata:
  name: POD_NAME
  labels:
    cloud.google.com/matching-allowlist: ALLOWLIST_NAME
spec:
  # Paste the content of spec.template here

    Ersetzen Sie Folgendes:

    • POD_NAME: Der Name für Ihren Test-Pod.
    • ALLOWLIST_NAME: Der Name der Zulassungsliste.

  5. Wenden Sie das Pod-Manifest an:

    kubectl apply -f YOUR_POD_MANIFEST_FILE

    Ersetzen Sie YOUR_POD_MANIFEST_FILE durch den Pfad zu Ihrer Pod-Manifestdatei.

  6. Prüfen Sie die Ausgabe des vorherigen Schritts. Wenn Sie im Bereich „Workload Mismatches“ (Arbeitslast-Abweichungen) unerwartete Felder sehen, z. B. zusätzliche Umgebungsvariablen (z. B. DD_AGENT_HOST), Container oder Volumes, ist das ein starkes Indiz dafür, dass ein anderer Webhook Ihre Pods ändert.

Um dieses Problem zu beheben, müssen Sie den in Konflikt stehenden Webhook so konfigurieren, dass er die Pods Ihrer zugelassenen Arbeitslast nicht ändert. Dies geschieht in der Regel, indem der Arbeitslast oder ihrem Namespace ein Label oder eine Annotation hinzugefügt wird, um dem Webhook zu signalisieren, dass sie von der Mutation ausgeschlossen werden soll. Wenn Sie beispielsweise Datadog verwenden, fügen Sie dem Namespace Ihrer Arbeitslast das Label admission.datadoghq.com/enabled: "false" hinzu.

Informationen dazu, wie Sie Arbeitslasten aus dem Admission Controller der jeweiligen Drittanbietersoftware ausschließen, finden Sie in der Dokumentation der Software.

Wenn Sie verhindern, dass der andere Webhook die Pods ändert, können Sie dafür sorgen, dass sie weiterhin der Zulassungsliste entsprechen und erfolgreich in Ihrem Autopilot-Cluster bereitgestellt werden.

Fehlerberichte und Feature Requests für privilegierte Arbeitslasten und Zulassungslisten

Wenn Sie eine privilegierte Arbeitslast ausführen, die von einem GKE-Partner oder einem Drittanbieter bereitgestellt wird, ist dieser Anbieter für das Erstellen, Entwickeln und Verwalten seiner privilegierten Arbeitslasten und Zulassungslisten verantwortlich. Wenn Sie einen Fehler finden oder einen Feature Request für eine privilegierte Arbeitslast oder Zulassungsliste eines Partners oder Drittanbieters haben, wenden Sie sich an den Anbieter.

Nächste Schritte