Sicherheit von Clustern erhöhen

Durch die kontinuierliche Weiterentwicklung von Kubernetes stehen häufig neue Sicherheitsfunktionen zur Verfügung. Auf dieser Seite werden Sie durch die Implementierung unserer aktuellen Anleitung zum Härten Ihres Google Kubernetes Engine-Clusters (GKE) geführt.

In diesem Leitfaden werden vor allem wichtige Sicherheitsmaßnahmen behandelt, die eine Aktion des Kunden zum Zeitpunkt der Clustererstellung erfordern. Weniger zentrale Features, sichere Standardeinstellungen sowie Einstellungen, die nach der Erstellung aktiviert werden können, werden weiter unten in diesem Dokument behandelt. Einen allgemeinen Überblick über Sicherheitsthemen finden Sie unter Übersicht über die Sicherheit.

Viele dieser Empfehlungen sowie andere häufige Fehlkonfigurationen können mithilfe von Sicherheitsintegritäts-Analysen automatisch überprüft werden.

Wenn sich die folgenden Empfehlungen auf eine CIS-GKE-Benchmark-Empfehlung beziehen, wird das angegeben.

Aktualisierung der GKE-Infrastruktur zeitnah ausführen (Standardeinstellung vom 11.11.2019)

CIS-GKE-Benchmark-Empfehlung: 6.5.3. Automatische Knotenupgrades für GKE-Knoten sollten aktiviert sein

Die einfachste Methode zur Verbesserung der Sicherheit besteht darin, immer die neueste Kubernetes-Version zu verwenden. Kubernetes implementiert regelmäßig neue Sicherheits-Features und bietet geeignete Sicherheitspatches.

Weitere Informationen zu Sicherheitspatches finden Sie unter GKE-Sicherheitsbulletins.

In Google Kubernetes Engine werden die Master automatisch repariert und aktualisiert. Durch die automatische Knotenaktualisierung werden auch die Knoten automatisch auf den neuesten Stand gebracht.

Wenn Sie die automatische Aktualisierung des Knotens deaktivieren, sollten Sie nach eigenem Zeitplan monatlich aktualisieren. Für ältere Cluster wird empfohlen, die automatische Knotenaktualisierung zu aktivieren und die GKE-Sicherheitsbulletins für kritische Patches aufmerksam zu verfolgen.

Weitere Informationen finden Sie unter Knoten automatisch aktualisieren.

Netzwerkzugang zu Steuerungsebene und Knoten beschränken

CIS-GKE-Benchmark-Empfehlungen: 6.6.2. VPC-native Cluster werden bevorzugt, 6.6.3. Autorisierte Masternetzwerke sollten aktiviert sein, 6.6.4. Cluster sollten mit aktiviertem privatem Endpunkt und deaktiviertem öffentlichem Zugriff erstellt werden, und 6.6.5. Cluster sollten mit privaten Knoten erstellt werden

Sie sollten die Sichtbarkeit der Steuerungsebene und Knoten Ihres Clusters im Internet beschränken. Diese Einstellungen können nur zum Zeitpunkt der Clustererstellung festgelegt werden.

Standardmäßig haben die Steuerungsebene und Knoten des GKE-Clusters routingfähige Internetadressen, auf die von jeder IP-Adresse aus zugegriffen werden kann.

Informationen zur Steuerungsebene des GKE-Clusters finden Sie unter Private Cluster einrichten. Es gibt drei verschiedene Arten von privaten Clustern, die Schutz auf Netzwerkebene bieten:

  • Zugriff auf öffentlichen Endpunkt ist deaktiviert: Dies ist die sicherste Option, da dadurch der gesamte Internetzugriff auf Master und Knoten verhindert wird. Dieser Schutz ist zu empfehlen, wenn Sie Ihr lokales Netzwerk so konfiguriert haben, dass mit Cloud Interconnect und Cloud VPN eine Verbindung zu Google Cloud hergestellt wird. Diese Technologien verbinden Ihr Unternehmensnetzwerk effizient mit Ihrem Cloud VPC.
  • Öffentlicher Endpunktzugriff aktiviert, autorisierte Masternetzwerke aktiviert (empfohlen): Diese Option bietet eingeschränkten Zugriff auf den Master über von Ihnen definierte Quell-IP-Adressen. Diese Option ist zu empfehlen, wenn Sie keine bestehende VPN-Infrastruktur haben oder Road Warriors bzw. Zweigstellen vorhanden sind, die über das öffentliche Internet statt über das Unternehmens-VPN und Cloud Interconnect/Cloud VPN eine Verbindung herstellen.
  • Zugriff auf öffentlichen Endpunkt ist aktiviert, autorisierte Masternetzwerke sind deaktiviert: Dies ist die Standardeinstellung. Sie ermöglicht allen Internetnutzern, Netzwerkverbindungen zur Steuerungsebene herzustellen.

