Sicherheit

Auf dieser Seite wird die Sicherheitsarchitektur von GKE on AWS beschrieben, einschließlich Verschlüsselung und Knotenkonfiguration.

GKE-Cluster bieten Features zum Schutz Ihrer Arbeitslasten, einschließlich des Inhalts Ihres Container-Images, der Containerlaufzeit, des Clusternetzwerks und des Zugriffs auf den Cluster-API-Server.

Wenn Sie GKE-Cluster verwenden, erklären Sie sich damit einverstanden, bestimmte Verantwortung für Ihre Cluster zu übernehmen. Weitere Informationen finden Sie unter Gemeinsame Verantwortung von GKE-Clustern.

AWS-KMS-Verschlüsselung

GKE on AWS verwendet vom Kunden verwaltete symmetrische Schlüssel des AWS Key Management Service (KMS), um Folgendes zu verschlüsseln:

Für Produktionsumgebungen empfehlen wir die Verwendung unterschiedlicher Schlüssel für die Konfiguration und die Volume-Verschlüsselung. Um das Risiko weiter zu minimieren, wenn ein Schlüssel manipuliert ist, können Sie auch für jeden der folgenden Schlüssel unterschiedliche Schlüssel erstellen:

Für zusätzliche Sicherheit können Sie eine AWS-KMS-Schlüsselrichtlinie erstellen, die nur den minimal erforderlichen Satz von Berechtigungen zuweist. Weitere Informationen finden Sie unter KMS-Schlüssel mit bestimmten Berechtigungen erstellen.

Verschlüsselung inaktiver Daten

Die Verschlüsselung inaktiver Daten ist die Verschlüsselung gespeicherter Daten, im Gegensatz zu den Daten bei der Übertragung. Standardmäßig verschlüsselt GKE on AWS Daten in etcd und inaktiven Speicher-Volumes mit von der AWS-Plattform verwalteten Schlüsseln.

GKE on AWS-Cluster speichern Daten auf AWS Elastic Block Storage-Volumes (EBS-Volumes). Diese EBS-Volumes werden immer mit inaktiven AWS-KMS-Schlüsseln (AWS Key Management System) verschlüsselt. Beim Erstellen von Clustern und Knotenpools können Sie einen vom Kunden verwalteten KMS-Schlüssel (Customer-Managed KMS Key, CMK) bereitstellen, um die zugrunde liegenden EBS-Volumes zu verschlüsseln. Wenn Sie keinen Schlüssel angeben, verwendet AWS den von AWS verwalteten Standardschlüssel in der AWS-Region, in der der Cluster ausgeführt wird.

Darüber hinaus aktivieren alle GKE-Cluster die Verschlüsselung von Secrets auf Anwendungsebene für sensible Daten wie Secret-Objekte von Kubernetes, die in etcd gespeichert sind. Selbst wenn Angreifer Zugriff auf das zugrunde liegende Volume erhalten, in dem etcd-Daten gespeichert sind, werden diese Daten verschlüsselt.

Wenn Sie einen Cluster erstellen, müssen Sie einen AWS KMS-Schlüssel an das Feld --database-encryption-kms-key-arn übergeben. Dieser Schlüssel wird für die Umschlagverschlüsselung von Anwendungsdaten verwendet. Da dieses Ressourcenfeld unveränderlich ist und nach der Erstellung des Clusters nicht mehr geändert werden kann, empfehlen wir die Verwendung eines KMS-Schlüsselalias. Mit einem Schlüsselalias können Sie die Schlüssel, die für die Verschlüsselung inaktiver Daten verwendet werden, während des gesamten Lebenszyklus des Clusters rotieren.

Verschlüsselung auf Anwendungsebene

Kubernetes bietet eine Verschlüsselung auf Anwendungsebene mit einer Technik, die als Umschlagverschlüsselung bezeichnet wird. Zum Verschlüsseln eines Secrets wird ein lokaler Schlüssel verwendet. Dieser wird im Allgemeinen als Data Encryption Key (DEK) bezeichnet. Der DEK selbst wird dann mit einem zweiten Schlüssel, dem Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK), verschlüsselt. Der KEK wird nicht von Kubernetes gespeichert. Wenn Sie ein neues Kubernetes-Secret erstellen, führt der Cluster folgende Schritte aus:

  1. Der Kubernetes API-Server generiert mit einem Zufallszahlengenerator einen eindeutigen DEK für das Secret.

  2. Der Kubernetes API-Server verschlüsselt das Secret lokal mit dem DEK.

  3. Der Kubernetes API-Server sendet den DEK zur Verschlüsselung an AWS KMS.

  4. AWS KMS verwendet einen vorab generierten KEK, um den DEK zu verschlüsseln, und gibt den verschlüsselten DEK an das AWS KMS-Plug-in des Kubernetes API-Servers zurück.

  5. Der Kubernetes API-Server speichert das verschlüsselte Secret und den verschlüsselten DEK unter etcd. Der Klartext-DEK wird nicht auf dem Laufwerk gespeichert.

  6. Der Kubernetes API-Server erstellt einen In-Memory-Cache-Eintrag, um den verschlüsselten DEK dem Klartext-DEK zuzuordnen. Dadurch kann der API-Server kürzlich aufgerufene Secrets entschlüsseln, ohne den AWS KMS abzufragen.

