Sicherheit Ihres Clusters erhöhen

Auf dieser Seite werden Sie durch die Implementierung der aktuellen Best Practices 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.

Dieses Dokument richtet sich an Sicherheitsexperten, die Richtlinien und Verfahren zum Schutz der Daten einer Organisation vor unbefugtem Zugriff definieren, verwalten und implementieren. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und ‑Aufgaben.

Machen Sie sich vor dem Lesen dieser Seite mit den folgenden Themen vertraut:

Wenn Sie neue Cluster in GKE erstellen, sind viele dieser Sicherheitsfunktionen standardmäßig aktiviert. Wenn Sie Aktualisierungen für bestehende Cluster ausführen, sollten Sie diesen Leitfaden zur Härtung regelmäßig auf neue Features prüfen und diese aktivieren.

Im Autopilot-Modus erstellte Cluster implementieren standardmäßig viele GKE-Härtungsfeatures.

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

GKE-Infrastruktur regelmäßig upgraden

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.

Die automatische Knotenaktualisierung ist standardmäßig für Cluster aktiviert, die ab Juni 2019 mit derGoogle Cloud -Konsole erstellt wurden, und für Cluster, die ab dem 11. November 2019 mit der API erstellt wurden.

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 Netzwerke 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

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

Best Practice:

Sichtbarkeit der Steuerungsebene und Knoten Ihres Clusters im Internet beschränken.

Zugriff auf die Steuerungsebene einschränken

Informationen zum Einschränken des Zugriffs auf die GKE-Cluster-Steuerungsebene finden Sie unter Zugriff auf die Steuerungsebene konfigurieren. Folgende Optionen stehen für den Schutz auf Netzwerkebene zur Verfügung:

  • DNS-basierter Endpunkt aktiviert (empfohlen): Sie können mit VPC Service Controls steuern, wer auf den DNS-basierten Endpunkt zugreifen kann. Mit VPC Service Controls können Sie einen Sicherheitsparameter für alle Google APIs in Ihrem Projekt mit kontextbezogenen Attributen wie dem Netzwerkursprung definieren. Diese Einstellungen können für ein Projekt zentral für alle Google-APIs gesteuert werden. So müssen Sie weniger Orte konfigurieren, an denen Zugriffsregeln festgelegt werden müssen.

  • Zugriff auf externe und interne IP-basierte Endpunkte deaktiviert:Dadurch wird der gesamte Zugriff auf die Steuerungsebene über IP-basierte Endpunkte verhindert.

  • Zugriff auf externe IP-basierte Endpunkte deaktiviert:Dadurch wird der gesamte Internetzugriff auf beide Steuerungsebenen verhindert. Diese Option ist zu empfehlen, wenn Sie Ihr lokales Netzwerk so konfiguriert haben, dass mit Cloud Interconnect und Cloud VPN eine Verbindung zuGoogle Cloud hergestellt wird. Diese Technologien verbinden Ihr Unternehmensnetzwerk effizient mit Ihrem Cloud VPC.

  • Zugriff auf externe IP-basierte Endpunkte aktiviert; autorisierte Netzwerke aktiviert: 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 externe Endpunkte aktiviert; autorisierte Netzwerke deaktiviert: Dies ermöglicht allen Internetnutzern, Netzwerkverbindungen zur Steuerungsebene herzustellen.

Wenn Sie IP-basierte Endpunkte verwenden, empfehlen wir, dass Cluster autorisierte Netzwerke 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
  • Von Google reservierte IP-Adressen für die Clusterverwaltung.

Zugriff auf Knoten einschränken

Best Practice:

Aktivieren Sie private Knoten in Ihren Clustern, um zu verhindern, dass externe Clients auf die Knoten zugreifen.

Zur Deaktivierung des direkten Internetzugriffs auf Knoten geben Sie beim Erstellen des Clusters die gcloud CLI-Option --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.

Anonymen Zugriff auf Clusterendpunkte einschränken