Zur Deaktivierung des direkten Internetzugriffs auf Knoten geben Sie beim Erstellen des Clusters die gcloud-Tooloption "--enable-private-nodes" an.

Damit wird GKE angewiesen, Knoten mit privaten RFC 1918-IP-Adressen bereitzustellen, d. h. die Knoten sind nicht direkt über das öffentliche Internet erreichbar.

Wir empfehlen für Cluster mindestens autorisierte Masternetzwerke und private Knoten zu verwenden. Damit wird sichergestellt, dass die Steuerungsebene in folgender Weise erreichbar ist:

  • Durch auf die weiße Liste gesetzte CIDRs in autorisierten Masternetzwerken
  • Über Knoten in der VPC des Clusters
  • Über interne Google-Produktionsjobs, die Ihren Master verwalten

Dies entspricht den im Folgenden aufgeführten gcloud-Flags bei der Clustererstellung:

  • --enable-ip-alias
  • --enable-private-nodes
  • --enable-master-authorized-networks

Gruppenauthentifizierung (Beta)

CIS-GKE-Benchmark-Empfehlung: 6.8.3. Kubernetes-RBAC-Nutzer mit Google Groups für GKE verwalten

Diese Einstellung kann nur beim Erstellen des Clusters aktiviert werden.

Sie sollten Ihre Nutzer mit Gruppen verwalten. Mithilfe von Gruppen können Identitäten über Ihr Identitätsverwaltungssystem und Ihre Identitätsadministratoren gesteuert werden. Für die Anpassung der Gruppenmitgliedschaft müssen Sie dann nicht mehr Ihre RBAC-Konfiguration aktualisieren, wenn jemand der Gruppe hinzugefügt oder daraus entfernt wird.

Zur Verwaltung von Nutzerberechtigungen mit Google Groups müssen Sie beim Erstellen des Clusters Google Groups for GKE aktivieren. Damit können Sie Nutzer mit gleichen Berechtigungen auf einfache Weise verwalten, während Ihre Identitätsadministratoren die Möglichkeit haben, Nutzer zentral und einheitlich zu verwalten.

Zur Aktivierung von Google Groups for GKE müssen Sie die Google-Gruppe gke-security-groups erstellen, um damit den Nutzerzugriff zu verwalten, und das gcloud-Flag --security-group bei der Erstellung des Clusters festlegen.

Möglichkeiten für Containerknoten

In den folgenden Abschnitten werden mögliche Konfiguration sicherer Knoten beschrieben.

Shielded GKE-Knoten aktivieren

CIS-GKE-Benchmark-Empfehlung: 6.5.5. Shielded GKE-Knoten sollten aktiviert sein

Shielded GKE-Knoten bieten eine starke, nachprüfbare Knotenidentität und -integrität, die die Sicherheit von GKE-Knoten erhöhen. Sie sollten für alle GKE-Cluster aktiviert werden.

Zur Aktivierung von Shielded GKE-Knoten legen Sie die gcloud-Option --enable-shielded-nodes beim Erstellen oder Aktualisieren von Clustern fest. Shielded GKE-Knoten müssen mit Secure Boot aktiviert werden. Secure Boot sollte allerdings nicht verwendet werden, wenn Sie unsignierte Kernelmodule von Drittanbietern benötigen. Zur Aktivierung von Secure Boot geben Sie beim Erstellen des Clusters das gcloud-Flag --shielded-secure-boot an.

Gehärtetes Knoten-Image mit der containerd-Laufzeit auswählen

Das Container-Optimized OS mit containerd-Image (cos_containerd) ist eine Variante des Container-Optimized OS-Images mit containerd als Haupt-Container-Laufzeit, die direkt in Kubernetes eingebunden ist.