Wenn ein Client ein Secret vom Kubernetes API-Server anfordert, passiert Folgendes:

  1. Der Kubernetes API-Server ruft das verschlüsselte Secret und den verschlüsselten DEK aus etcd ab.

  2. Der Kubernetes API-Server prüft den Cache auf einen vorhandenen Zuordnungseintrag und, falls einer gefunden wird, entschlüsselt das Secret damit.

  3. Wenn kein übereinstimmender Cache-Eintrag vorhanden ist, sendet der API-Server den DEK an AWS KMS zur Entschlüsselung mithilfe des KEK. Der entschlüsselte DEK wird dann zur Entschlüsselung des Secrets verwendet.

  4. Der Kubernetes API-Server gibt das entschlüsselte Secret an den Client zurück.

Schlüsselrotation

Im Gegensatz zur Zertifikatsrotation ist die Schlüsselrotation der Vorgang, bei dem das zugrunde liegende kryptografische Material in einem Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK) geändert wird. Sie kann automatisch im Rahmen einer geplanten Rotation oder manuell ausgelöst werden, normalerweise nach einem Sicherheitsvorfall, bei dem Schlüssel möglicherweise manipuliert wurden. Bei der Schlüsselrotation wird nur das einzelne Feld im Schlüssel ersetzt, das die Rohdaten zum Verschlüsselungs-/Entschlüsselungsschlüssel enthält.

KMS-Schlüsselrotation

AWS KMS unterstützt die automatische Rotation von KMS-Schlüsseln. Wenn diese Option aktiviert ist, generiert AWS einmal pro Jahr automatisch neues kryptografisches Schlüsselmaterial für Ihren Schlüssel. Es sind keine manuellen Maßnahmen erforderlich.

Weitere Informationen finden Sie unter Schlüsselrotation.

Cluster Trust

Bei der gesamten Clusterkommunikation wird Transport Layer Security (TLS) verwendet. Jeder Cluster wird mit den folgenden selbst signierten Stamm-CAs (Certificate Authorities, Zertifizierungsstelle) bereitgestellt:

  • Die Stammzertifizierungsstelle des Clusters wird zur Validierung von Anfragen verwendet, die an den API-Server gesendet werden.
  • Die etcd-Stamm-CA wird verwendet, um Anfragen zu validieren, die an etcd-Replikate gesendet werden.

Jeder Cluster hat eine eindeutige Stamm-CA. Wenn die Zertifizierungsstelle eines Clusters gehackt wurde, ist keine Zertifizierungsstelle eines anderen Clusters betroffen. Alle Stamm-CAs haben eine Gültigkeitsdauer von 30 Jahren.

Knotensicherheit

GKE on AWS stellt Ihre Arbeitslasten auf Knotenpools von AWS EC2-Instanzen bereit. Im folgenden Abschnitt werden Sicherheitsfeatures von Knoten erläutert.

Ubuntu

Auf Ihren Knoten wird eine optimierte Version des Ubuntu-Betriebssystems ausgeführt, um die Kubernetes-Steuerungsebene und -Knoten auszuführen. Weitere Informationen finden Sie unter Sicherheitsfeatures in der Ubuntu-Dokumentation.

GKE-Cluster implementieren unter anderem die folgenden Sicherheitsfunktionen:

  • Optimiertes Paket

  • Google Cloud-spezifischer Linux-Kernel

  • Eingeschränkte Nutzerkonten und eine deaktivierte Rootanmeldung

Für Ubuntu sind zusätzliche Sicherheitsleitfäden verfügbar, z. B.:

Arbeitslasten sichern

Kubernetes bietet Nutzern die Möglichkeit, containerbasierte Arbeitslasten schnell bereitzustellen, zu skalieren und zu aktualisieren. In diesem Abschnitt werden Taktiken beschrieben, mit denen Sie die Nebenwirkungen der Ausführung von Containern in Clustern und den Google Cloud-Diensten begrenzen können.

Verarbeitungsrechte für Podcontainer einschränken

Für die Sicherheit des Clusters ist es wichtig, die Berechtigungen von containerisierten Prozessen einzuschränken. Sie können sicherheitsrelevante Optionen mit einem Sicherheitskontext festlegen. Sie haben dadurch die Möglichkeit, die Sicherheitseinstellungen etwa von folgenden Prozessen zu ändern:

  • Nutzer und Gruppe für die Ausführung des Prozesses
  • Verfügbare Linux-Funktionen
  • Rechteausweitung

Das standardmäßige GKE on AWS-Knotenbetriebssystem Ubuntu verwendet die standardmäßigen Docker AppArmor-Sicherheitsrichtlinien für alle Container. Sie können die Profilvorlage auf GitHub ansehen. Dieses Profil verweigert unter anderem Containern die folgenden Aktionen:

  • Direktes Schreiben in Dateien in einem Prozess-ID-Verzeichnis (/proc/)
  • Schreiben in Dateien, die sich nicht in /proc/ befinden
  • Schreiben in Dateien in /proc/sys außer /proc/sys/kernel/shm*
  • Bereitstellen von Dateisystemen