Diese Sicherheitsverbesserung trägt dazu bei, die Risiken zu verringern, die mit versehentlichen oder böswilligen Rollenbindungen verbunden sind, indem der anonyme Zugriff auf Clusterendpunkte eingeschränkt wird. Standardmäßig weist Kubernetes dem system:anonymous-Nutzer und der system:unauthenticated-Gruppe anonyme Anfragen an Clusterendpunkte zu. Wenn dieser Nutzer oder diese Gruppe über RBAC-Bindungen Berechtigungen im Cluster hat, kann dies einem anonymen Nutzer unbeabsichtigten Zugriff auf Endpunkte ermöglichen, die zur Gefährdung der Sicherheit eines Dienstes oder des Clusters selbst verwendet werden können.

Sofern sie nicht explizit durch RBAC-Bindungen eingeschränkt werden, werden anonyme Authentifizierungsanfragen für alle Clusterendpunkte akzeptiert. In GKE-Version 1.32.2-gke.1234000 und höher können Sie beim Erstellen oder Aktualisieren eines Clusters die Menge der Endpunkte, die durch anonyme Anfragen erreicht werden können, auf die drei Kubernetes API-Server-Health-Check-Endpunkte /healthz, /livez und /readyz beschränken. Der anonyme Zugriff auf diese Systemdiagnose-Endpunkte ist erforderlich, um zu prüfen, ob ein Cluster ordnungsgemäß funktioniert.

Wenn Sie den anonymen Zugriff auf Clusterendpunkte einschränken möchten, geben Sie LIMITED für das Flag --anonymous-authentication-config in einem der folgenden gcloud CLI-Befehle an:

Das Flag --anonymous-authentication-config hat entweder den Wert LIMITED oder ENABLED. Der Standardwert ist ENABLED. Wenn Sie den Wert auf LIMITED festlegen, werden anonyme Anfragen während der Authentifizierung abgelehnt, auch wenn ein solcher Zugriff durch vorhandene RBAC-Bindungen zulässig ist. Abgelehnte Anfragen geben den HTTP-Statuscode 401 zurück.

Wie im folgenden Beispiel gezeigt, können Sie eine Einschränkung für Organisationsrichtlinien verwenden, um diese Zugriffsbeschränkung für alle Cluster in Ihrer Organisation zu erzwingen:

name: organizations/ORGANIZATION_ID/customConstraints/custom.gkeAnonymousAccessLimited
    resourceTypes:
    - container.googleapis.com/Cluster
    methodTypes:
    - CREATE
    - UPDATE
    condition: "condition:resource.anonymousAuthenticationConfig.mode == "LIMITED"
    action: ALLOW
    displayName: Restrict anonymous access to cluster endpoints.
    description: All new and updated clusters must restrict anonymous access to cluster endpoints.

Ersetzen Sie ORGANIZATION_ID durch Ihre Organisations-ID, z. B. 123456789.

Verlassen Sie sich nicht allein auf diese Funktion, um Ihren Cluster zu schützen. Erwägen Sie zusätzliche Sicherheitsmaßnahmen wie die folgenden:

Informationen zur zugrunde liegenden Kubernetes-Implementierung für diese Verbesserung finden Sie unter Anonymous Authenticator Configuration. Weitere Informationen zu RBAC-Richtlinien (Role-Based Access Control, rollenbasierte Zugriffssteuerung) finden Sie unter Best Practices für GKE-RBAC.

Firewallregeln mit geringsten Berechtigungen verwenden

Minimieren Sie das Risiko eines unbeabsichtigten Zugriffs mithilfe des Prinzips der geringsten Berechtigung für Firewallregeln

GKE erstellt Standard-VPC-Firewallregeln, um Systemfunktionen zu aktivieren und gute Sicherheitspraktiken zu erzwingen. Eine vollständige Liste der automatisch erstellten Firewallregeln finden Sie unter Automatisch erstellte Firewallregeln.