containerd ist die zentrale Laufzeitkomponente von Docker. Sie wurde entwickelt, um Kerncontainerfunktionen für das Container Runtime Interface (CRI) von Kubernetes bereitstellen zu können. Sie ist wesentlich weniger komplex als der vollständige Docker-Daemon und bietet so nur eine reduzierte Angriffsfläche.

Zur Verwendung des cos_containerd-Images in Ihrem Cluster geben Sie beim Erstellen oder Aktualisieren des Clusters das Flag gcloud --image-type=cos_containerd an.

cos_containerd ist das bevorzugte Image für GKE, da es speziell für die Ausführung von Containern entwickelt, optimiert und gehärtet wurde.

Workload Identity aktivieren

CIS-GKE-Benchmark-Empfehlung: 6.2.2. Dedizierte Google Cloud-Dienstkonten und Workload Identity verwenden

Workload Identity ist die empfohlene Methode zur Authentifizierung bei Google APIs. Sie ersetzt die bisherigen Verfahren, bei denen Knotendienstkonten verwendet oder Dienstkontoschlüssel in Secrets exportiert werden, wie unter Mit Dienstkonten bei Google Cloud authentifizieren erläutert.

Mit Workload Identity muss auch keine Metadatenverbergung verwendet werden. Die beiden Ansätze sind nicht kompatibel. Die vertraulichen Metadaten, die durch Metadatenverbergung geschützt werden, werden durch Workload Identity ebenfalls geschützt.

Isolierung von Arbeitslasten mit GKE Sandbox härten

CIS-GKE-Benchmark-Empfehlung: 6.10.4. Ziehen Sie eventuell GKE Sandbox in Betracht, um die Isolierung von Arbeitslasten zu härten, insbesondere für nicht vertrauenswürdige Arbeitslasten.

Mithilfe einer zusätzlichen Sicherheitsebene verhindert GKE Sandbox, dass der Hostkernel auf Ihren Clusterknoten durch schädlichen Code beeinträchtigt wird.

Informationen zur Verwendung von GKE Sandbox finden Sie unter Isolierung von Arbeitslasten mit GKE Sandbox härten.

Berechtigungen

Google-Dienstkonten mit Mindestberechtigung verwenden

CIS-GKE-Benchmark-Empfehlung: 6.2.1. GKE-Cluster nicht mit dem Compute Engine-Standarddienstkonto ausführen

Jedem GKE-Knoten ist ein Cloud IAM-Dienstkonto (Cloud Identity and Access Management) zugeordnet. Standardmäßig erhalten Knoten das Compute Engine-Standarddienstkonto, das Sie über den Cloud IAM-Abschnitt der Cloud Console aufrufen können. Dieses Konto bietet standardmäßig einen breiten Zugriff und ist daher für eine Vielzahl von Anwendungen hilfreich. Ihm sind jedoch mehr Berechtigungen zugewiesen, als für die Ausführung des Kubernetes Engine-Clusters erforderlich sind. Sie sollten ein Dienstkonto mit minimalen Berechtigungen erstellen, um Ihren GKE-Cluster auszuführen, anstatt das Compute Engine-Standarddienstkonto zu verwenden.

Aufgrund der Einführung von Workload Identity empfehlen wir einen eingeschränkteren Anwendungsfall für das Knotendienstkonto. Wir gehen davon aus, dass das Knotendienstkonto von System-Daemons verwendet wird, die für Logging, Monitoring und ähnliche Aufgaben zuständig sind. Arbeitslasten in Pods sollten stattdessen die notwendigen Berechtigungen über Google-Identitäten mit Workload Identity erhalten.

Für GKE müssen dem Dienstkonto mindestens die Rollen monitoring.viewer, monitoring.metricWriter und logging.logWriter zugewiesen sein. Weitere Informationen erhalten Sie unter Monitoring-Rollen und Logging-Rollen.

Mit den folgenden Befehlen können Sie ein Cloud IAM-Dienstkonto mit den für den Betrieb von GKE mindestens erforderlichen Berechtigungen erstellen:

gcloud

gcloud iam service-accounts create sa-name \
  --display-name=sa-name

gcloud projects add-iam-policy-binding project-id \
  --member "serviceAccount:sa-name@project-id.iam.gserviceaccount.com" \
  --role roles/logging.logWriter