Möglichkeit einschränken, dass sich Arbeitslasten selbst ändern

Bestimmte Kubernetes-Arbeitslasten, insbesondere Systemarbeitslasten, haben die Berechtigung, sich selbst zu ändern. Beispielsweise werden einige Arbeitslasten automatisch vertikal skaliert. Dies ist zwar praktisch, kann einem Angreifer, der bereits einen Knoten manipuliert hat, aber auch die Möglichkeit bieten, im Cluster weiter zu eskalieren. Ein Angreifer kann beispielsweise dafür sorgen, dass sich eine Arbeitslast auf dem Knoten selbst ändert, um als ein privilegierteres Dienstkonto ausgeführt zu werden, das im selben Namespace vorhanden ist.

Idealerweise sollten Arbeitslasten nicht die Berechtigung erhalten, sich selbst zu ändern. Wenn eine Selbständerung erforderlich ist, können Sie die Berechtigungen einschränken, indem Sie Policy Controller oder Gatekeeper in Ihrem Cluster installieren. Wenden Sie Einschränkungen an, z. B. NoUpdateServiceAccount aus der Open-Source-Gatekeeper-Bibliothek, die mehrere nützliche Sicherheitsrichtlinien bietet.

Wenn Sie Richtlinien bereitstellen, müssen die Controller, die den Clusterlebenszyklus verwalten, normalerweise die Möglichkeit haben, die Richtlinien zu umgehen. Dies ist erforderlich, damit die Controller Änderungen am Cluster vornehmen können, indem sie z. B. Clusterupgrades anwenden. Wenn Sie beispielsweise die Richtlinie NoUpdateServiceAccount in GKE on AWS bereitstellen, müssen Sie die folgenden Parameter in Constraint festlegen:

parameters:
  allowedGroups: []
  allowedUsers:
  - service-PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com

Ersetzen Sie PROJECT_NUMBER durch die Nummer (nicht die ID) des Projekts, in dem der Cluster gehostet wird.

Binärautorisierung verwenden

Eine weitere Möglichkeit, Ihre Arbeitslasten zu schützen, ist die Aktivierung der Binärautorisierung. Die Binärautorisierung ist ein Sicherheitsfeature, mit dem sichergestellt wird, dass nur vertrauenswürdige Container-Images in GKE-Clustern bereitgestellt werden.

So funktioniert der Prozess:

  1. Administratoren erstellen eine Richtlinie, die die Anforderungen für die Bereitstellung eines Images definiert. Dazu gehört die Angabe der vertrauenswürdigen und autorisierten Entitäten (Attestierer), die Images signieren können, und es können auch andere Kriterien einbezogen werden, die ein Image erfüllen muss, um als sicher für das Deployment eingestuft zu werden.

  2. Ein Attestierer (z. B. ein Entwickler oder ein automatisiertes System) generiert mithilfe eines kryptografischen Algorithmus ein Schlüsselpaar (private und öffentliche Schlüssel).

  3. Der private Schlüssel, der geheim gehalten wird, wird verwendet, um eine digitale Signatur (d. h. einen eindeutigen Satz von Zeichen) für ein Bild zu generieren. Diese Signatur dient als Genehmigungssiegel und gibt an, dass das Bild alle erforderlichen Prüfungen und Validierungen bestanden hat.

  4. Die digitale Signatur wird dann an das Bild "angehängt". Mit anderen Worten, die Signatur wird in den Metadaten des Images gespeichert, normalerweise in der Image-Registry.

  5. Der öffentliche Schlüssel wird dann beim Binärautorisierungssystem registriert, sodass das System den öffentlichen Schlüssel zur Signaturprüfung verwenden kann.

  6. Wenn eine Anfrage zum Bereitstellen eines Containers gestellt wird, ruft das Binärautorisierungssystem die digitale Signatur ab, die an das Image in der Registry angehängt ist.

  7. Das Binärautorisierungssystem verwendet den registrierten öffentlichen Schlüssel, um die an das Image angehängte digitale Signatur zu prüfen. Außerdem wird geprüft, ob das Image alle anderen in der Richtlinie definierten Kriterien erfüllt. Wenn die digitale Signatur mit dem öffentlichen Schlüssel und den Image-Daten erfolgreich verifiziert werden kann und das Image alle anderen in der Richtlinie definierten Kriterien erfüllt, lässt das Binärautorisierungssystem das Deployment des Containers zu. Wenn die digitale Signatur mit dem öffentlichen Schlüssel und den Image-Daten nicht erfolgreich verifiziert werden kann oder das Image andere in der Richtlinie definierte Kriterien nicht erfüllt, lehnt das Binärautorisierungssystem die Containerbereitstellung ab.

Weitere Informationen zur Funktionsweise der Binärautorisierung finden Sie in der Übersicht zur Binärautorisierung.

Informationen zum Aktivieren der Binärautorisierung in einem vorhandenen Cluster oder beim Erstellen eines Clusters finden Sie unter Binärautorisierung aktivieren.

Nächste Schritte