Für GKE-Cluster einrichten

Hinweis: Dieses Dokument richtet sich nur an Nutzer von GKE on Bare Metal 1.15 oder früher. Für GKE on Bare Metal 1.16 oder höher kann die Binärautorisierung während der Clustererstellung oder -aktualisierung konfiguriert werden.

Hinweis: Dieses Dokument bzw. dieser Abschnitt enthält Verweise auf einen oder mehrere Begriffe, die Google als respektlos oder anstößig erachtet. Die Begriffe werden verwendet, da es sich um Suchbegriffe der Software handelt, die im Dokument beschrieben wird.

Die Begriffe: whitelist

Vorschau

Dieses Produkt oder diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und -Funktionen sind unverändert verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

In diesem Dokument erfahren Sie, wie Sie die Binärautorisierung für GKE-Cluster einrichten. Anschließend erfahren Sie, wie Sie eine Beispielrichtlinie für die Binärautorisierung konfigurieren.

Hinweise

1. Sie müssen GKE-Cluster bei Connect registriert haben. Die Binärautorisierung unterstützt die folgenden Umgebungen.

   GKE auf Bare-Metal

   GKE on Bare Metal 1.14 oder höher

   GKE on VMware

   GKE on VMware 1.4 oder höher.

2. Der Binärautorisierungsdienst verwendet eine öffentliche IP-Adresse, auf die über eine reguläre Internetverbindung zugegriffen werden kann. Konfigurieren Sie Ihre Firewallregeln für HTTPS so, dass der Nutzercluster auf den Endpunkt binaryauthorization.googleapis.com zugreifen kann.

   GKE auf Bare-Metal

   Konfigurieren Sie GKE on Bare Metal-Firewallregeln.

   GKE on VMware

   Konfigurieren Sie Firewallregeln für GKE auf VMware.

3. Wenn Sie zentralisierte Cloud-Audit-Logs verwenden möchten, um Audit-Logeinträge aufzurufen, einschließlich der Einträge aus der Binärautorisierung für GKE-Cluster, müssen Sie Cloud-Audit-Logs in Ihrer Clusterkonfiguration konfigurieren.

   GKE auf Bare-Metal

   Konfigurieren Sie Cloud-Audit-Logs in GKE on Bare Metal.

   GKE on VMware

   Konfigurieren Sie Cloud-Audit-Logs in GKE on VMware.

4. Sie müssen die Binary Authorization API so aktivieren:

   1. Öffnen Sie die Google Cloud Console.

      APIs aktivieren

   2. Wählen Sie in der Projekt-Drop-down-Liste Ihr Connect-Projekt aus. Sie finden dieses Google Cloud-Projekt im Abschnitt gkeConnect Ihrer Konfigurationsdatei für den Nutzercluster. Dies ist das Google Cloud-Projekt, das Ihren Nutzercluster mit Google Cloud verbindet.

Binärautorisierung einrichten

In diesem Abschnitt richten Sie die Binärautorisierung für GKE-Cluster in Ihrem Cluster ein.

Umgebungsvariablen für die Installation angeben

So geben Sie die Umgebungsvariablen an:

Workload Identity verwenden

1. Geben Sie Ihr Connect-Projekt an:

   export PROJECT_ID=PROJECT_ID
   

2. Geben Sie die Flottenmitgliedschafts-ID Ihres Clusters an:

   export MEMBERSHIP_ID=MEMBERSHIP_ID
   

Dienstkontoschlüssel verwenden

1. Geben Sie Ihr Connect-Projekt an:

   export PROJECT_ID=PROJECT_ID
   

   Ersetzen Sie PROJECT_ID durch das Google Cloud-Projekt im Abschnitt gkeConnect Ihrer Konfigurationsdatei für den Nutzercluster.

2. Geben Sie den Pfad der kubeconfig-Datei des Nutzerclusters an:

   export KUBECONFIG=PATH
   

   Ersetzen Sie PATH durch den Pfad der kubeconfig-Datei des Nutzerclusters.

3. Wählen Sie einen Namen für das Zugriffsdienstkonto der Binary Authorization API:

   export SA_NAME=SERVICE_ACCOUNT_NAME
   

   Ersetzen Sie SERVICE_ACCOUNT_NAME durch den Dienstkontonamen Ihrer Wahl. Das Binärautorisierungsmodul verwendet dieses Dienstkonto, um auf die Binary Authorization API zuzugreifen.

