Einrichtung für lokale Cluster

Hinweis: Wenn Sie Google Distributed Cloud (nur Software) auf Bare Metal verwenden, richtet sich dieses Dokument nur an Nutzer von Version 1.15 oder früher. Ab Version 1.16 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 lokale Cluster einrichten, die als Teil von Google Distributed Cloud erstellt wurden. Anschließend erfahren Sie, wie Sie eine Beispielrichtlinie für die Binärautorisierung konfigurieren.

Hinweise

1. Achten Sie darauf, dass Ihre Cluster eine unterstützte Google Distributed Cloud-Version haben. Die Binärautorisierung unterstützt die folgenden Umgebungen.

   Bare Metal

   Google Distributed Cloud 1.14 oder 1.15. Ab Version 1.16 kann die Binärautorisierung während der Clustererstellung oder -aktualisierung konfiguriert werden.

   VMware

   Google Distributed Cloud 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.

   Bare Metal

   Konfigurieren Sie Google Distributed Cloud-Firewallregeln.

   VMware

   Konfigurieren Sie Google Distributed Cloud-Firewallregeln.

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 Cluster außerhalb von Google Cloud, müssen Sie Cloud-Audit-Logs in Ihrer Clusterkonfiguration konfigurieren.

   Bare Metal

   Konfigurieren Sie Cloud-Audit-Logs in Google Distributed Cloud.

   VMware

   Konfigurieren Sie Cloud-Audit-Logs in Google Distributed Cloud.

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 Flotten-Hostprojekt aus. Sie finden dies 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 in Ihrem lokalen Cluster ein.

Umgebungsvariablen für die Installation angeben

So geben Sie die Umgebungsvariablen an:

Workload Identity verwenden

1. Geben Sie das Flotten-Hostprojekt an:

   export PROJECT_ID=PROJECT_ID
   

2. Legen Sie die Mitglieds-ID der Flotte auf Ihre Cluster-ID fest:

   Die Mitglieds-ID wird in der Spalte NAME aufgeführt, wenn Sie den Befehl gcloud container fleet memberships list ausführen.

   export MEMBERSHIP_ID=CLUSTER_NAME
   

Dienstkontoschlüssel verwenden

1. Geben Sie das Flotten-Hostprojekt 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 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 Flotten-Hostprojekt 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 Nutzercluster installieren:

   Bare Metal

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

   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 Zugriffsdienstkonto für die Binary Authorization API Ihres Flotten-Hostprojekts 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 Nutzercluster installieren:

   Bare Metal

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

   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 Binärautorisierungsrichtlinien für lokale Cluster einrichten und verwenden.

In jedem Beispiel konfigurieren Sie die Richtlinie und testen sie dann. Versuchen Sie dazu, ein Container-Image in Ihrem 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 die Flotten-Hostprojekt-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 Flotten-Hostprojekt 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:

   defaultAdmissionRule:
     enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
     evaluationMode: ALWAYS_ALLOW
   globalPolicyEvaluationMode: ENABLE
   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
   

Wenn Sie der Zulassungsliste ein ausgenommenes Image hinzufügen möchten, fügen Sie der Richtliniendatei Folgendes hinzu:

admissionWhitelistPatterns:
  - namePattern: EXEMPT_IMAGE_PATH

Ersetzen Sie EXEMPT_IMAGE_PATH durch den Pfad zu einem Image, das ausgenommen werden soll. Wenn Sie zusätzliche Images ausschließen möchten, fügen Sie zusätzliche - namePattern-Einträge hinzu. Weitere Informationen zu admissionWhitelistPatterns.

Führen Sie auf Ihrer Administrator-Workstation 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 Flotten-Hostprojekt 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. Legen Sie die PROJECT_ID auf die ID des Flotten-Hostprojekts fest.

   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 Ihrer Administrator-Workstation 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. Öffnen Sie in der Google Cloud Console die Seite zu den GKE-Clustern.

   Zu den Clustern

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

3. Suchen Sie in der Clusterliste in der Spalte Name nach Ihrer Cluster-ID.

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 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 Google Distributed Cloud finden Sie unter Cloud-Audit-Logs-Ereignisse ansehen.
• Messwerte überwachen