Cluster härten

Durch die kontinuierliche Weiterentwicklung von Kubernetes stehen häufig neue Sicherheitsfeatures zur Verfügung. Auf dieser Seite werden Sie durch die Implementierung unserer aktuellen Anleitung zum Härten Ihres GKE-Clusters (Google Kubernetes Engine) 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 Überblick über die Sicherheit.

Viele dieser Empfehlungen sowie andere häufige Fehlkonfigurationen können mithilfe von Sicherheitsintegritätsanalysen automatisch geprü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 Sicherheitsfeatures 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 im Cluster 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 erstellen. 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 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 Ihrer Cloud-VPC.
  • Zugriff auf öffentliche Endpunkte aktiviert, autorisierte Masternetzwerke aktiviert (empfohlen): Bei dieser Option erhält die Steuerungsebene eine öffentliche IP-Adresse. Es wird aber davor eine vom Kunden konfigurierbare Firewall installiert, mit der sich festlegen lässt, welche IP-Adressen mit der Steuerungsebene kommunizieren können. 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 öffentliche Endpunkte aktiviert, autorisierte Masternetzwerke 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 for 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-Containerlaufzeit, 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 gcloud-Flag --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 (Beta)

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 der Verwendung von Knotendienstkonten oder des Exports von Dienstkontoschlüsseln in Secrets 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 durch Metadatenverbergung geschützten vertraulichen Metadaten werden auch durch Workload Identity geschützt.

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 Bereich "IAM" 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, statt 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. Hier erfahren Sie mehr über 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-logging.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 auch 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 monitoring.viewer 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, statt 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 die verschiedenen Teams und Umgebungen. 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 fest, die Ihre Nutzer für den Cluster ausführen müssen, 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 finden Sie unter Kubernetes Engine-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. 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 erstellen. Diese Option bietet eine einfache Möglichkeit der Zugriffssteuerung mithilfe 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 sensible 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, das lokal bereitgestellt wird, 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 HashiCorp Vault verwenden. Bei Ausführung im gehärteten Hochverfügbarkeitsmodus bietet dieser Manager eine einheitliche und produktionsfertige Möglichkeit zum Verwalten 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 Verbindung dazu in Kubernetes herstellen.

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

Mithilfe von Zugangs-Controllern Richtlinien durchsetzen

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

Zugangs-Controller sind Plug-ins, die die Art der Verwendung des Clusters steuern und erzwingen. Sie müssen aktiviert sein, damit Sie einige der erweiterten Sicherheitsfeatures 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 Ausgangspunkt.

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

Wenn Sie eine NetworkPolicy verwenden 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ätsanalysen automatisch geprüft werden.

Sichere Standardeinstellungen

In den folgenden Abschnitten werden Optionen erläutert, die in neuen Clustern standardmäßig sicher konfiguriert sind. Überprü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. Legacy-Instanzmetadaten-APIs in Compute Engine sollten deaktiviert sein und 6.4.2. 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 wurden verworfen 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. Basisauthentifizierung mit statischen Passwörtern sollte deaktiviert sein und 6.8.2. 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. Ab 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.

Logging für Google Cloud-Vorgangs-Suite aktiviert lassen (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 die Google Cloud-Vorgangs-Suite integriert und sollten 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 integrieren Kubernetes-Audit-Logging mit Cloud-Audit-Logs und das Logging der Google Cloud-Vorgangs-Suite. Logs lassen sich bei Bedarf aus Stackdriver 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. 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. 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 einen neuen Cluster mit der obigen Empfehlung:

    gcloud container clusters create [CLUSTER_NAME] \
        --no-enable-legacy-authorization
    

Weitere Informationen