4. Geben Sie den Pfad zur Dienstkonto-Schlüsseldatei an, die Sie später in dieser Anleitung herunterladen:

   export SA_JSON_PATH=SA_KEY_FILE_PATH
   

   Ersetzen Sie SA_KEY_FILE_PATH durch den Pfad zur JSON-Schlüsseldatei für das Dienstkonto.

Binärautorisierungsmodul in Ihrem Nutzercluster installieren

So installieren Sie das Modul für die Binärautorisierung:

Workload Identity verwenden

Mit Fleet Workload Identity können sich die Arbeitslasten in Ihrem Cluster bei Google authentifizieren, ohne dass Sie Google Cloud-Dienstkontoschlüssel herunterladen, manuell rotieren und verwalten müssen. Weitere Informationen zur Funktionsweise von Fleet Workload Identity für Flotten und dessen Vorteilen finden Sie unter Workload Identity für Flotten verwenden.

1. Weisen Sie dem Kubernetes-Dienstkonto in Ihrem Connect-Projekt die Rolle binaryauthorization.policyEvaluator zu:

   gcloud projects add-iam-policy-binding ${PROJECT_ID} \
       --member="serviceAccount:${PROJECT_ID}.svc.id.goog[binauthz-system/binauthz-admin]" \
       --role="roles/binaryauthorization.policyEvaluator"
   

2. Erstellen Sie ein Arbeitsverzeichnis:

   1. Erstellen Sie ein Verzeichnis mit dem Namen binauthz.

   2. Wechseln Sie in das Verzeichnis.

3. Laden Sie die Datei manifest-wi-0.2.6.yaml.tmpl herunter, mit der Sie das Binärautorisierungsmodul in Ihrem GKE-Cluster-Nutzercluster installieren:

   GKE auf Bare-Metal

   gsutil cp gs://anthos-baremetal-release/binauthz/manifest-wi-0.2.6.yaml.tmpl .
   

   GKE on VMware

   gsutil cp gs://gke-on-prem-release/binauthz/manifest-wi-0.2.6.yaml.tmpl .
   

4. Ersetzen Sie die Umgebungsvariablen in der Vorlage:

   envsubst < manifest-wi-0.2.6.yaml.tmpl > manifest-0.2.6.yaml
   

5. Installieren Sie das Binärautorisierungsmodul in Ihrem Nutzercluster:

   kubectl apply -f manifest-0.2.6.yaml
   

6. Prüfen Sie, ob die Bereitstellung erstellt wurde:

   kubectl get pod --namespace binauthz-system
   

   Sie sehen den Pod binauthz-module-deployment-* mit dem Status Running und 1/1 Pods als bereit, ähnlich dieser Ausgabe:

   NAME                                          READY   STATUS    RESTARTS   AGE
   binauthz-module-deployment-5fddf9594f-qjprz   1/1     Running   0          11s
   

Dienstkontoschlüssel verwenden

1. Legen Sie das Standardprojekt für die Google Cloud CLI fest:

   gcloud config set project ${PROJECT_ID}
   

2. Erstellen Sie ein Zugriffsdienstkonto für die Binary Authorization API:

   gcloud iam service-accounts create ${SA_NAME}
   

3. Weisen Sie dem Zugriffdienstkonto für die Binary Authorization API Ihres Connect-Projekts die Rolle binaryauthorization.policyEvaluator zu:

   gcloud projects add-iam-policy-binding ${PROJECT_ID}\
       --member="serviceAccount:${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \
       --role="roles/binaryauthorization.policyEvaluator"
   

4. Erstellen Sie ein Arbeitsverzeichnis:

   1. Erstellen Sie ein Verzeichnis mit dem Namen binauthz.

   2. Wechseln Sie in das Verzeichnis.

5. Laden Sie die Datei manifest-0.2.6.yaml herunter, mit der Sie das Binärautorisierungsmodul in Ihrem GKE-Cluster-Nutzercluster installieren:

   anthos_clusters_on_bare_metal

   gsutil cp gs://anthos-baremetal-release/binauthz/manifest-0.2.6.yaml .
   

   anthos_clusters_on_vmware

   gsutil cp gs://gke-on-prem-release/binauthz/manifest-0.2.6.yaml .
   

6. Erstellen Sie eine YAML-Datei für den Namespace binauthz-system.

   Kopieren Sie Folgendes in eine Datei mit dem Namen namespace.yaml:

   apiVersion: v1
   kind: Namespace
   metadata:
     labels:
       control-plane: binauthz-controller
     name: binauthz-system
   

