Schlüsselkonzepte

Diese Seite enthält Informationen zu Schlüsselkonzepten im Zusammenhang mit der Binärautorisierung.

Richtlinien

Eine Richtlinie zur Binärautorisierung ist eine Reihe von Regeln, die das Deployment von Container-Images in Google Kubernetes Engine (GKE) steuern. Eine Richtlinie besteht aus folgenden Teilen:

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 Platform-Projekt (GCP) kann genau eine Richtlinie haben. In einer einzelnen Projektkonfiguration wird über diese Richtlinie das Deployment in GKE gesteuert, wobei alle Ressourcen in der Deployment-Pipeline Teil desselben Projekts sind. Bei einer Konfiguration mit mehreren Projekten kann eine einzelne Richtlinie das Deployment von Images aus Container Registry, die sich in einem Projekt befinden, in einem GKE-Cluster steuern, der in einem anderen Projekt ausgeführt wird.

Weitere Informationen finden Sie unter Richtlinien über die Befehlszeile konfigurieren und Richtlinien über die Console konfigurieren.

Regeln

Eine Regel ist Teil einer Richtlinie, die Einschränkungen für Container-Images definiert. Nur Container-Images, die innerhalb dieser Einschränkungen liegen, können bereitgestellt werden. In den meisten Fällen sind für eine Regel eine oder mehrere digital signierte Attestierungen erforderlich. Wurde die Signatur zu jeder erforderlichen Attestierung bestätigt, wodurch angegeben wird, dass alle erforderlichen internen Prozesse abgeschlossen sind, kann der Container bereitgestellt werden. Über eine Regel können auch alle Deployments aus bestimmten Container Registry-Pfaden und/oder in bestimmten GKE-Clustern zugelassen oder abgelehnt werden.

Regeln werden beim Konfigurieren einer Richtlinie definiert. Eine Richtlinie hat eine Standardregel und eine beliebige Anzahl von clusterspezifischen Regeln.

Standardregeln

Jede Richtlinie hat eine Standardregel. Diese Regel gilt für jede Deploymentanfrage, die nicht mit einer clusterspezifischen Regel übereinstimmt. Wenn die Richtlinie keine clusterspezifische Regel enthält, gilt immer die Standardregel. In einer YAML-Richtliniendatei wird die Standardregel im Knoten defaultAdmissionRule angegeben.

Clusterspezifische Regeln

Eine Richtlinie kann auch eine oder mehrere clusterspezifische Regeln enthalten. Dieser Regeltyp ist nur auf Container-Images anwendbar, die ausschließlich auf bestimmten GKE-Clustern bereitgestellt werden sollen. In einer YAML-Richtliniendatei wird jede clusterspezifische Regel in einem clusterAdmissionRule-Knoten angegeben.

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
  • Alle Images ablehnen
  • Attestierungen erforderlich machen

Für eine Regel, die Attestierungen erforderlich macht, muss ein Signer den Container-Image-Digest vor dem Deployment digital signieren und eine Attestierung erstellen. Zum Zeitpunkt des Deployments 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: Ermöglicht das Deployment von nicht konformen Images, schreibt jedoch Details zu sämtlichen Verstößen in das Audit-Log.

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 Nachrichten, die in Cloud Logging geschrieben werden, finden Sie unter Audit-Logs ansehen.

Ausgenommene Images

Ein ausgenommenes Image ist ein Container-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.

Die Zulassungsliste der ausgenommenen Images wird mit dem Attribut admissionWhitelistPatterns in der YAML-Richtliniendatei festgelegt.

Zulassungslistenmuster

So lassen Sie alle Container-Images zu, deren Registry-Speicherort mit dem angegebenen Pfad übereinstimmt:

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 eine bestimmte Image-Version anhand ihres Digests zu:

gcr.io/example-project/helloworld@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c

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 globalen Richtlinie 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 globalen Richtlinie mit dem folgenden Befehl anzeigen lassen:

gcloud container binauthz policy export --project=binauthz-global-policy

Attestierungen

Eine Attestierung ist ein digitales Dokument, das bestätigt, dass GKE das Container-Image bereitstellen darf.

Das Erstellen einer Attestierung wird manchmal als "Signieren eines Images" bezeichnet. Eine Attestierung wird erstellt, nachdem ein Container-Image eingerichtet wurde. Jeder Container hat einen global eindeutigen Digest. Ein Signer signiert den Container-Image-Digest mit einem privaten Schlüssel aus einem Schlüsselpaar und erstellt mit der Signatur die Attestierung. Zum Zeitpunkt des Deployments 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 Container-Image erstellt wurde. Wenn der Signer beispielsweise Teil der Qualitätssicherungsfunktion (quality assurance, QA) ist, deutet die Attestierung möglicherweise darauf hin, dass das Container-Image alle erforderlichen End-to-End-Funktionstests in einer Staging-Umgebung bestanden hat.

Zum Aktivieren der Attestierungen in der Binärautorisierung wird der enforcementMode Ihrer Richtlinie auf REQUIRE_ATTESTATION gesetzt.

Typische Anwendungsfälle finden Sie in der Übersicht über die Binärautorisierung.

Informationen zum Erstellen einer Attestierung finden Sie unter Attestierungen erstellen.

Signaturgeber

Ein Signer ist eine Person oder ein automatisierter Prozess, der eine Attestierung erstellt, indem ein eindeutiger Container-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 dem Deployment des zugehörigen Containers in einem Attestierer gespeichert wurde.

Attestierer

Ein Attestierer ist eine GCP-Ressource, mit der die Binärautorisierung zum Zeitpunkt des Deployments des Container-Images die Attestierung prüft. Attestierer enthalten den öffentlichen Schlüssel, der dem privaten Schlüssel entspricht, der von einem Signer verwendet wird, um den Container-Image-Digest zu signieren und die Attestierung zu erstellen. Der Binärautorisierungserzwinger verwendet zum Zeitpunkt des Deployments den Attestierer, um das Deployment von Container-Images auf die Images zu begrenzen, für die vor dem Deployment eine begleitende, prüfbare Attestierung erstellt wurde.

Attestierer können also von Mitarbeitern des Sicherheitspersonals verwaltet werden, 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 Container-Images verantwortlich sind, diese mit dem privaten Schlüssel signieren und vor dem Deployment die Attestierungen erstellen.

Attestierer haben Folgendes:

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 Container-Image bereit für das Deployment 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.

Weitere Informationen finden Sie unter Attestierer mithilfe der Befehlszeile erstellen oder Attestierer mithilfe der Console erstellen.

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 Container-Image-Deskriptor 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.

Zum Zeitpunkt des Deployments ruft GKE den Binärautorisierungserzwinger auf. Dieser verwendet Attestierer in der Richtlinie, um die Gültigkeit der zugehörigen Attestierungen zu prüfen. So wird sichergestellt, dass jedes digital signierte Container-Image bereitgestellt werden darf.

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.

Hinweise zu Container Analysis

Die Binärautorisierung verwendet Container Analysis, um vertrauenswürdige Metadaten zu speichern, die für den Autorisierungsvorgang verwendet werden. Für jeden von Ihnen erstellten Attestierer muss ein Container Analysis-Hinweis erstellt 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 Container Analysis-Speicher geprüft, ob die erforderlichen Attestierungen vorhanden sind.