GKE erstellt diese Standard-Firewallregeln mit der Priorität 1.000. Wenn Sie freie Firewallregeln mit einer höheren Priorität erstellen, z. B. eine allow-all-Firewallregel für das Debugging, besteht das Risiko eines unbeabsichtigten Clusters.

Gruppenauthentifizierung verwenden

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

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 Google Groups for RBAC in Ihrem Cluster 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.

Sicherheit für Containerknoten konfigurieren

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.

Identitätsföderation von Arbeitslasten für GKE aktivieren

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

Workload Identity Federation for GKE ist die empfohlene Methode zur Authentifizierung bei Google Cloud APIs.

Workload Identity Federation for GKE macht die Verwendung der Metadatenverbergung überflüssig. Daher sind diese beiden Ansätze nicht kompatibel. Die vertraulichen Metadaten, die durch Metadatenverbergung geschützt werden, werden durch Workload Identity Federation for GKE 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.

Sie können Container in einer Sandbox-Umgebung ausführen, um die meisten Container-Escape-Angriffe, auch lokale Privilegienerweiterungsangriffe genannt, zu minimieren. Sicherheitslücken bei Containern in der Vergangenheit finden Sie in den Sicherheitsbulletins. Diese Art von Angriff ermöglicht einem Angreifer Zugriff auf die Host-VM des Containers und somit auf andere Container auf derselben VM. Eine Sandbox wie GKE Sandbox kann die Auswirkungen dieser Angriffe begrenzen.

In Situationen wie diesen sollten Sie das Ausführen von Arbeitslasten in einer Sandbox in Betracht ziehen:

  • Die Arbeitslast führt nicht vertrauenswürdigen Code aus.
  • Sie möchten die Auswirkungen begrenzen, wenn ein Angreifer einen Container in der Arbeitslast manipuliert.

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

Sicherheitsbulletin-Benachrichtigungen aktivieren

Wenn Sicherheitsbulletins verfügbar sind, die für Ihren Cluster relevant sind, veröffentlicht GKE Benachrichtigungen zu diesen Ereignissen als Nachrichten in Pub/Sub-Themen, die Sie konfigurieren. Sie können diese Benachrichtigungen für ein Pub/Sub-Abo erhalten, den Dienst von Drittanbietern einbinden und nach den Benachrichtigungstypen filtern, die Sie erhalten möchten.

Weitere Informationen zum Empfangen von Sicherheitsbulletins mit GKE-Cluster-Benachrichtigungen finden Sie unter Cluster-Benachrichtigungen.

Unsicheren schreibgeschützten Port für kubelet deaktivieren

Deaktivieren Sie den schreibgeschützten Port von Kubelet und wechseln Sie alle Arbeitslasten, die Port 10255 verwenden, um stattdessen den sichereren Port 10250 zu verwenden.

Der auf Knoten ausgeführte kubelet-Prozess stellt eine schreibgeschützte API mit dem unsicheren Port 10255 bereit. Kubernetes führt an diesem Port keine Authentifizierungs- oder Autorisierungsprüfungen durch. Kubelet stellt dieselben Endpunkte auf dem sichereren, authentifizierten Port 10250 bereit.

Eine Anleitung finden Sie unter Schreibgeschützten Port für Kubelet in GKE-Clustern deaktivieren.

Zugriffsberechtigungen erteilen

In den folgenden Abschnitten wird beschrieben, wie Sie Zugriff auf Ihre GKE-Infrastruktur gewähren.

IAM-Dienstkonten mit Mindestberechtigungen verwenden

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

GKE verwendet IAM-Dienstkonten, die an Ihre Knoten angehängt sind, um Systemaufgaben wie Logging und Monitoring auszuführen. Diese Knoten-Dienstkonten müssen in Ihrem Projekt mindestens die Rolle Kubernetes Engine Default Node Service Account (roles/container.defaultNodeServiceAccount) haben. Standardmäßig verwendet GKE das Compute Engine-Standarddienstkonto, das automatisch in Ihrem Projekt erstellt wird, als Knotendienstkonto.