gcloud projects add-iam-policy-binding project-id \
  --member "serviceAccount:sa-name@project-id.iam.gserviceaccount.com" \
  --role roles/monitoring.metricWriter

gcloud projects add-iam-policy-binding project-id \
  --member "serviceAccount:sa-name@project-id.iam.gserviceaccount.com" \
  --role roles/monitoring.viewer

Config Connector

Hinweis: Für diesen Schritt ist Config Connector erforderlich. Folgen Sie der Installationsanleitung, um Config Connector in Ihrem Cluster zu installieren.

  1. Laden Sie zum Erstellen des Dienstkontos die folgende Ressource als service-account.yaml herunter. Ersetzen Sie [SA_NAME] durch den Namen, den Sie für das Dienstkonto verwenden möchten.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMServiceAccount
    metadata:
      name: [SA_NAME]
    spec:
      displayName: [SA_NAME]
    Führen Sie dann diesen Befehl aus:
    kubectl apply -f service-account.yaml

  2. Wenden Sie die Rolle logging.logWriter auf das Dienstkonto an. Laden Sie die folgende Ressource als Datei policy-logging.yaml herunter. Ersetzen Sie [SA_NAME] und [PROJECT_ID] durch Ihre eigenen Informationen.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMPolicyMember
    metadata:
      name: policy-logging
    spec:
      member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
      role: roles/logging.logWriter
      resourceRef:
        kind: Project
        name: [PROJECT_ID]
    kubectl apply -f policy-logging.yaml

  3. Wenden Sie die Rolle monitoring.metricWriter an. Laden Sie die im Folgenden aufgeführte Ressource als Datei policy-metrics-writer.yaml herunter. Ersetzen Sie [SA_NAME] und [PROJECT_ID] durch Ihre eigenen Informationen.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMPolicyMember
    metadata:
      name: policy-metrics-writer
    spec:
      member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
      role: roles/monitoring.metricWriter
      resourceRef:
        kind: Project
        name: [PROJECT_ID]
    kubectl apply -f policy-metrics-writer.yaml

  4. Wenden Sie die Rolle monitoring.viewer an. Laden Sie die im Folgenden aufgeführte Ressource als Datei policy-monitoring.yaml herunter. Ersetzen Sie [SA_NAME] und [PROJECT_ID] durch Ihre eigenen Informationen.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMPolicyMember
    metadata:
      name: policy-monitoring
    spec:
      member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
      role: roles/monitoring.viewer
      resourceRef:
        kind: Project
        name: [PROJECT_ID]
    kubectl apply -f policy-monitoring.yaml

Wenn Sie private Images in Google Container Registry verwenden, müssen Sie Zugriff darauf gewähren:

gcloud

gcloud projects add-iam-policy-binding project-id \
--member "serviceAccount:sa-name@project-id.iam.gserviceaccount.com" \
--role roles/storage.objectViewer

Config Connector

Hinweis: Für diesen Schritt ist Config Connector erforderlich. Folgen Sie der Installationsanleitung, um Config Connector in Ihrem Cluster zu installieren.

Wenden Sie die Rolle storage.objectViewer auf Ihr Dienstkonto an. Laden Sie die im Folgenden aufgeführte Ressource als Datei policy-object-viewer.yaml herunter. Ersetzen Sie [SA_NAME] und [PROJECT_ID] durch Ihre eigenen Informationen.

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-object-viewer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/storage.objectViewer
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
kubectl apply -f policy-object-viewer.yaml

Wenn ein anderer Nutzer die Möglichkeit haben soll, neue Cluster oder Knotenpools mit diesem Dienstkonto zu erstellen, müssen Sie ihm die Rolle des Dienstkontonutzers für dieses Dienstkonto zuweisen:

gcloud

gcloud iam service-accounts add-iam-policy-binding \
sa-name@project-id.iam.gserviceaccount.com \
--member=user:user \
--role=roles/iam.serviceAccountUser

Config Connector

Hinweis: Für diesen Schritt ist Config Connector erforderlich. Folgen Sie der Installationsanleitung, um Config Connector in Ihrem Cluster zu installieren.

Wenden Sie die Rolle iam,serviceAccountUser auf Ihr Dienstkonto an. Laden Sie die im Folgenden aufgeführte Ressource als Datei policy-service-account-user.yaml herunter. Ersetzen Sie [SA_NAME] und [PROJECT_ID] durch Ihre eigenen Informationen.

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-service-account-user
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/iam.serviceAccountUser
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
kubectl apply -f policy-service-account-user.yaml

