Sicherheit

Auf dieser Seite wird die Sicherheitsarchitektur von GKE on Azure 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.

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 Azure Daten in etcd und in inaktiven Speicher-Volumes mit von der Azure-Plattform verwalteten Schlüsseln.

GKE on Azure-Cluster speichern Daten auf Azure-Laufwerks-Volumes. Diese Volumes werden immer mit inaktiven Azure Key Vault-Schlüsseln verschlüsselt. Wenn Sie Cluster und Knotenpools erstellen, können Sie einen vom Kunden verwalteten Keyvault-Schlüssel angeben, um die zugrunde liegenden Laufwerks-Volumes des Clusters zu verschlüsseln. Wenn Sie keinen Schlüssel angeben, verwendet Azure den von Azure verwalteten Standardschlüssel innerhalb der Azure-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, können Sie im Parameter --database-encryption-kms-key-arn einen Azure Key Vault-Schlüssel angeben. Dieser Schlüssel wird zur Verschlüsselung der Anwendungsdaten verwendet. Wenn Sie bei der Clustererstellung keinen Schlüssel angeben, erstellt GKE on Azure automatisch einen Schlüssel für den Cluster. Dieses Ressourcenfeld ist unveränderlich und kann nach der Erstellung des Clusters nicht mehr geändert werden.

Sie können auch manuell einen Key Vault-Schlüssel erstellen oder Ihren eigenen Schlüssel (BYOK) mit einem Hardware Security Module (HSM) erstellen. Weitere Informationen finden Sie unter Eigenen Schlüssel verwenden.

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 Azure Key Vault.

  4. Azure Key Vault verwendet einen generierten KEK, um den DEK zu verschlüsseln, und gibt den verschlüsselten DEK an das Azure Key Vault-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 Azure Key Vault 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 Azure Key Vault 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.

Konfigurationsverschlüsselung mit Key Vault Firewall

Wenn Sie einen öffentlichen Schlüssel für die Verschlüsselung übergeben, benötigt das Diensthauptkonto nicht die Berechtigung zum Verschlüsseln, aber die Berechtigung zum Verwalten von Rollenzuweisungen. Am einfachsten ist es, wenn Sie Ihrem Diensthauptkonto die integrierte Azure-Rolle User Access Administrator zuweisen.

Um Ihren Azure Key Vault weiter zu sichern, können Sie die Azure Key Vault-Firewall aktivieren. GKE on Azure kann dann einen öffentlichen Schlüssel zur Verschlüsselung verwenden und den Netzwerkzugriff auf den Key Vault vermeiden.

Um die Firewall zu konfigurieren, laden Sie den Key Vault-Schlüssel mit Azure-Befehlszeile herunter. Sie übergeben den Schlüssel an --config-encryption-public-key, wenn Sie einen Cluster mit dem Google Cloud CLI erstellen.

Sie müssen noch die Dienstendpunkte für Key Vault in allen für Ihren Cluster verwendeten Subnetzen aktivieren. Weitere Informationen finden Sie unter Endpunkte des virtuellen Netzwerkdienstes für Azure Key Vault.

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.

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 Azure stellt Ihre Arbeitslasten auf Knotenpools von Azure-VM-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 Azure-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 Azure 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.

Nächste Schritte