Wenn Sie das Compute Engine-Standarddienstkonto für andere Funktionen in Ihrem Projekt oder Ihrer Organisation verwenden, hat das Dienstkonto möglicherweise mehr Berechtigungen als für GKE erforderlich. Dies kann zu Sicherheitsrisiken führen.

Das Dienstkonto, das an Ihre Knoten angehängt ist, sollte nur von Systemarbeitslasten verwendet werden, die Aufgaben wie Logging und Monitoring ausführen. Für Ihre eigenen Arbeitslasten stellen Sie Identitäten mit der Identitätsföderation von Arbeitslasten für GKE bereit.

So erstellen Sie ein benutzerdefiniertes Dienstkonto und weisen ihm die erforderliche Rolle für GKE zu:

Console

  1. Aktivieren Sie die Cloud Resource Manager API:

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the API

  2. Rufen Sie die Seite Dienstkonten auf:

    Zur Seite „Dienstkonten“

  3. Klicken Sie auf Dienstkonto erstellen.
  4. Geben Sie einen Namen für das Dienstkonto ein. Im Feld Dienstkonto-ID wird automatisch eine eindeutige ID für das Dienstkonto auf Grundlage des Namens generiert.
  5. Klicken Sie auf Erstellen und fortfahren.
  6. Wählen Sie im Menü Rolle auswählen die Rolle Kubernetes Engine Default Node Service Account aus.
  7. Klicken Sie auf Fertig.

gcloud

  1. Aktivieren Sie die Cloud Resource Manager API: 
    gcloud services enable cloudresourcemanager.googleapis.com
  2. Erstellen Sie das Dienstkonto: 
    gcloud iam service-accounts create SA_NAME

    Ersetzen SieSA_NAME durch einen eindeutigen Namen, der das Dienstkonto identifiziert.

  3. Weisen Sie dem Dienstkonto die Rolle Kubernetes Engine Default Node Service Account (roles/container.defaultNodeServiceAccount) zu: 
    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
    --role=roles/container.defaultNodeServiceAccount

    Ersetzen Sie Folgendes:

    • PROJECT_ID: Projekt-ID in Google Cloud .
    • SA_NAME: Name des von Ihnen erstellten Dienstkontos.

Terraform

Erstellen Sie ein IAM-Dienstkonto und weisen Sie ihm die Rolle roles/container.defaultNodeServiceAccount für das Projekt zu:

resource "google_service_account" "default" {
  account_id   = "gke-node-service-account"
  display_name = "GKE node service account"
}

data "google_project" "project" {
}

resource "google_project_iam_member" "default" {
  project = data.google_project.project.project_id
  role    = "roles/container.defaultNodeServiceAccount"
  member  = "serviceAccount:${google_service_account.default.email}"
}

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: 
    apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMServiceAccount
metadata:
  name: [SA_NAME]