Wenn Ihr Cluster bereits vorhanden ist, können Sie jetzt einen neuen Knotenpool mit diesem neuen Dienstkonto erstellen:

gcloud container node-pools create node-pool \
  --service-account=sa-name@project-id.iam.gserviceaccount.com \
  --cluster=cluster-name

Wenn Ihr GKE-Cluster Zugriff auf andere Google Cloud-Dienste benötigt, müssen Sie ein zusätzliches Dienstkonto erstellen und Ihren Arbeitslasten mit Workload Identity Zugriff auf das Dienstkonto gewähren.

RBAC-Berechtigungen für die Clustererkennung einschränken

Kubernetes stattet Cluster standardmäßig per Bootstrapping mit einem wenig eingeschränkten Satz von ClusterRoleBindings zur Erkennung aus. Diese ermöglichen einen breiten Zugriff auf Informationen zu den APIs eines Clusters, einschließlich jener von CustomResourceDefinitions.

Nutzer sollten sich der Tatsache bewusst sein, dass die Gruppe system:authenticated, die in den Subjekten der ClusterRoleBindings system:discovery und system:basic-user enthalten ist, authentifizierte Nutzer umfassen kann, einschließlich Nutzer mit einem Google-Konto, und daher für GKE-Cluster keine geeignete Sicherheitsstufe darstellt.

Zur Härtung der Erkennungs-APIs von Clustern stehen Nutzern die folgenden Aktionen zur Verfügung:

  • Konfigurieren der autorisierten Netzwerke, um den Zugriff auf festgelegte IP-Bereiche einzuschränken.
  • Einrichten eines privaten Clusters, um den Zugriff auf eine VPC einzuschränken.
  • Auswahl der Subjekte der Standard-ClusterRoleBindings system:discovery und system:basic-user. Damit kann z. B. der Zugriff auf die Gruppe system:serviceaccounts sowie auf andere bekannte Nutzer und Gruppen beschränkt werden, anstatt gemäß der Kubernetes-Standardeinstellung den Zugriff auf system:(un)authenticated zuzulassen.

Mit Namespaces und RBAC den Zugriff auf Clusterressourcen beschränken

CIS-GKE-Benchmark-Empfehlung: 5.6.1. Administrative Grenzen zwischen Ressourcen mithilfe von Namespaces erstellen

Gewähren Sie Teams Zugriff auf Kubernetes mit minimalen Berechtigungen und erstellen Sie dafür separate Namespaces oder Cluster für jedes Team und jede Umgebung. Weisen Sie jedem Namespace Kostenstellen und entsprechende Labels für Rechnungslegung und Rückbuchungen zu. Gewähren Sie Entwicklern nur Zugriff auf die Namespaces, die sie benötigen, um ihre Anwendung bereitzustellen und zu verwalten, insbesondere in der Produktion. Legen Sie die Aufgaben, die Ihre Nutzer für den Cluster ausführen müssen, fest und definieren Sie die Berechtigungen, die für die jeweilige Aufgabe erforderlich sind.

Weitere Informationen zum Erstellen von Namespaces finden Sie in der Kubernetes-Dokumentation.

Cloud IAM und die rollenbasierte Zugriffssteuerung (Role-based Access Control, RBAC) arbeiten zusammen. Jede Entität muss auf jeder Ebene ausreichende Berechtigungen haben, um mit Ressourcen im Cluster arbeiten zu können.

Weisen Sie den Gruppen und Nutzern die geeigneten Cloud IAM-Rollen für GKE zu, um Berechtigungen auf Projektebene bereitzustellen. Verwenden Sie RBAC, um Berechtigungen auf Cluster- und Namespace-Ebene zu gewähren. Weitere Informationen finden Sie unter Zugriffssteuerung.

Weitere Informationen zur Vorbereitung der Kubernetes Engine-Umgebung für die Produktion erhalten Sie unter RBAC-Autorisierung.

Traffic zwischen Pods mit einer Netzwerkrichtlinie beschränken

CIS-GKE-Benchmark-Empfehlung: 6.6.7. Netzwerkrichtlinie sollte aktiviert und entsprechend eingerichtet sein

