Container bereitstellen (GKE, Distributed Cloud)

Auf dieser Seite wird erläutert, wie Sie ein Container-Image in einem GKE-Cluster (aufGoogle Cloud oder Google Distributed Cloud) bereitstellen, in dem die Binärautorisierung aktiviert ist. Die kubectl-Befehle, die Sie zum Bereitstellen des Images verwenden, sind mit denen identisch, die Sie zum Bereitstellen von Images in Clustern ohne Binärautorisierung verwenden.

Hinweise

Achten Sie darauf, dass die Binärautorisierung in Ihrem Projekt und ein GKE-Cluster mit aktivierter Binärautorisierung aktiviert ist. Siehe In Google Kubernetes Engine einrichten oder In Distributed Cloud einrichten.

Installieren Sie kubectl für die Interaktion mit GKE.

kubectl konfigurieren

Sie müssen für Ihre kubectl-Installation die lokale Datei kubeconfig aktualisieren. Damit werden die Anmeldedaten und Endpunktinformationen bereitgestellt, die für den Zugriff auf den Cluster in GKE oder Distributed Cloud erforderlich sind.

Führen Sie den folgenden gcloud-Befehl aus, um kubectl zu konfigurieren:

GKE 

gcloud container clusters get-credentials \
    --zone ZONE \
    CLUSTER_NAME

Ersetzen Sie Folgendes:

  • ZONE ist der Name der GKE-Zone, in der der Cluster ausgeführt wird, z. B. us-central1-a
  • CLUSTER_NAME ist der Name des Clusters.

Distributed Cloud 

gcloud container fleet memberships get-credentials \
    --location LOCATION \
    MEMBERSHIP_NAME

Ersetzen Sie Folgendes:

  • LOCATION: der Standort der Flottenmitgliedschaft des GKE-Cluster, z. B. global
  • MEMBERSHIP_NAME: der Name der Fleet-Mitgliedschaft des GKE-Cluster

Container-Image bereitstellen

Stellen Sie das Container-Image so bereit:

  1. Konfigurieren Sie Umgebungsvariablen:

    POD_NAME=POD_NAME
IMAGE_PATH=IMAGE_PATH
IMAGE_DIGEST=IMAGE_DIGEST

    Ersetzen Sie Folgendes:

    • POD_NAME ist der Name, den Sie für die GKE-Arbeitslast verwenden möchten.
    • IMAGE_PATH: Pfad des Images in Artifact Registry oder einer anderen Registry.

    • IMAGE_DIGEST: Der Digest des Image-Manifests. Beispiel:

      • Artifact Registry:
        • Pfad: us-docker.pkg.dev/google-samples/containers/gke/hello-app
        • Digest: sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567

      Informationen zum Abrufen des Digests eines Images in Artifact Registry finden Sie unter Images verwalten.

  2. Stellen Sie das Image mit dem Befehl kubectl run bereit.

    Sie müssen das Image mit dem Digest anstelle eines Tags wie 1.0 oder latest bereitstellen, da die Binärautorisierung den Digest zur Suche nach Attestierungen verwendet.

    Führen Sie den folgenden kubectl-Befehl aus, um das Image bereitzustellen:

    kubectl run ${POD_NAME} \
    --image ${IMAGE_PATH}@${IMAGE_DIGEST}

    Prüfen Sie, ob das Deployment durch die Binärautorisierung blockiert wurde:

    kubectl get pods

    Der Pod wird angezeigt.

Beschränkungen

Bei der Bereitstellung scannt die Binärautorisierung nur Images in den Feldern containers und ephemeralContainers der PodSpec. Andere Felder werden nicht gescannt. Init-Container und Image-Volumes werden bei der Bereitstellung nicht gescannt.

Fail-Open

Wenn die GKE den Binärautorisierungsserver aus irgendeinem Grund nicht erreichen kann oder wenn der Server einen Fehler zurückgibt, kann die GKE nicht feststellen, ob die Binärautorisierung das Image zulassen oder ablehnen würde. In diesem Fall erfolgt in GKE ein Fail-Open: Das Image wird standardmäßig bereitgestellt. Es wird aber ein Logeintrag in den Cloud-Audit-Logs erstellt, um aufzuzeichnen, warum das Image zugelassen wurde.

Die GKE-Erzwingung führt zu einem Fail-Open aufgrund eines Kompromisses zwischen Zuverlässigkeit und Sicherheit. GKE sendet bei jedem Erstellen oder Aktualisieren eines Pods eine Anfrage an die Binärautorisierung. Dies umfasst Szenarien, in denen Pods automatisch von Kubernetes-Arbeitslast-Controllern auf höherer Ebene wie ReplicaSets und StatefulSets erstellt oder aktualisiert werden. Wenn in GKE ein Fail-Closed statt eines Fail-Open erfolgt, würde jeder Ausfall der Binärautorisierung die Ausführung dieser Pods stoppen. Wenn Pods abgelehnt werden, kann ein Failover außerdem zu kaskadierenden Ausfällen führen, da der umgeleitete Traffic die noch ausgeführten Pods überlastet. Ein Ausfall der Binärautorisierung kann zu einem vollständigen Ausfall Ihres Clusters führen, auch wenn keine neuen Images bereitgestellt werden.

Images bereitstellen, die gegen die Richtlinie verstoßen

Die Binärautorisierung unterstützt ein Feature mit dem Namen Break-Glass, mit dem ein Image bereitgestellt werden kann, auch wenn es gegen die Richtlinie verstößt.

Weitere Informationen finden Sie unter Break-Glass verwenden.

Bereinigen

Löschen Sie zum Bereinigen den Pod mit dem folgenden Befehl:

  kubectl delete pod ${POD_NAME}

Nächste Schritte