7. Erstellen Sie den Namespace in Ihrem Nutzercluster:

   kubectl apply -f namespace.yaml
   

   Die Ausgabe sollte in etwa so aussehen:

   namespace/binauthz-system created
   

8. Laden Sie eine JSON-Schlüsseldatei für Ihr Dienstkonto herunter.

   gcloud iam service-accounts keys create ${SA_JSON_PATH} --iam-account ${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com
   

9. Speichern Sie den Dienstkontoschlüssel als Kubernetes-Secret in Ihrem Nutzercluster:

   kubectl --namespace binauthz-system create secret generic binauthz-sa --from-file=key.json=${SA_JSON_PATH}
   

10. Installieren Sie das Binärautorisierungsmodul in Ihrem Nutzercluster:

    kubectl apply -f manifest-0.2.6.yaml
    

11. Prüfen Sie, ob die Bereitstellung erstellt wurde:

    kubectl get pod --namespace binauthz-system
    

    Sie sehen den Pod binauthz-module-deployment-* mit dem Status Running und 1/1 Pods als bereit, ähnlich dieser Ausgabe:

    NAME                                          READY   STATUS    RESTARTS   AGE
    binauthz-module-deployment-5fddf9594f-qjprz   1/1     Running   0          11s
    

Richtlinien für die Binärautorisierung einrichten und verwenden

In diesem Abschnitt erfahren Sie, wie Sie Richtlinien für Binärautorisierungen für GKE-Cluster einrichten und verwenden.

In jedem Beispiel konfigurieren Sie die Richtlinie und testen sie dann. Versuchen Sie dazu, ein Container-Image in Ihrem GKE-Cluster bereitzustellen.

Alle erlauben

In diesem Abschnitt wird ein Erfolgsfall beschrieben. Sie konfigurieren die Richtlinie für die Binärautorisierung so, dass ein Container-Image die Richtlinie erfüllt und bereitgestellt wird.

Achtung: Mit dieser Richtlinie können alle Container-Images bereitgestellt werden.

Gehen Sie in Google Cloud so vor:

Console

1. Rufen Sie in der Google Cloud Console die Seite "Binärautorisierung" auf.

   Zur Binärautorisierung

2. Wählen Sie Ihre Connect-Projekt-ID aus.

3. Klicken Sie auf Richtlinie bearbeiten.

4. Wählen Sie unter Projektstandardregel die Option Alle Images zulassen aus.

5. Klicken Sie auf Save Policy (Richtlinie speichern).

gcloud

1. Legen Sie die PROJECT_ID für Ihr Connect-Projekt fest. Sie finden diese Projekt-ID in der Konfigurationsdatei des Nutzerclusters im Feld gkeConnect.

   export PROJECT_ID=PROJECT_ID
   

   Legen Sie das Google Cloud-Standardprojekt fest.

   gcloud config set project ${PROJECT_ID}
   

2. Exportieren Sie die YAML-Richtliniendatei in Ihr lokales System:

   gcloud container binauthz policy export  > policy.yaml
   

   Ihre YAML-Datei sieht so aus:

   admissionWhitelistPatterns:
   - namePattern: gcr.io/google_containers/*
   - namePattern: gcr.io/google-containers/*
   - namePattern: k8s.gcr.io/**
   - namePattern: gke.gcr.io/**
   - namePattern: gcr.io/stackdriver-agents/*
   globalPolicyEvaluationMode: ENABLE
   defaultAdmissionRule:
     evaluationMode: ALWAYS_ALLOW
     enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
   name: projects/<var>PROJECT_ID</var>/policy
   

3. policy.yaml bearbeiten

4. Setzen Sie evaluationMode auf ALWAYS_ALLOW.

5. Wenn die Datei den Block requireAttestationsBy enthält, löschen Sie diesen Block.

6. Speichern Sie die Datei.

7. Importieren Sie policy.yaml so:

   gcloud container binauthz policy import policy.yaml
   

Führen Sie auf der Administrator-Workstation des GKE-Clusters folgende Schritte aus:

1. Erstellen Sie eine Manifestdatei für einen Pod.

   Speichern Sie Folgendes in einer Datei mit dem Namen pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: test-pod
   spec:
     containers:
     - name: test-container
       image: gcr.io/google-samples/hello-app@sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4
   

2. Erstellen Sie den Pod:

   kubectl apply -f pod.yaml
   

   Sie sehen, dass der Pod erfolgreich bereitgestellt wurde.

3. Löschen Sie den Pod:

   kubectl delete -f pod.yaml
   

Keine zulassen

In diesem Abschnitt wird ein Fehlerfall beschrieben. In diesem Abschnitt konfigurieren Sie die Standardrichtlinie, um die Bereitstellung Ihres Container-Images zu verbieten.

Achtung: Diese Richtlinie verhindert die Bereitstellung aller Container-Images.

Gehen Sie in Google Cloud so vor:

Console

1. Rufen Sie in der Google Cloud Console die Seite "Binärautorisierung" auf.

   Zur Binärautorisierung

2. Achten Sie darauf, dass Ihr Connect-Projekt ausgewählt ist.

3. Klicken Sie auf Richtlinie bearbeiten.

4. Wählen Sie unter Projektstandardregel die Option Alle Images ablehnen aus.

5. Klicken Sie auf Richtlinie speichern.

gcloud

1. Setzen Sie die PROJECT_ID auf Ihre Connect-Projekt-ID.

   export PROJECT_ID=PROJECT_ID
   

2. Legen Sie das Google Cloud-Standardprojekt fest.

   gcloud config set project ${PROJECT_ID}
   

3. Exportieren Sie die YAML-Richtliniendatei:

   gcloud container binauthz policy export  > policy.yaml
   

4. policy.yaml bearbeiten

5. Setzen Sie evaluationMode auf ALWAYS_DENY.

6. Wenn die Datei den Block requireAttestationsBy enthält, löschen Sie diesen Block.

7. Speichern Sie die Datei.

8. Importieren Sie policy.yaml so:

   gcloud container binauthz policy import policy.yaml
   

Hinweis: Es kann einige Minuten dauern, bis die Richtlinie wirksam wird.

Führen Sie auf der Administrator-Workstation des GKE-Clusters folgende Schritte aus:

1. Erstellen Sie eine Manifestdatei für einen Pod.

   Speichern Sie Folgendes in einer Datei mit dem Namen pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: test-pod
   spec:
     containers:
     - name: test-container
       image: gcr.io/google-samples/hello-app@sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4
   

2. Erstellen Sie den Pod:

   kubectl apply -f pod.yaml
   

   Sie sehen, dass der Pod nicht bereitgestellt werden konnte. Die Ausgabe sieht in etwa so aus:

   Error from server (VIOLATES_POLICY): error when creating "pod.yaml": admission webhook "binaryauthorization.googleapis.com" denied the request: Denied by default admission rule. Overridden by evaluation mode
   

Ressourcen-ID des Nutzerclusters abrufen

In diesem Abschnitt erfahren Sie, wie Sie die Clusterressourcen-ID für Ihren Nutzercluster erstellen. In Ihrer Binärautorisierungsrichtlinie können Sie clusterspezifische Regeln erstellen. Sie ordnen diese Regeln einer clusterspezifischen Ressourcen-ID zu, die auf Ihrer Cluster-ID basiert.

Die Ressourcen-ID erhalten Sie so:

Console

1. Rufen Sie in der Google Cloud Console die Seite GKE Enterprise-Cluster auf.

   Zu den Clustern

2. Wählen Sie die Connect-Projekt-ID für GKE-Cluster aus. Sie finden diese Projekt-ID im Abschnitt gkeConnect Ihrer Konfigurationsdatei für den Nutzercluster.

3. Suchen Sie unter In Anthos verwaltete Cluster Ihre Cluster-ID in der Spalte Name.

4. Zum Erstellen der Ressourcen-ID fügen Sie der Cluster-ID das Präfix global. hinzu, damit die Ressourcen-ID das folgende Format hat: global.CLUSTER_ID.

gcloud

1. Verwenden Sie SSH, um eine Verbindung zu Ihrer Administrator-Workstation für GKE-Cluster herzustellen.

2. Führen Sie auf der Administrator-Workstation den folgenden Befehl aus:

   kubectl get membership -o yaml
   

3. Rufen Sie die Cluster-ID aus dem Feld spec.owner.id der Ausgabe ab. Beispielausgabe:

   apiVersion: v1
   items:
   - apiVersion: hub.gke.io/v1
     kind: Membership
     ...
     spec:
       owner:
         id: //gkehub.googleapis.com/projects/PROJECT_NUMBER/locations/global/memberships/my-cluster-id
   

   In der Beispielausgabe lautet die Cluster-ID my-cluster-id.

4. Zum Erstellen der Ressourcen-ID fügen Sie der Cluster-ID das Präfix global. hinzu. In diesem Beispiel lautet die Ressourcen-ID global.my-cluster-id.

Sie verwenden diese Ressourcen-ID, wenn Sie clusterspezifische Regeln definieren. Clusterspezifische Regeln mit der Google Cloud Console oder der gcloud CLI festlegen.

Fehlerrichtlinie aktualisieren

Der Webhook des Binärautorisierungsmoduls kann auf fail-open oder fail-close konfiguriert werden.

Fail-Close

So aktualisieren Sie die Fehlerrichtlinie auf "Fail-Close":

1. Bearbeiten Sie die Datei "manifest-0.2.6.yaml" und legen Sie "errorPolicy" auf Fail fest.

2. Aktivieren Sie den Webhook wieder:

   kubectl apply -f manifest-0.2.6.yaml
   

   Die Ausgabe sollte in etwa so aussehen:

   serviceaccount/binauthz-admin unchanged
   role.rbac.authorization.k8s.io/binauthz-role configured
   clusterrole.rbac.authorization.k8s.io/binauthz-role configured
   rolebinding.rbac.authorization.k8s.io/binauthz-rolebinding unchanged
   clusterrolebinding.rbac.authorization.k8s.io/binauthz-rolebinding unchanged
   secret/binauthz-tls unchanged
   service/binauthz unchanged
   deployment.apps/binauthz-module-deployment unchanged
   validatingwebhookconfiguration.admissionregistration.k8s.io/binauthz-validating-webhook-configuration configured
   

Fail-Open

So aktualisieren Sie die Fehlerrichtlinie auf "Fail-Open":

1. Bearbeiten Sie die Datei "manifest-0.2.6.yaml" und legen Sie "errorPolicy" auf Ignore fest.

2. Aktivieren Sie den Webhook wieder:

   kubectl apply -f manifest-0.2.6.yaml
   

   Die Ausgabe sollte in etwa so aussehen:

   serviceaccount/binauthz-admin unchanged
   role.rbac.authorization.k8s.io/binauthz-role configured
   clusterrole.rbac.authorization.k8s.io/binauthz-role configured
   rolebinding.rbac.authorization.k8s.io/binauthz-rolebinding unchanged
   clusterrolebinding.rbac.authorization.k8s.io/binauthz-rolebinding unchanged
   secret/binauthz-tls unchanged
   service/binauthz unchanged
   deployment.apps/binauthz-module-deployment unchanged
   validatingwebhookconfiguration.admissionregistration.k8s.io/binauthz-validating-webhook-configuration configured
   

Weitere Informationen finden Sie unter Webhook-Fehlerrichtlinie.

Bereinigen

1. Das folgende Codebeispiel zeigt, wie Sie den Webhook deaktivieren:

   kubectl delete ValidatingWebhookConfiguration/binauthz-validating-webhook-configuration
   

2. Im folgenden Codebeispiel wird gezeigt, wie der Webhook wieder aktiviert wird:

   kubectl apply -f manifest-0.2.6.yaml
   

3. Im folgenden Codebeispiel wird gezeigt, wie Sie alle Ressourcen löschen, die sich auf die Binärautorisierung beziehen:

   kubectl delete -f manifest-0.2.6.yaml
   kubectl delete namespace binauthz-system
   

Nächste Schritte

• Um die Einhaltung von Richtlinien bei der Pod-Erstellung zu überprüfen, ohne die Erstellung des Pods zu blockieren, siehe Probelauf aktivieren.
• Informationen zum Erzwingen eines Pods, der durch die Binärautorisierungserzwingung andernfalls blockiert werden würde, finden Sie unter Break-Glass verwenden.
• Verwenden Sie den Attestierer built-by-cloud-build, um nur von Cloud Build erstellte Images bereitzustellen (Vorschau).
• Informationen zum Implementieren einer Attestierer-basierten Richtlinie für die Binärautorisierung finden Sie hier:
  • Konfigurieren Sie eine Richtlinie mit der Google Cloud Console oder dem Befehlszeilentool. Legen Sie fest, dass für die Standard- oder clusterspezifische Regel Attestierungen erforderlich sind.
  • Erstellen Sie einen Attestierer mithilfe der Google Cloud Console oder des Befehlszeilentools.
  • Attestierung erstellen.
• Informationen zu Logereignissen im Zusammenhang mit der Binärautorisierung für GKE-Cluster finden Sie unter Cloud-Audit-Logs-Ereignisse ansehen.
• Messwerte überwachen