Alle Pods in einem Cluster können standardmäßig miteinander kommunizieren. Sie sollten die Pod-zu-Pod-Kommunikation je nach Arbeitslast entsprechend steuern.

Die Beschränkung des Netzwerkzugriffs auf Dienste erschwert es Angreifern, sich innerhalb des Clusters seitlich zu bewegen. Sie bietet Diensten außerdem einen gewissen Schutz vor versehentlichen oder absichtlichen "Denial-of-Service"-Angriffen. Es gibt zwei empfohlene Methoden zur Steuerung des Traffics:

  1. Verwenden Sie Istio. Weitere Informationen finden Sie unter Istio in GKE installieren. Verwenden Sie diese Option, wenn Sie Load-Balancing, Dienstautorisierung, Drosselung, Kontingente, Messwerte und mehr verwenden möchten.
  2. Verwenden Sie Kubernetes-Netzwerkrichtlinien. Weitere Informationen finden Sie unter Cluster-Netzwerkrichtlinien festlegen. Diese Option bietet eine einfache Möglichkeit der Zugriffssteuerung von Kubernetes. Die Kubernetes-Dokumentation enthält eine hervorragende Schritt-für-Schritt-Anleitung für ein einfaches nginx-Deployment.

Istio und Netzwerkrichtlinien können bei Bedarf auch kombiniert verwendet werden.

Secret-Verwaltung

CIS-GKE-Benchmark-Empfehlung: 6.3.1. Kubernetes-Secrets mit Schlüsseln verschlüsseln, die in Cloud KMS verwaltet werden

Sie sollten einen zusätzlichen Schutz für vertrauliche Daten wie Secrets bereitstellen, die in etcd gespeichert sind. Dazu müssen Sie einen Secrets-Manager konfigurieren, der in GKE-Cluster eingebunden ist. Einige Lösungen funktionieren sowohl in GKE als auch in Anthos GKE On-Prem und sind daher möglicherweise besser geeignet, wenn Sie Arbeitslasten in mehreren Umgebungen ausführen. Wenn Sie einen externen Secrets Manager wie HashiCorp Vault verwenden möchten, sollten Sie diesen vor dem Erstellen des Clusters einrichten.

Für die Verwaltung von Secrets stehen mehrere Möglichkeiten zur Verfügung.

  • Sie können Kubernetes-Secrets nativ in GKE verwenden. Optional können Sie die Secrets auf Anwendungsebene mit einem von Ihnen verwalteten Schlüssel verschlüsseln. Dazu verwenden Sie die Verschlüsselung von Secrets auf Anwendungsebene.
  • Sie können einen Secrets-Manager wie z. B. HashiCorp Vault verwenden. Bei Ausführung im gehärteten Hochverfügbarkeitsmodus bietet dieser Manager eine einheitliche und produktionsfertige Möglichkeit zur Verwaltung von Secrets. Sie können sich entweder mit einem Kubernetes- oder Google Cloud-Dienstkonto bei HashiCorp Vault authentifizieren. Weitere Informationen zur Verwendung von GKE mit Vault finden Sie unter HashiCorp Vault ausführen und dafür eine Verbindung in Kubernetes herstellen.

GKE-VMs werden standardmäßig auf Speicherebene verschlüsselt. Dies beinhaltet etcd.

Mithilfe von Admission-Controllern Richtlinien durchsetzen

CIS-GKE-Benchmark-Empfehlung: 6.10.3. Pod-Sicherheitsrichtlinien sollten aktiviert und entsprechend eingerichtet sein

Admission-Controller sind Plug-ins, die die Art der Verwendung des Clusters steuern und erzwingen. Sie müssen aktiviert sein, damit Sie einige der erweiterten Sicherheitsfunktionen von Kubernetes verwenden können. Sie sind außerdem ein wichtiger Bestandteil des "Defense-in-Depth"-Konzepts zur Härtung des Clusters.

Standardmäßig können Pods in Kubernetes mit Funktionen arbeiten, die über ihre Anforderungen hinausgehen. Sie sollten die Funktionen eines Pods auf die für die jeweilige Arbeitslast erforderlichen Funktionen beschränken.