spec:
  displayName: [DISPLAY_NAME]

    Ersetzen Sie Folgendes:

    • [SA_NAME] ist der Name des neuen Dienstkontos.
    • [DISPLAY_NAME]: Ein Anzeigename für das Dienstkonto.
  2. Erstellen Sie das Dienstkonto: 
    kubectl apply -f service-account.yaml
  3. Wenden Sie die Rolle roles/logging.logWriter auf das Dienstkonto an:
    1. Laden Sie die folgende Ressource als Datei policy-logging.yaml herunter. 
      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]

      Ersetzen Sie Folgendes:

      • [SA_NAME] ist der Name des Dienstkontos.
      • [PROJECT_ID]: Projekt-ID in Google Cloud .
    2. Wenden Sie die Rolle auf das Dienstkonto an: 
      kubectl apply -f policy-logging.yaml
  4. Wenden Sie die Rolle roles/monitoring.metricWriter auf das Dienstkonto an:
    1. Laden Sie die folgende 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]

      Ersetzen Sie Folgendes:

      • [SA_NAME] ist der Name des Dienstkontos.
      • [PROJECT_ID]: Projekt-ID in Google Cloud .
    2. Wenden Sie die Rolle auf das Dienstkonto an: 
      kubectl apply -f policy-metrics-writer.yaml
  5. Wenden Sie die Rolle roles/monitoring.viewer auf das Dienstkonto an:
    1. Laden Sie die folgende Ressource als Datei policy-monitoring.yaml herunter. 
      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]

      Ersetzen Sie Folgendes:

      • [SA_NAME] ist der Name des Dienstkontos.
      • [PROJECT_ID]: Projekt-ID in Google Cloud .
    2. Wenden Sie die Rolle auf das Dienstkonto an: 
      kubectl apply -f policy-monitoring.yaml
  6. Wenden Sie die Rolle roles/autoscaling.metricsWriter auf das Dienstkonto an:
    1. Laden Sie die folgende Ressource als Datei policy-autoscaling-metrics-writer.yaml herunter. 
      apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-autoscaling-metrics-writer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/autoscaling.metricsWriter
  resourceRef:
    kind: Project
    name: [PROJECT_ID]

      Ersetzen Sie Folgendes:

      • [SA_NAME] ist der Name des Dienstkontos.
      • [PROJECT_ID]: Projekt-ID in Google Cloud .
    2. Wenden Sie die Rolle auf das Dienstkonto an: 
      kubectl apply -f policy-autoscaling-metrics-writer.yaml

Sie können dieses Dienstkonto auch für Ressourcen in anderen Projekten verwenden. Eine Anleitung finden Sie unter Identitätswechsel für Dienstkonten über Projekte hinweg aktivieren.

Zugriff auf private Image-Repositories gewähren

Wenn Sie private Images in Artifact Registry verwenden möchten, weisen Sie dem Dienstkonto die Rolle „Artifact Registry-Leser“ (roles/artifactregistry.reader) zu.

gcloud

gcloud artifacts repositories add-iam-policy-binding REPOSITORY_NAME \
    --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/artifactregistry.reader

Ersetzen Sie dabei REPOSITORY_NAME durch den Namen Ihres Artifact Registry-Repositorys.

Config Connector

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

  1. Speichern Sie das folgende Manifest als policy-artifact-registry-reader.yaml:

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-artifact-registry-reader
spec:
  member: serviceAccount:"SA_NAME"@"PROJECT_ID".iam.gserviceaccount.com
  role: roles/artifactregistry.reader
  resourceRef:
    apiVersion: artifactregistry.cnrm.cloud.google.com/v1beta1
    kind: ArtifactRegistryRepository
    name: "REPOSITORY_NAME"

    Ersetzen Sie Folgendes:

    • SA_NAME: Der Name Ihres IAM-Dienstkontos.
    • PROJECT_ID: Projekt-ID in Google Cloud .
    • REPOSITORY_NAME: der Name Ihres Artifact Registry-Repositorys

  2. Weisen Sie dem Dienstkonto die Rolle „Artifact Registry-Leser” zu:

    kubectl apply -f policy-artifact-registry-reader.yaml

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

gcloud

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
  --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/storage.objectViewer

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

Ersetzen Sie Folgendes:

  • PROJECT_ID: Ihre Google Cloud Projekt-ID in der 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 gcloud storage buckets add-iam-policy-binding.

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

Für vorhandene Standard-Cluster können Sie jetzt einen neuen Knotenpool mit diesem neuen Dienstkonto erstellen. Für Autopilot-Cluster müssen Sie einen neuen Cluster mit dem Dienstkonto erstellen. Eine Anleitung finden Sie unter Autopilot-Cluster erstellen.

  • Erstellen Sie einen Knotenpool, der das neue Dienstkonto verwendet:

    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, sollten Sie die Workload Identity Federation for GKE verwenden.

