Diese Seite enthält Informationen zu Konzepten im Zusammenhang mit der Binärautorisierung.
Richtlinien
Eine Richtlinie zur Binärautorisierung, auch als Projekt-Singleton-Richtlinie bezeichnet, ist eine Reihe von Regeln, die die Bereitstellung von Container-Images steuern.
Bei der kontinuierlichen Validierung (CV) wird ein anderer Richtlinientyp verwendet, der als Plattformrichtlinie bezeichnet wird.
Eine Richtlinie besteht aus folgenden Teilen:
- Bereitstellungsregeln
- Liste der ausgenommenen Images
Damit können Sie eine Richtlinie konfigurieren:
- Google Cloud Console
gcloud
-Befehle
Wenn Sie gcloud
-Befehle verwenden, exportieren und ändern Sie eine Definition der Richtlinie im YAML-Format, bevor Sie sie wieder in Ihr Projekt importieren. Das YAML-Format gibt die interne Struktur einer Richtlinie im Binärautorisierungsspeicher wieder.
Weitere Informationen zu diesem Format finden Sie in der Referenz zu YAML-Richtlinien.
Jedes Google Cloud-Projekt kann genau eine Richtlinie haben. Sie müssen die Richtlinie in dem Projekt konfigurieren, in dem Sie die Bereitstellungsplattform ausführen. In einer Konfiguration mit einem einzelnen Projekt befinden sich die Richtlinie und alle untergeordneten Ressourcen – Attestierer und Attestierungen – in demselben Projekt. Sie können eine Konfiguration mit mehreren Projekten verwenden, um die Aufgabentrennung einzurichten. In dieser Konfiguration kann die Bereitstellungsplattform in einem Projekt ausgeführt werden, Attestierer können sich in einem anderen Projekt befinden und Attestierungen können sich in noch einem anderen Projekt befinden.
Informationen zu Einrichtung und Verwendung der Binärautorisierung auf unterstützten Plattformen finden Sie unter Nach Plattform einrichten.
Beispiel für GKE mit mehreren Projekten einrichten
Regeln
Wenn Sie eine Richtlinie konfigurieren, definieren Sie die Regeln. Regeln definieren Einschränkungen, die Images erfüllen müssen, bevor sie bereitgestellt werden können. Eine Richtlinie hat eine Standardregel und kann je nach Plattform bestimmte Regeln haben. Weitere Informationen finden Sie unter Unterstützte Regeltypen nach Plattform.
Jede Regel kann mit einem Auswertungsmodus und einem Erzwingungsmodus konfiguriert werden. Eine Regel kann beispielsweise erfordern, dass ein Image ein signiertes Attestierung hat, bevor es bereitgestellt werden kann.
Standardregel
Jede Richtlinie hat eine Standardregel. Diese Regel gilt für jede Deploymentanfrage, die nicht mit einer spezifischen Regel übereinstimmt. In einer YAML-Richtliniendatei wird die Standardregel im Knoten defaultAdmissionRule
angegeben.
Weitere Informationen zum Konfigurieren der Standardregel finden Sie unter Richtlinie konfigurieren.
Spezifische Regeln
Einer Richtlinie können eine oder mehrere bestimmte Regeln hinzugefügt werden. Diese Art von Regel gilt für Images, die in bestimmten Clustern, Dienstkonten oder Identitäten bereitgestellt werden sollen. Die Unterstützung für bestimmte Regeln variiert je nach Plattform. Weitere Informationen finden Sie unter Unterstützte Regeltypen nach Plattform.
In einer YAML-Richtliniendatei wird jede clusterspezifische Regel in einem clusterAdmissionRule
-Knoten angegeben.
Unterstützte Regeltypen nach Plattform
Folgende Tabelle zeigt, welche Regeltypen für die einzelnen Bereitstellungsplattformen unterstützt werden.
Plattform | Standardregel | Spezifische Regel |
---|---|---|
GKE | Unterstützt | Cluster Kubernetes-Namespaces Kubernetes-Dienstkonten |
Cloud Run | Unterstützt | Nicht unterstützt |
In GKE angehängte Cluster | Unterstützt | Cluster Kubernetes-Namespaces Kubernetes-Dienstkonten |
GKE on AWS | Unterstützt | Cluster Kubernetes-Namespaces Kubernetes-Dienstkonten |
GKE on Bare Metal | Unterstützt | Cluster Kubernetes-Namespaces Kubernetes-Dienstkonten |
GKE on VMware | Unterstützt | Cluster Kubernetes-Namespaces Kubernetes-Dienstkonten |
Anthos Service Mesh | Unterstützt | Anthos Service Mesh-Dienst-Identitäten |
Auswertungsmodi
Jede Regel hat einen Auswertungsmodus, der die Art der Einschränkung angibt, die die Binärautorisierung für die Regel erzwingt. Der Auswertungsmodus für eine Regel wird mithilfe des Attributs evaluationMode
in der YAML-Richtliniendatei angegeben.
Es gibt drei Auswertungsmodi:
- Alle Images zulassen: Ermöglicht die Bereitstellung aller Images.
- Alle Images nicht zulassen: Verhindert, dass alle Images bereitgestellt werden.
- Attestierungen erforderlich machen: erfordert, dass ein Signer den Image-Digest digital signiert und vor der Bereitstellung eine Attestierung erstellt. Zum Zeitpunkt der Bereitstellung verwendet der Binärautorisierungserzwinger einen Attestierer, um die Signatur in der Attestierung zu prüfen, bevor das zugehörige Container-Image bereitgestellt wird.
Erzwingungsmodi
Jede Regel hat auch einen Erzwingungsmodus, der die Aktion angibt, die von GKE ausgeführt wird, wenn ein Image nicht der Regel entspricht. Eine Regel kann die folgenden Erzwingungsmodi haben:
Blockieren und Audit-Log: Das Deployment von Images, die nicht der Regel entsprechen, wird blockiert und es wird eine Nachricht in das Audit-Log geschrieben, in der angegeben ist, warum das Image nicht bereitgestellt wurde.
Probelauf: Nur Audit-Log: Der Probelaufmodus ist ein Erzwingungsmodus in einer Richtlinie, der die Bereitstellung von nicht konformen Images ermöglicht. Dabei werden Details zur Bereitstellung in die Cloud Audit-Logs geschrieben. Im Probelaufmodus können Sie eine Richtlinie testen, z. B. in Ihrer Produktionsumgebung, bevor die Erzwingung tatsächlich wirksam wird.
Die meisten Produktionsregeln verwenden den Erzwingungsmodus Blockieren und Audit-Log. Probelauf: Nur Audit-Log wird hauptsächlich zum Testen einer Richtlinie in Ihrer Umgebung verwendet, bevor sie in Kraft tritt.
Der Erzwingungsmodus für eine Regel wird mithilfe des Attributs enforcementMode
in der YAML-Richtliniendatei angegeben.
Weitere Informationen zu in Cloud-Audit-Logs geschriebene Nachrichten finden Sie unter Audit-Logs ansehen (GKE, GKE-Cluster, Anthos Service Mesh) oder Audit-Logs ansehen (Cloud Run).
Kontinuierliche Validierung
Die kontinuierliche Validierung (Continuous Validation, CV) ist eine Funktion der Binärautorisierung, die regelmäßig mit den ausgeführten Pods verknüpfte Images auf kontinuierliche Richtlinienkonformität prüft.
Ausgenommene Images
Ein ausgenommenes Image ist ein Image, das von den Richtlinienregeln ausgenommen ist.
Die Binärautorisierung lässt das Deployment von ausgenommenen Images immer zu. Jedes Projekt hat eine Zulassungsliste von ausgenommenen Images, die durch den Registrierungspfad angegeben wurden. Images im Pfad gcr.io/google_containers/*
, k8s.gcr.io/**
und in weiteren Pfaden sind standardmäßig ausgenommen, da sie Ressourcen enthalten, die benötigt werden, damit GKE einen Cluster bei aktivierter Standardrichtlinie erfolgreich starten kann.
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
.
Zulassungslistenmuster
So lassen Sie alle Images zu, deren Registry-Speicherort mit dem angegebenen Pfad übereinstimmt:
gcr.io/example-project/*
So lassen Sie alle Images zu, deren Registry-Speicherort ein beliebiges Unterverzeichnis des angegebenen Pfads ist (z. B. gcr.io/example-project/my-directory/helloworld
):
gcr.io/example-project/**
So lassen Sie ein bestimmtes Image zu:
gcr.io/example-project/helloworld
So lassen Sie eine bestimmte Version eines Images nach Tag zu:
gcr.io/example-project/helloworld:latest gcr.io/example-project/helloworld:my-tag
So lassen Sie alle Versionen/Tags eines Images zu:
gcr.io/example-project/helloworld:*
So lassen Sie eine bestimmte Image-Version anhand ihres Digests zu:
gcr.io/example-project/helloworld@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c
Container-Image-Digests verwenden
Erfahren Sie, wie Sie ausgenommene Images in der Google Cloud Console, mit dem Befehlszeilentool oder mit der REST API verwalten.
Von Google verwaltete System-Images
Alle von Google verwalteten System-Images als vertrauenswürdig einstufen: veranlasst die Binärautorisierung, eine Liste der von Google verwalteten System-Images von der weiteren Richtlinienauswertung auszuschließen. Ist diese Einstellung aktiviert, werden für GKE erforderliche Images durch die Richtlinienerzwingung nicht blockiert. Die Auswertung der Systemrichtlinie erfolgt vor der Auswertung der Nutzerrichtlinien und zusätzlich dazu.
Sie können diese Einstellung mithilfe des Attributs globalPolicyEvaluationMode
in der YAML-Richtliniendatei aktivieren oder deaktivieren. Sie können sich den Inhalt der Systemrichtlinie mit dem folgenden Befehl anzeigen lassen:
gcloud alpha container binauthz policy export-system-policy
Attestierungen
Eine Attestierung ist ein digitales Dokument, das ein Image zertifiziert. Während der Bereitstellung prüft die Binärautorisierung die Attestierung, bevor das Image bereitgestellt werden kann.
Das Erstellen einer Attestierung wird manchmal als Signieren eines Images bezeichnet. Eine Attestierung wird erstellt, nachdem ein Image erstellt wurde. Jedes Image hat einen global eindeutigen Digest. Ein Signer signiert den Image-Digest mit einem privaten Schlüssel aus einem Schlüsselpaar und erstellt mit der Signatur die Attestierung. Beim Deployment verwendet der Binärautorisierungserzwinger den öffentlichen Schlüssel des Attestierers, um die Signatur in der Attestierung zu prüfen. Normalerweise entspricht ein Attestierer genau einem Signer.
Eine Attestierung gibt an, dass durch das erfolgreiche Ausführen eines bestimmten, erforderlichen Prozesses das zugehörige Image erstellt wurde. Wenn der Signer beispielsweise Teil der Qualitätssicherungsfunktion (quality assurance, QA) ist, deutet die Attestierung möglicherweise darauf hin, dass das Image alle erforderlichen End-to-End-Funktionstests in einer Staging-Umgebung bestanden hat.
Zum Aktivieren der Attestierungen in der Binärautorisierung wird der evaluationMode
Ihrer Richtlinie auf REQUIRE_ATTESTATION
gesetzt.
Attestierer und Attestierungen erstellen und verwenden
Signaturgeber
Ein Signer ist eine Person oder ein automatisierter Prozess, der eine Attestierung erstellt, indem ein eindeutiger Image-Deskriptor mit einem privaten Schlüssel signiert wird. Die Attestierung wird zum Zeitpunkt des Deployments anhand des entsprechenden öffentlichen Schlüssels geprüft, der vor der Bereitstellung des zugehörigen Images in einem Attestierer gespeichert wurde.
Attestierer und Attestierungen erstellen und verwenden
Attestierer
Ein Attestierer ist eine Google Cloud-Ressource, mit der die Binärautorisierung zum Zeitpunkt der Image-Bereitstellung die Attestierung prüft. Attestierer enthalten den öffentlichen Schlüssel, der dem privaten Schlüssel entspricht, der von einem Signer verwendet wird, um den Image-Digest zu signieren und die Attestierung zu erstellen. Der Binärautorisierungserzwinger verwendet zum Zeitpunkt der Bereitstellung den Attestierer, um die Bereitstellung von Images auf diejenigen zu begrenzen, für die vor der Bereitstellung eine begleitende, prüfbare Attestierung erstellt wurde.
Attestierer werden häufig von Mitarbeitern des Sicherheitspersonals verwaltet, die auch die öffentlichen und privaten Schlüsselpaare verwalten. Bei Signern handelt es sich in der Regel um Softwareentwickler oder für die Qualitätssicherung zuständige DevOps- oder Compliance-Mitarbeiter, die für die Erstellung von bereitstellbaren Images verantwortlich sind, diese mit dem privaten Schlüssel signieren und vor der Bereitstellung die Attestierungen erstellen.
Attestierer haben Folgendes:
- Einen entsprechenden Artefaktanalyse-Hinweis
- Einen oder mehrere kryptografische öffentliche Schlüssel, die dem privaten Schlüssel entsprechen, den der Signer zum Erstellen einer Attestierung verwendet hat.
Wenn Sie eine Richtlinie mit einer Regel einrichten, die Attestierungen erforderlich macht, müssen Sie für jede Person oder jeden Prozess, die bzw. der prüfen muss, ob das Image bereit für die Bereitstellung ist, einen Attestierer hinzufügen. Sie können Attestierer über die Google Cloud Console, die gcloud
-Benutzeroberfläche oder die REST API der Binärautorisierung hinzufügen.
Attestierer und Attestierungen erstellen und verwenden
Kryptografische Schlüssel
Die Binärautorisierung verwendet digitale Signaturen, um zum Zeitpunkt des Deployments Images zu prüfen, wenn die Richtlinie eine Regel enthält, die Attestierungen erforderlich macht.
Es wird ein Schlüsselpaar generiert. Der private Schlüssel wird vom Signer verwendet, um einen Bilddeskriptor zu signieren. Dadurch wird eine Attestierung erstellt.
Anschließend wird ein Attestierer erstellt und in der Richtlinie gespeichert. Der öffentliche Schlüssel, der dem privaten Schlüssel zum Signieren entspricht, wird hochgeladen und an den Attestierer angehängt.
Wenn ein Versuch zum Bereitstellen eines Image unternommen wird, verwendet die Binärautorisierung Attestierer in der Richtlinie, um die Attestierungen des Images zu prüfen. Wenn die Attestierung verifiziert werden kann, wird das Image bereitgestellt.
Die Binärautorisierung unterstützt zwei Arten von Schlüsseln:
PKIX-Schlüssel können lokal, extern oder im Cloud Key Management Service gespeichert werden.
Erstellen Sie einen kryptografischen Schlüssel und einen Attestierer.
Artefaktanalyse-Hinweise
Die Binärautorisierung verwendet Artefaktanalyse, um vertrauenswürdige Metadaten zu speichern, die für den Autorisierungsvorgang verwendet werden. Für jeden von Ihnen erstellten Attestierer muss ein Artefaktanalyse-Hinweis angelegt werden. Jede Attestierung wird als ein Vorkommen dieses Hinweises gespeichert.
Wenn die Binärautorisierung eine Regel auswertet, die erfordert, dass Attestierer ein Image geprüft haben, wird im Artefaktanalyse-Speicher geprüft, ob die erforderlichen Attestierungen vorhanden sind.