Kubernetes bietet Optionen, mit denen Sie Ihre Pods so einschränken können, dass sie nur mit den explizit zugewiesenen Funktionen ausgeführt werden. Mit der Pod-Sicherheitsrichtlinie lassen sich intelligente Standardeinstellungen für Pods festlegen und Einstellungen für die gesamte Umgebung erzwingen. Die von Ihnen definierten Richtlinien sollten auf die Anforderungen Ihrer Anwendung zugeschnitten sein. Die Beispielrichtlinie restricted-psp.yaml ist dafür ein guter Anhaltspunkt.

Weitere Informationen zur Pod-Sicherheitsrichtlinie finden Sie unter PodSecurityPolicies verwenden.

Wenn Sie eine NetworkPolicy nutzen und einen Pod haben, für den eine PodSecurityPolicy gilt, erstellen Sie eine RBAC Role oder ClusterRole, die zur Verwendung der PodSecurityPolicy berechtigt ist. Binden Sie dann die Role oder ClusterRole an das Dienstkonto des Pods. Es reicht in diesem Fall nicht aus, Berechtigungen für Nutzerkonten zu gewähren. Weitere Informationen finden Sie unter Richtlinien autorisieren.

Clusterkonfiguration überwachen

Es wird empfohlen, Ihre Clusterkonfigurationen auf Abweichungen von Ihren definierten Einstellungen zu prüfen.

Viele Empfehlungen, die in diesem Leitfaden zur Härtung behandelt werden, sowie andere häufige Fehlkonfigurationen können mithilfe von Sicherheitsintegritäts-Analysen automatisch überprüft werden.

Sichere Standardeinstellungen

In den folgenden Abschnitten werden Optionen erläutert, die in neuen Clustern standardmäßig sicher konfiguriert sind. Prüfen Sie, ob bereits vorhandene Cluster sicher konfiguriert sind.

Knotenmetadaten schützen (Standardeinstellung für 1.12 oder höher)

CIS-GKE-Benchmark-Empfehlungen: 6.4.1. Die Legacy-Instanzmetadaten-APIs in Compute Engine sollten deaktiviert sein, und 6.4.2. Der GKE-Metadatenserver sollte aktiviert sein

Der Instanzmetadatenserver von Compute Engine macht die Legacy-Endpunkte /0.1/ und /v1beta1/ verfügbar, die keine Metadatenabfrage-Header erzwingen. Diese APIs wurden für neue Cluster standardmäßig ab Version 1.12+ deaktiviert. Wenn Sie Cluster aus älteren Versionen aktualisiert haben, sollten Sie diese Legacy-APIs manuell deaktivieren.

Manche Angriffe auf Kubernetes in der Praxis erfordern Zugriff auf den Metadatenserver der VM, um Anmeldedaten zu extrahieren. Diese Angriffe werden blockiert, wenn Sie Workload identity oder die Metadatenverbergung verwenden.

Metadatenserver-Endpunkte von Compute Engine v1beta1 und v0.1 sind veraltet und sollen eingestellt werden. Sorgen Sie dafür, dass alle Anfragen für die Verwendung des v1-Endpunkts aktualisiert werden.

Weitere Informationen finden Sie unter Clustermetadaten schützen.

Deaktivierung der Legacy-Methoden zur Clientauthentifizierung beibehalten (Standardeinstellung für 1.12 oder höher)

CIS-GKE-Benchmark-Empfehlungen: 6.8.1. Die Basisauthentifizierung mit statischen Passwörtern sollte deaktiviert sein, und 6.8.2. Die Authentifizierung mit Clientzertifikaten sollte deaktiviert sein

Es gibt mehrere Methoden zur Authentifizierung beim Kubernetes API-Server.

Die unterstützten Methoden in GKE sind Inhabertokens für Dienstkonten, OAuth-Tokens, x509-Clientzertifikate und statische Passwörter. GKE verwaltet die Authentifizierung mit gcloud mithilfe der OAuth-Token-Methode. Dabei werden die Kubernetes-Konfiguration eingerichtet sowie ein Zugriffstoken abgerufen und auf den neuesten Stand gebracht.

Vor der Einbindung von GKE in Google OAuth waren das vorinstallierte x509-Zertifikat oder statische Passwörter die einzigen verfügbaren Authentifizierungsmethoden. Seit Version 1.12 werden sie jedoch nicht für neue Cluster empfohlen und sind standardmäßig deaktiviert.