Zugriff auf die Discovery APIs des Clusters einschrä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. Weitere Informationen finden Sie unter Standardrollen und -gruppen vermeiden.

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

  • Aktivieren Sie den DNS-basierten Endpunkt nur für den Zugriff auf die Steuerungsebene.
  • Konfigurieren Sie autorisierte Netzwerke, um den Zugriff auf festgelegte IP-Bereiche einzuschränken.
  • Beschränken Sie den Zugriff auf die Steuerungsebene und aktivieren Sie private Knoten.

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. Best Practices für die Planung Ihrer RBAC-Konfiguration finden Sie unter Best Practices für GKE-RBAC.

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.

Sie können IAM- und RBAC-Berechtigungen zusammen mit Namespaces verwenden, um Nutzerinteraktionen mit Clusterressourcen in der Google Cloud Console einzuschränken. Weitere Informationen finden Sie unter Zugriff gewähren und Clusterressourcen nach Namespace aufrufen.

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 GKE Enterprise 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.

Daten mit der Verwaltung von vertraulichen Informationen schützen

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

Verwenden Sie ein externes Tool zur Verwaltung von vertraulichen Daten, um vertrauliche Daten außerhalb Ihres Clusters zu speichern und programmatisch darauf zuzugreifen.

In Kubernetes können Sie vertrauliche Daten in Secret-Objekten in Ihrem Cluster speichern. Mit Secrets können Sie Anwendungen vertrauliche Daten zur Verfügung stellen, ohne diese Daten in den Anwendungscode aufzunehmen. Das Speichern dieser Daten in Ihrem Cluster birgt jedoch Risiken wie die folgenden:

  • Jeder, der Pods in einem Namespace erstellen kann, kann die Daten eines beliebigen Secrets in diesem Namespace lesen.
  • Jeder mit RBAC- oder IAM-Zugriff zum Lesen aller Kubernetes API-Objekte kann Secrets lesen.

Verwenden Sie nach Möglichkeit einen externen Dienst zur Verwaltung von vertraulichen Daten wie Secret Manager, um Ihre vertraulichen Daten außerhalb Ihres Clusters zu speichern. Erstellen Sie Secrets in Ihrem Cluster nur, wenn Sie diese Daten nicht auf andere Weise für Ihre Arbeitslasten bereitstellen können. Wir empfehlen die folgenden Methoden, um auf Ihre Secrets zuzugreifen (in der Reihenfolge der Präferenz):

  • Secret Manager-Clientbibliotheken: Sie können programmatisch über Ihren Anwendungscode auf Secrets zugreifen, indem Sie die Secret Manager API mit der Identitätsföderation von Arbeitslasten für GKE verwenden. Weitere Informationen finden Sie unter Mit Clientbibliotheken auf Secrets zugreifen, die außerhalb von GKE-Clustern gespeichert sind.
  • Secret Manager-Daten als eingebundene Volumes: Sie können sensible Daten für Ihre Pods als eingebundene Volumes bereitstellen, indem Sie das Secret Manager-Add-on für GKE verwenden. Diese Methode ist nützlich, wenn Sie Ihren Anwendungscode nicht ändern können, um die Secret Manager-Clientbibliotheken zu verwenden. Weitere Informationen finden Sie unter Secret Manager-Add-on mit Google Kubernetes Engine verwenden.

  • Drittanbietertools zur Secret-Verwaltung: Drittanbietertools wie HashiCorp Vault bieten Funktionen zur Secret-Verwaltung für Kubernetes-Arbeitslasten. Diese Tools erfordern mehr anfängliche Konfiguration als Secret Manager, sind aber eine sicherere Option als das Erstellen von Secrets im Cluster. Informationen zum Konfigurieren eines Drittanbieter-Tools für die Secret-Verwaltung finden Sie in der Dokumentation des Anbieters. Beachten Sie außerdem die folgenden Empfehlungen:

    • Wenn das Drittanbietertool in einem Cluster ausgeführt wird, verwenden Sie einen anderen Cluster als den, in dem Ihre Arbeitslasten ausgeführt werden.
    • Verwenden Sie Cloud Storage oder Spanner zum Speichern der Daten des Tools.
    • Verwenden Sie einen internen Passthrough-Network Load Balancer, um das Drittanbieter-Tool zur Verwaltung von Secrets für Pods verfügbar zu machen, die in Ihrem VPC-Netzwerk ausgeführt werden.

  • Kubernetes-Secrets verwenden (nicht empfohlen): Wenn keine der vorherigen Optionen für Ihren Anwendungsfall geeignet ist, können Sie die Daten als Kubernetes-Secrets speichern. Google Cloud verschlüsselt Daten auf der Speicherebene standardmäßig. Diese standardmäßige Verschlüsselung der Speicherebene umfasst die Datenbank, in der der Status Ihres Clusters gespeichert wird. Diese basiert entweder auf etcd oder Spanner. Außerdem können Sie diese Secrets auf Anwendungsebene mit einem von Ihnen verwalteten Schlüssel verschlüsseln. Weitere Informationen finden Sie unter Secrets auf Anwendungsebene verschlüsseln.

