Diese Seite wurde von der Cloud Translation API übersetzt.

Einrichtung für lokale Cluster

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

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

Bare Metal
GKE on Bare Metal 1.14 oder 1.15. Ab Version 1.16 kann die Binärautorisierung während der Clustererstellung oder -aktualisierung konfiguriert werden.

VMware
GKE on VMware 1.4 oder höher.
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 GKE on Bare Metal-Firewallregeln.

VMware
Konfigurieren Sie Firewallregeln für GKE auf VMware.
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 GKE on Bare Metal.

VMware
Konfigurieren Sie Cloud-Audit-Logs in GKE on VMware.
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

Geben Sie das Flotten-Hostprojekt an:
```
export PROJECT_ID=PROJECT_ID
```
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

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.
Geben Sie den Pfad der kubeconfig-Datei des Nutzerclusters an:
```
export KUBECONFIG=PATH
```
Ersetzen Sie PATH durch den Pfad der kubeconfig-Datei des Nutzerclusters.
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.
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.

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"

Erstellen Sie ein Arbeitsverzeichnis:
1. Erstellen Sie ein Verzeichnis mit dem Namen binauthz.
2. Wechseln Sie in das Verzeichnis.

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 .

Ersetzen Sie die Umgebungsvariablen in der Vorlage:

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

Installieren Sie das Binärautorisierungsmodul in Ihrem Nutzercluster:
```
kubectl apply -f manifest-0.2.6.yaml
```

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

Legen Sie das Standardprojekt für die Google Cloud CLI fest:
```
gcloud config set project ${PROJECT_ID}
```
Erstellen Sie ein Zugriffsdienstkonto für die Binary Authorization API:
```
gcloud iam service-accounts create ${SA_NAME}
```

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"

Erstellen Sie ein Arbeitsverzeichnis:
1. Erstellen Sie ein Verzeichnis mit dem Namen binauthz.
2. Wechseln Sie in das Verzeichnis.
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 .
```
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
```
Erstellen Sie den Namespace in Ihrem Nutzercluster:
```
kubectl apply -f namespace.yaml
```
Die Ausgabe sollte in etwa so aussehen:
```
namespace/binauthz-system created
```

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

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}

Installieren Sie das Binärautorisierungsmodul in Ihrem Nutzercluster:
```
kubectl apply -f manifest-0.2.6.yaml
```

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.

Gehen Sie in Google Cloud so vor:

Console

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

Zur Binärautorisierung
Wählen Sie die Flotten-Hostprojekt-ID aus.
Klicken Sie auf Richtlinie bearbeiten.
Wählen Sie unter Projektstandardregel die Option Alle Images zulassen aus.
Klicken Sie auf Save Policy (Richtlinie speichern).

gcloud

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}
```

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

policy.yaml bearbeiten
Setzen Sie evaluationMode auf ALWAYS_ALLOW.
Wenn die Datei den Block requireAttestationsBy enthält, löschen Sie diesen Block.
Speichern Sie die Datei.

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:

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

Erstellen Sie den Pod:
```
kubectl apply -f pod.yaml
```
Sie sehen, dass der Pod erfolgreich bereitgestellt wurde.
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.

Gehen Sie in Google Cloud so vor:

Console

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

Zur Binärautorisierung
Achten Sie darauf, dass Ihr Flotten-Hostprojekt ausgewählt ist.
Klicken Sie auf Richtlinie bearbeiten.
Wählen Sie unter Projektstandardregel die Option Alle Images ablehnen aus.
Klicken Sie auf Richtlinie speichern.

gcloud

Legen Sie die PROJECT_ID auf die ID des Flotten-Hostprojekts fest.
```
export PROJECT_ID=PROJECT_ID
```
Legen Sie das Google Cloud-Standardprojekt fest.
```
gcloud config set project ${PROJECT_ID}
```

Exportieren Sie die YAML-Richtliniendatei:

gcloud container binauthz policy export  > policy.yaml

policy.yaml bearbeiten
Setzen Sie evaluationMode auf ALWAYS_DENY.
Wenn die Datei den Block requireAttestationsBy enthält, löschen Sie diesen Block.
Speichern Sie die Datei.

Importieren Sie policy.yaml so:

gcloud container binauthz policy import policy.yaml

Führen Sie auf Ihrer Administrator-Workstation folgende Schritte aus:

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

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

Öffnen Sie in der Google Cloud Console die Seite zu den GKE-Clustern.

Zu den Clustern
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.
Suchen Sie in der Clusterliste in der Spalte Name nach Ihrer Cluster-ID.
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

Verwenden Sie SSH, um eine Verbindung zu Ihrer Administrator-Workstation herzustellen.
Führen Sie auf der Administrator-Workstation den folgenden Befehl aus:
```
kubectl get membership -o yaml
```

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.

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":

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

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":

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

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

Das folgende Codebeispiel zeigt, wie Sie den Webhook deaktivieren:

kubectl delete ValidatingWebhookConfiguration/binauthz-validating-webhook-configuration

Im folgenden Codebeispiel wird gezeigt, wie der Webhook wieder aktiviert wird:
```
kubectl apply -f manifest-0.2.6.yaml
```
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