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.

Upgrades der GKE-Infrastruktur zeitnah ausführen

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 führt häufig neue Sicherheitsfunktionen ein und bietet Sicherheitspatches.

Weitere Informationen zu Sicherheitspatches finden Sie unter GKE-Sicherheitsbulletins.

In Google Kubernetes Engine werden die Steuerungsebenen 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 öffentliche Endpunkte deaktiviert: Dies ist die sicherste Option, da dadurch der gesamte Internetzugriff auf Steuerungsebenen 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.
  • Zugriff auf öffentliche Endpunkte aktiviert; autorisierte Netzwerke aktiviert (empfohlen): Diese Option bietet eingeschränkten Zugriff auf die Steuerungsebene ü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 sowie Cloud Interconnect oder Cloud VPN eine Verbindung herstellen.
  • Zugriff auf öffentliche Endpunkte aktiviert; autorisierte Netzwerke 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 internen IP-Adressen bereitzustellen, d. h., die Knoten sind nicht direkt über das öffentliche Internet erreichbar.

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

  • Über die zulässigen CIDRs in autorisierten Netzwerken
  • Über Knoten in der VPC des Clusters
  • Über interne Google-Produktionsjobs, die Ihre Steuerungsebene verwalten

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

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

Gruppenauthentifizierung

CIS-GKE-Benchmark-Empfehlung: 6.8.3. Kubernetes-RBAC-Nutzer mit Google Groups für RBAC 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 RBAC 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.

Eine Anleitung zum Aktivieren von Google Groups for RBAC finden Sie unter Google Groups für RBAC.

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.

Sie können Shielded GKE-Knoten beim Erstellen oder Aktualisieren von Clustern aktivieren. 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. Eine Anleitung zum Aktivieren von Shielded GKE-Knoten und zum Aktivieren des sicheren Starts mit Shielded GKE-Knoten finden Sie unter Shielded GKE-Knoten verwenden.

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

Informationen zur Verwendung des Images cos_containerd in Ihrem Cluster finden Sie unter Container-Images.

Das cos_containerd-Image ist das bevorzugte Image für GKE, da es speziell für die Ausführung von Containern erstellt, 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 IAM-Dienstkonto (Identity and Access Management) zugeordnet. Standardmäßig wird Knoten das Compute Engine-Standarddienstkonto zugewiesen. Sie finden das Konto im IAM-Bereich der Cloud Console. Dieses Konto hat standardmäßig einen weiten Zugriff und ist daher für eine Vielzahl von Anwendungen nützlich. 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, logging.logWriter und stackdriver.resourceMetadata.writer zugewiesen sein. Hier erfahren Sie mehr über Monitoring-Rollen und Logging-Rollen.

Anhand der folgenden Befehle wird ein IAM-Dienstkonto mit den zum Ausführen von GKE erforderlichen Mindestberechtigungen erstellt:

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

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
  --role roles/stackdriver.resourceMetadata.writer

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 Container Registry verwenden, müssen Sie auch Zugriff darauf gewähren:

gsutil

gsutil iam ch \
  serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com:objectViewer \
  gs://BUCKET_NAME

Der Bucket, in dem Ihre Images gespeichert sind, hat den Namen BUCKET_NAME im Format:

  • artifacts.PROJECT_ID.appspot.com für Images, die in eine Registry im Host gcr.io hochgeladen werden, oder
  • STORAGE_REGION.artifacts.PROJECT_ID.appspot.com

Dabei gilt:

  • PROJECT_ID ist Ihre Projekt-ID der Google Cloud Console.
  • STORAGE_REGION ist der Speicherort des Storage-Buckets:
    • us für Registrys im Host us.gcr.io
    • eu für Registrys im Host eu.gcr.io
    • asia für Registrys im Host asia.gcr.io

Weitere Informationen zum Befehl finden Sie in der Dokumentation zu gsutil iam.

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 folgende 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_NAME \
  --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.

Zugriff auf die Cluster-API-Erkennung beschränken

Kubernetes stattet Cluster standardmäßig per Bootstrapping mit einem wenig restriktiven Satz von ClusterRoleBindings zur Erkennung aus, die einen breiten Zugriff auf Informationen zu den APIs eines Clusters ermöglichen, 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:

Wenn keine dieser Optionen für Ihren GKE-Anwendungsfall geeignet ist, sollten Sie alle API-Erkennungsinformationen, d. h. das Schema von CustomResources, APIService-Definitionen und Erkennungsinformationen, die von Erweiterungs-API-Servern gehostet werden, als öffentlich behandeln.

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.

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 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 finden Sie unter GKE-Umgebung für die Produktion vorbereiten.

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. Lesen Sie Istio in Google Kubernetes Engine installieren, wenn Sie Load-Balancing, Dienstautorisierung, Drosselung, Kontingente, Messwerte und mehr verwenden möchten.
  2. Verwenden Sie Kubernetes-Netzwerkrichtlinien. Siehe Cluster-Netzwerkrichtlinie erstellen. Diese Option bietet eine einfache Möglichkeit der Zugriffssteuerung mit Kubernetes. Wenn Sie gängige Ansätze zum Einschränken des Traffics mithilfe von Netzwerkrichtlinien implementieren möchten, lesen Sie den Implementierungsleitfaden der Anthos-Sicherheits-Blueprints. Die Kubernetes-Dokumentation enthält auch eine hervorragende Schritt-für-Schritt-Anleitung für ein einfaches nginx-Deployment. Prüfen Sie mit Logging von Netzwerkrichtlinien, ob Ihre Netzwerkrichtlinien erwartungsgemäß funktionieren.

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-Cluster auf VMware 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 unterstützt zahlreiche Steuerelemente, mit denen Sie Ihre Pods so einschränken können, dass sie nur mit den explizit zugewiesenen Funktionen ausgeführt werden. Die beiden gängigsten Steuerelemente sind Gatekeeper und Pod-Sicherheitsrichtlinien.

Gatekeeper bietet Ihnen die effektive Möglichkeit, die Sicherheit auf GKE-Clustern mithilfe deklarativer Richtlinien zu erzwingen und zu validieren. Informationen zum Verwenden deklarativer Steuerungen auf Ihrem GKE-Cluster finden Sie unter Pod-Sicherheitsrichtlinien mit Gatekeeper anwenden.

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

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.

Weitere Informationen finden Sie unter Clustermetadaten schützen.

Legacy-Authentifizierungsmethoden für Legacy-Clients aktiviert lassen

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 und x509-Clientzertifikate. GKE verwaltet die Authentifizierung mit gcloud mithilfe der OAuth-Token-Methode. Dabei wird die Kubernetes-Konfiguration eingerichtet sowie ein Zugriffstoken abgerufen und auf den neuesten Stand gebracht.

Vor der Einbindung von GKE in OAuth waren einmalig erstellte x509-Zertifikate oder statische Passwörter die einzigen verfügbaren Authentifizierungsmethoden. Diese sind jedoch nicht mehr empfehlenswert und sollten deaktiviert werden. Diese Methoden bieten eine größere Angriffsfläche zur Manipulation von Clustern und sind seit GKE-Version 1.12 standardmäßig deaktiviert. Wenn Sie Legacy-Authentifizierungsmethoden verwenden, empfehlen wir, sie zu deaktivieren. Die Authentifizierung mit einem statischen Passwort ist veraltet und wurde seit der GKE-Version 1.19 entfernt.

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.

Informationen zum Aktualisieren eines vorhandenen Clusters und zum Entfernen des statischen Passworts finden Sie unter Authentifizierung mit einem statischen Passwort deaktivieren.

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.

Cloud Logging aktiviert lassen

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 sind nützlich, um verdächtige API-Anfragen zu untersuchen, Statistiken zu erfassen oder Monitoringbenachrichtigungen 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 können von Cloud Logging an Ihre eigenen Logging-Systeme weitergeleitet werden.

Kubernetes-Web-UI (Dashboard) deaktiviert lassen

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

ABAC deaktiviert lassen

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.

Standardmäßig ist ABAC für Cluster deaktiviert, die mit GKE ab Version 1.8 erstellt wurden. 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 gegenüber ABAC.

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

Nächste Schritte