Mithilfe von Zugangs-Controllern Richtlinien durchsetzen

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. Beispielsweise ist Policy Controller für Cluster in Flotten verfügbar. Kubernetes verfügt auch über den integrierten PodSecurity-Admission-Controller, mit dem Sie die Pod-Sicherheitsstandards in einzelnen Clustern erzwingen können.

Policy Controller ist ein Feature von GKE Enterprise, mit dem Sie die Sicherheit in GKE-Clustern mithilfe von deklarativen Richtlinien erzwingen und validieren können. Informationen zum Erzwingen deklarativer Steuerungen auf Ihrem GKE-Cluster mit Policy Controller finden Sie unter Policy Controller installieren.

Mit dem PodSecurity-Admission-Controller können Sie vordefinierte Richtlinien in bestimmten Namespaces oder im gesamten Cluster erzwingen. Diese Richtlinien entsprechen den verschiedenen Pod-Sicherheitsstandards.

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 Gatekeeper- oder Policy Controller-Einschränkungen anwenden, 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 bereitstellen, müssen Sie die folgenden Parameter in der Constraint festlegen:

parameters:
  allowedGroups:
  - system:masters
  allowedUsers:
  - system:addon-manager

Verwendung des eingestellten Volume-Typs gcePersistentDisk einschränken

Mit dem verworfenen gcePersistentDisk-Volume-Typ können Sie einen nichtflüchtigen Compute Engine-Speicher auf Pods bereitstellen. Wir empfehlen, die Verwendung des Volumetyp gcePersistentDisk in Ihren Arbeitslasten einzuschränken. GKE führt beim Einbinden dieses Volumetyp keine IAM-Autorisierungsprüfungen für den Pod durch. Google Cloud führt jedoch Autorisierungsprüfungen durch, wenn die Festplatte an die zugrunde liegende VM angehängt wird. Ein Angreifer, der bereits Pods in einem Namespace erstellen kann, könnte daher auf den Inhalt des nichtflüchtigen Speichers von Compute Engine in Ihrem Google Cloud -Projekt zugreifen.

Verwenden Sie stattdessen PersistentVolumes und PersistentVolumeClaims, um auf nichtflüchtige Compute Engine-Speicher zuzugreifen und sie zu verwenden. Wenden Sie Sicherheitsrichtlinien in Ihrem Cluster an, um die Verwendung des Volume-Typs gcePersistentDisk zu verhindern.

Um die Nutzung des Volume-Typs gcePersistentDisk zu verhindern, wenden Sie die Referenz oder die Richtlinie "Eingeschränkt" mit dem PodSecurity-Admission-Controller an. Sie können auch eine benutzerdefinierte Einschränkung im Richtlinien-Controller oder im Gatekeeper-Admission-Controller definieren.