Vorhandene Cluster sollten nach OAuth verschoben werden. Wenn ein System, das sich außerhalb des Clusters befindet, langlebige Anmeldedaten benötigt, empfehlen wir, ein Google-Dienstkonto oder ein Kubernetes-Dienstkonto mit den erforderlichen Berechtigungen zu erstellen und den Schlüssel zu exportieren.

So aktualisieren Sie einen vorhandenen Cluster und entfernen das statische Passwort:

gcloud container clusters update cluster-name \
  --no-enable-basic-auth

Derzeit ist es nicht möglich, das vorab ausgestellte Clientzertifikat aus einem vorhandenen Cluster zu entfernen. Es sind damit aber keine Berechtigungen vorhanden, wenn RBAC aktiviert und ABAC deaktiviert ist.

Aktivierung von Cloud Logging beibehalten (Standardeinstellung)

CIS-GKE-Benchmark-Empfehlung: 6.7.1. Stackdriver Kubernetes Logging und Monitoring sollten aktiviert sein

Zur Reduzierung des operativen Aufwands und zur Bereitstellung einer konsolidierten Ansicht Ihrer Logs sollten Sie eine einheitliche Logging-Strategie für alle bereitgestellten Cluster implementieren. Anthos-Cluster sind standardmäßig in Cloud Logging eingebunden und sollten so konfiguriert bleiben.

Alle GKE-Cluster bieten Kubernetes-Audit-Logging mit einer chronologischen Aufzeichnung von Aufrufen, die an den Kubernetes API-Server gesendet wurden. Dieses Feature ist standardmäßig aktiviert. Die Einträge im Kubernetes-Audit-Log bieten hilfreiche Informationen, um verdächtige API-Anfragen zu untersuchen, Statistiken zu erfassen oder Monitoring-Benachrichtigungen für unerwünschte API-Aufrufe zu erstellen.

GKE-Cluster ermöglichen die Einbindung von Kubernetes-Audit-Logging in Cloud-Audit-Logs und Cloud Logging. Logs lassen sich bei Bedarf aus Cloud Logging exportieren. Solche Exporte können in eigenen Logging-Systemen verwendet werden.

Deaktivierung der Kubernetes-Web-UI (Dashboard) beibehalten (Standardeinstellung für 1.10 oder höher)

CIS-GKE-Benchmark-Empfehlung: 6.10.1. Die Kubernetes-Web-UI sollte deaktiviert sein

Sie sollten die Kubernetes-Web-UI (Dashboard) nicht aktivieren, wenn sie in GKE ausgeführt wird.

Die Kubernetes-Web-UI (Dashboard) wird von einem Kubernetes-Dienstkonto mit hoher Priorität unterstützt. Die Cloud Console bietet weitgehend die gleiche Funktionalität, sodass Sie diese Berechtigungen nicht benötigen.

So deaktivieren Sie die Kubernetes-Web-UI:

gcloud container clusters update cluster-name \
    --update-addons=KubernetesDashboard=DISABLED

Deaktivierung der ABAC-Funktion beibehalten (Standardeinstellung für 1.10 oder höher)

CIS-GKE-Benchmark-Empfehlung: 6.8.4. Die Legacy-Autorisierung (ABAC) sollte deaktiviert sein

Sie sollten in GKE die attributbasierte Zugriffssteuerung (Attribute-Based Access Control, ABAC) deaktivieren und stattdessen die rollenbasierte (Role-Based Access Control, RBAC) verwenden.

In Kubernetes wird RBAC zum Erteilen von Berechtigungen für Ressourcen auf Cluster- und Namespace-Ebene verwendet. Mit RBAC können Sie Rollen mit Regeln definieren, die eine Reihe von Berechtigungen enthalten. RBAC bietet erhebliche Sicherheitsvorteile und ist nun in Kubernetes stabil. Daher ist es an der Zeit, ABAC zu deaktivieren.

Wenn Sie dennoch ABAC verwenden, lesen Sie zuerst die Voraussetzungen für die Verwendung von RBAC. Wenn Sie Ihren Cluster von einer älteren Version aktualisiert haben und ABAC verwenden, müssen Sie die Konfiguration der Zugriffssteuerung entsprechend aktualisieren:

gcloud container clusters update cluster-name \
    --no-enable-legacy-authorization

So erstellen Sie gemäß der obigen Empfehlung einen neuen Cluster:

gcloud container clusters create cluster-name \
    --no-enable-legacy-authorization

Weitere Informationen