So definieren Sie eine benutzerdefinierte Einschränkung, um diesen Volume-Typ einzuschränken:

  1. Installieren Sie einen richtlinienbasierten Zulassungs-Controller, z. B. Policy Controller oder Gatekeeper OPA.

    Policy Controller

    Policy Controller in Ihrem Cluster installieren

    Policy Controller basiert auf Open-Source-Gatekeeper. Sie erhalten jedoch auch Zugriff auf die vollständige Einschränkungsvorlagenbibliothek, Richtlinien-Bundles und die Einbindung in Google Cloud -Konsolen-Dashboards, um Ihre Cluster zu beobachten und zu verwalten. Richtlinien-Bundles sind Best Practices, die Sie auf Ihre Cluster anwenden können. Dazu gehören Bundles, die auf Empfehlungen wie der CIS-Kubernetes-Benchmark basieren.

    Gatekeeper

    Gatekeeper in Ihrem Cluster installieren

    Öffnen Sie für Autopilot-Cluster das Gatekeeper-Manifest gatekeeper.yaml in einem Texteditor. Ändern Sie das rules-Feld in der MutatingWebhookConfiguration-Spezifikation, um Platzhalterzeichen (*) durch bestimmte API-Gruppen- und Ressourcennamen zu ersetzen, wie im folgenden Beispiel:

    apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
...
webhooks:
- admissionReviewVersions:
  - v1
  - v1beta1
  ...
  rules:
  - apiGroups:
    - core
    - batch
    - apps
    apiVersions:
    - '*'
    operations:
    - CREATE
    - UPDATE
    resources:
    - Pod
    - Deployment
    - Job
    - Volume
    - Container
    - StatefulSet
    - StorageClass
    - Secret
    - ConfigMap
  sideEffects: None
  timeoutSeconds: 1

    Wenden Sie das aktualisierte gatekeeper.yaml-Manifest auf Ihren Autopilot-Cluster an, um Gatekeeper zu installieren. Dies ist erforderlich, da Autopilot als integrierte Sicherheitsmaßnahme keine Platzhalterzeichen in Mutating Admission Webhooks zulässt.

  2. Stellen Sie die integrierte Einschränkungsvorlage für Pod-Sicherheitsrichtlinien-Volumentypen bereit:

    kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper-library/master/library/pod-security-policy/volumes/template.yaml

  3. Speichern Sie folgende Einschränkung mit einer Liste der zulässigen Volume-Typen als constraint.yaml:

    apiVersion: constraints.gatekeeper.sh/v1beta1
kind: k8sPSPVolumeTypes
metadata:
  name: nogcepersistentdisk
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pods"]
  parameters:
    volumes: ["configMap", "csi", "projected", "secret", "downwardAPI", "persistentVolumeClaim", "emptyDir", "nfs", "hostPath"]

    Diese Einschränkung beschränkt Volumes auf die Liste im spec.parameters.volumes-Feld.

  4. Stellen Sie die Einschränkung bereit:

    kubectl apply -f constraint.yaml

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.

Standardmäßig sichere Optionen prüfen

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

Die Compute Engine-Metadatenserver-Endpunkte v0.1 und v1beta1 wurden verworfen und am 30. September 2020 eingestellt. Diese Endpunkte haben keine Metadatenabfrage-Header erzwungen. Informationen zum Zeitplan für die Einstellung finden Sie unter Einstellung der Metadatenserver-Endpunkte v0.1 und v1beta1.

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 Federation for GKE oder Metadatenverbergung verwenden.

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. GKE Enterprise-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 Google 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 einen neuen Cluster mit der obigen Empfehlung:

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

Aktivierung des DenyServiceExternalIPs-Admission-Controller übernehmen

Deaktivieren Sie den DenyServiceExternalIPs-Admission-Controller nicht.

Der DenyServiceExternalIPs-Admission-Controller blockiert die Verwendung externer IP-Adressen durch Dienste und entschärft eine bekannte Sicherheitslücke.

Der DenyServiceExternalIPs-Admission-Controller ist standardmäßig für neue Cluster aktiviert, die mit den GKE-Versionen 1.21 und höher erstellt wurden. Bei Clustern, auf die GKE-Versionen 1.21 und höher aktualisiert werden, können Sie den Admission-Controller mit folgendem Befehl aktivieren:

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --no-enable-service-externalips

Nächste Schritte