In diesem Dokument wird beschrieben, wie Sie die Sicherheit Ihrer GKE on Bare Metal-Cluster erhöhen.
Container mit SELinux schützen
Sie können Ihre Container sichern, indem Sie SELinux aktivieren. SELinux wird für Red Hat Enterprise Linux (RHEL) unterstützt. Wenn auf Ihren Hostmaschinen RHEL ausgeführt wird und Sie SELinux für Ihren Cluster aktivieren möchten, müssen Sie SELinux auf allen Ihren Hostcomputern aktivieren. Weitere Informationen finden Sie unter Container mit SELinux sichern.
seccomp verwenden, um Container einzuschränken
Der sichere Computing-Modus (seccomp) ist ab Version 1.11 von GKE on Bare Metal verfügbar. Die Ausführung von Containern mit einem seccomp-Profil erhöht die Sicherheit Ihres Clusters, da dadurch die Systemaufrufe eingeschränkt werden, die Container an den Kernel senden dürfen. Dadurch sinkt die Wahrscheinlichkeit, dass Kernel-Sicherheitslücken ausgenutzt werden.
Das standardmäßige Profil seccomp enthält eine Liste der Systemaufrufe, die ein Container ausführen darf. Alle Systemaufrufe, die nicht in der Liste enthalten sind, sind nicht zulässig. seccomp ist in Version 1.11 von GKE on Bare Metal standardmäßig aktiviert. Das bedeutet, dass alle Systemcontainer und Kundenarbeitslasten mit dem Standardprofil seccomp der Containerlaufzeit ausgeführt werden. Auch Container und Arbeitslasten, für die in ihren Konfigurationsdateien kein seccomp-Profil angegeben ist, unterliegen seccomp-Einschränkungen.
seccomp clusterweite oder für bestimmte Arbeitslasten deaktivieren
Sie können seccomp nur während der Clustererstellung oder beim Clusterupgrade deaktivieren.
bmctl update kann nicht verwendet werden, um diese Funktion zu deaktivieren. Wenn Sie seccomp in einem Cluster deaktivieren möchten, fügen Sie der Konfigurationsdatei des Clusters den folgenden Abschnitt clusterSecurity hinzu:
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: example
namespace: cluster-example
spec:
...
clusterSecurity:
enableSeccomp: false
...
Im unwahrscheinlichen Fall, dass einige Ihrer Arbeitslasten Systemaufrufe ausführen müssen, die seccomp standardmäßig blockiert, müssen Sie seccomp nicht für den gesamten Cluster deaktivieren. Stattdessen können Sie einzelne Arbeitslasten, die in unconfined mode ausgeführt werden sollen, einzeln auswählen. Wenn Sie eine Arbeitslast in unconfined mode ausführen, wird diese Arbeitslast von den Einschränkungen befreit, die das Profil seccomp für den Rest des Clusters erzwingt.
Zum Ausführen eines Containers in unconfined mode fügen Sie dem Pod-Manifest den folgenden securityContext-Abschnitt hinzu:
apiVersion: v1
kind: Pod
....
spec:
securityContext:
seccompProfile:
type: Unconfined
....
Container nicht als root-Nutzer ausführen
Prozesse in Containern werden standardmäßig als root ausgeführt. Dies stellt ein potenzielles Sicherheitsproblem dar, denn wenn ein Prozess aus dem Container herausbricht, wird dieser Prozess auf dem Hostcomputer als root ausgeführt. Es wird daher empfohlen, alle Arbeitslasten als Nutzer ohne Rootberechtigung auszuführen.
In den folgenden Abschnitten werden zwei Möglichkeiten zum Ausführen von Containern als Nicht-Root-Nutzer beschrieben.
Methode 1: USER-Anweisung in Dockerfile hinzufügen
Diese Methode verwendet Dockerfile, um sicherzustellen, dass Container nicht als root-Nutzer ausgeführt werden. In einem Dockerfile können Sie angeben, welcher Nutzer in einem Container ausgeführt werden soll. Das folgende Snippet aus einem Dockerfile zeigt, wie das geht:
....
#Add a user with userid 8877 and name nonroot
RUN useradd −u 8877 nonroot
#Run Container as nonroot
USER nonroot
....
In diesem Beispiel wird mit dem Linux-Befehl useradd -u im Container ein Nutzer mit dem Namen nonroot erstellt. Dieser Nutzer hat die Nutzer-ID (UID) 8877.
In der nächsten Zeile von Dockerfile wird der Befehl USER nonroot ausgeführt. Dieser Befehl gibt an, dass Befehle ab diesem Punkt im Image als Nutzer-nonroot ausgeführt werden.
Gewähren Sie Berechtigungen der UID 8877, damit die Containerprozesse für nonroot ordnungsgemäß ausgeführt werden können.
Methode 2: securityContext-Felder in der Kubernetes-Manifestdatei hinzufügen
Bei dieser Methode wird eine Kubernetes-Manifestdatei verwendet, um sicherzustellen, dass Container nicht als root-Nutzer ausgeführt werden. Die Sicherheitseinstellungen werden für einen Pod festgelegt und diese werden wiederum auf alle Container innerhalb des Pods angewendet.
Das folgende Beispiel zeigt einen Auszug aus einer Manifestdatei für einen bestimmten Pod:
apiVersion: v1
kind: Pod
metadata:
name: name-of-pod
spec:
securityContext:
runAsUser: 8877
runAsGroup: 8877
....
Das Feld runAsUser gibt an, dass für alle Container im Pod alle Prozesse mit der Nutzer-ID 8877 ausgeführt werden. Das Feld runAsGroup gibt an, dass diese Prozesse die primäre Gruppen-ID (GID) 8877 haben. Denken Sie daran, der UID 8877 die erforderlichen und ausreichenden Berechtigungen zu erteilen, damit die Containerprozesse ordnungsgemäß ausgeführt werden können.
Dadurch wird sichergestellt, dass Prozesse in einem Container als UID 8877 ausgeführt werden, die weniger Berechtigungen als Root hat.
Systemcontainer in GKE on Bare Metal helfen beim Installieren und Verwalten von Clustern.
Die von diesen Containern verwendeten UIDs und GIDs können über das Feld startUIDRangeRootlessContainers in der Clusterspezifikation gesteuert werden. startUIDRangeRootlessContainers ist ein optionales Feld, das, wenn nicht angegeben, den Wert 2000 hat. Zulässige Werte für startUIDRangeRootlessContainers sind 1000–57000. Der Wert startUIDRangeRootlessContainers kann nur während Upgrades geändert werden. Die Systemcontainer verwenden die UIDs und GIDs im Bereich startUIDRangeRootlessContainers bis startUIDRangeRootlessContainers + 2999.
Das folgende Beispiel zeigt einen Auszug einer Manifestdatei für eine Clusterressource:
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: name-of-cluster
spec:
clusterSecurity:
startUIDRangeRootlessContainers: 5000
...
Wählen Sie den Wert für startUIDRangeRootlessContainers aus, damit sich die von den Systemcontainern verwendeten UID- und GID-Bereiche nicht mit denen überschneiden, die Nutzerarbeitslasten zugewiesen sind.
"Modus ohne Root" deaktivieren
Ab der GKE on Bare Metal-Version 1.10 werden Container der Kubernetes-Steuerungsebene und -Systemcontainer standardmäßig als Nicht-Root-Nutzer ausgeführt.
GKE on Bare Metal weist diesen Nutzern UIDs und GIDs im Bereich 2000 bis 4999 zu. Diese Zuweisung kann jedoch zu Problemen führen, wenn diese UIDs und GIDs bereits Prozessen zugewiesen wurden, die in Ihrer Umgebung ausgeführt werden.
Ab der GKE on Bare Metal-Version 1.11 können Sie den Root-losen Modus deaktivieren, wenn Sie Ihren Cluster upgraden. Wenn der Root-freie Modus deaktiviert ist, werden Container und Systemcontainer der Kubernetes-Steuerungsebene als Root-Nutzer ausgeführt.
Führen Sie die folgenden Schritte aus, um den Root-losen Modus zu deaktivieren:
Fügen Sie der Konfigurationsdatei des Clusters den folgenden Abschnitt
clusterSecurityhinzu:apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: example namespace: cluster-example spec: ... clusterSecurity: enableRootlessContainers: false ...Führen Sie ein Upgrade Ihres Clusters durch. Weitere Informationen finden Sie unter Cluster upgraden.
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 Sie den Controllern, die den Clusterlebenszyklus verwalten, in der Regel erlauben, 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 für GKE on Bare Metal bereitstellen, müssen Sie die folgenden Parameter in Constraint festlegen:
parameters:
allowedGroups:
- system:masters
allowedUsers: []
Schreibgeschützten Kubelet-Port deaktivieren
Ab Version 1.15.0 wird GKE on Bare Metal standardmäßig den schreibgeschützten Kubelet-Port 10255 deaktiviert. Alle Kundenarbeitslasten, die für das Lesen von Daten aus diesem unsicheren Kubelet-Port 10255 konfiguriert sind, sollten zum sicheren Kubelet-Port 10250 migriert werden.
Nur bei Clustern, die mit Version 1.15.0 oder höher erstellt wurden, ist dieser Port standardmäßig deaktiviert. Der schreibgeschützte Kubelet-Port 10255 bleibt auch nach einem Clusterupgrade auf Version 1.15.0 oder höher für Cluster zugänglich, die mit einer Version vor 1.15.0 erstellt wurden.
Diese Änderung wurde vorgenommen, weil das Kubelet Informationen mit geringer Vertraulichkeit über den nicht authentifizierten Port 10255 veröffentlicht. Die Informationen umfassen die vollständigen Konfigurationsinformationen für alle auf einem Knoten ausgeführten Pods, die für einen Angreifer wertvoll sein können. Darüber hinaus werden Messwerte und Statusinformationen bereitgestellt, die für Ihr Unternehmen relevant sein können.
Das Deaktivieren des schreibgeschützten Kubelet-Ports wird von der CIS-Kubernetes-Benchmark empfohlen.
Wartung
Das Monitoring von Sicherheitsbulletins und das Upgrade Ihrer Cluster sind wichtige Sicherheitsmaßnahmen, die ergriffen werden sollten, wenn Ihre Cluster einsatzbereit sind.
Sicherheitsbulletins überwachen
Das GKE-Sicherheitsteam veröffentlicht Sicherheitsbulletins zu Sicherheitslücken mit hohem und kritischem Schweregrad.
Diese Bulletins richten sich nach einem gängigen Google Cloud-Schema zur Nummerierung von Sicherheitslücken und sind über die Hauptbulletinseite von Google Cloud und die Versionshinweise für GKE on Bare Metal verlinkt.
Wenn Kunden Maßnahmen ergreifen müssen, um diese Sicherheitslücken mit hohem und kritischem Schweregrad zu adressieren, kontaktiert Google Kunden per E-Mail. Darüber hinaus kann Google Kunden mit Supportverträgen auch über Supportkanäle kontaktieren.
Weitere Informationen dazu, wie Google Sicherheitslücken und Patches für GKE und GKE Enterprise handhabt, finden Sie unter Sicherheitspatches.
Cluster aktualisieren
Kubernetes implementiert regelmäßig neue Sicherheits-Features und bietet Sicherheitspatches. GKE on Bare Metal-Releases enthalten Kubernetes-Sicherheitsverbesserungen, mit denen Sicherheitslücken geschlossen werden, die Ihre Cluster betreffen können.
Sie sind dafür verantwortlich, Ihre GKE on Bare-Metal-Cluster auf dem neuesten Stand zu halten. Lesen Sie die Versionshinweise zu den einzelnen Releases. Sie sollten jeden Monat auf neue Patchreleases und alle vier Monate auf neue Nebenversionen aktualisieren, um Sicherheitsrisiken für Ihre Cluster zu minimieren.
Einer der vielen Vorteile des Clusterupgrades besteht darin, dass die kubeconfig-Datei des Clusters automatisch aktualisiert wird. Die kubeconfig-Datei authentifiziert einen Nutzer bei einem Cluster. Die kubeconfig-Datei wird Ihrem Clusterverzeichnis hinzugefügt, wenn Sie einen Cluster mit bmctl erstellen. Der Standardname und der Standardpfad sind bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.
Wenn Sie ein Cluster upgraden, wird die kubeconfig-Datei dieses Clusters automatisch verlängert. Andernfalls läuft die Datei „kubeconfig” ein Jahr nach ihrer Erstellung ab.
Informationen zum Upgrade Ihrer Cluster finden Sie unter Cluster upgraden.
VPC Service Controls mit Cloud Interconnect oder Cloud VPN verwenden
Cloud Interconnect bietet Verbindungen mit niedriger Latenz und Hochverfügbarkeit, mit denen Sie Daten zuverlässig zwischen Ihren lokalen Bare-Metal-Maschinen und VPC-Netzwerken (Virtual Private Cloud) von Google Cloud übertragen können. Weitere Informationen zu Cloud Interconnect finden Sie in der Übersicht zur Bereitstellung von Dedicated Interconnect.
Mit Cloud VPN können Sie Ihr Peer-Netzwerk über eine IPsec-VPN-Verbindung sicher mit Ihrem VPC-Netzwerk (Virtual Private Cloud) verbinden. Weitere Informationen zu Cloud VPN finden Sie unter Cloud VPN – Übersicht.
VPC Service Controls funktioniert entweder mit Cloud Interconnect oder Cloud VPN und bietet so zusätzliche Sicherheit für Ihre Cluster. VPC Service Controls verringert das Risiko der Daten-Exfiltration. Mit VPC Service Controls können Sie Projekte zu Dienstperimetern hinzufügen, die Ressourcen und Dienste vor Anfragen schützen, die ihren Ursprung außerhalb des Perimeters haben. Weitere Informationen zu Dienstperimetern finden Sie unter Dienstperimeter – Details und Konfiguration.
Zum vollständigen Schutz von GKE on Bare Metal müssen Sie die eingeschränkte VIP verwenden und dem Dienstperimeter die folgenden APIs hinzufügen:
- Artifact Registry API (
artifactregistry.googleapis.com) - Resource Manager API (
cloudresourcemanager.googleapis.com) - Compute Engine API (
compute.googleapis.com) - Connect Gateway API (
connectgateway.googleapis.com) - Google Container Registry API (
containerregistry.googleapis.com) - GKE Connect API (
gkeconnect.googleapis.com) - GKE Hub API (
gkehub.googleapis.com) - GKE On-Prem API (
gkeonprem.googleapis.com) - Identity and Access Management (IAM) API (
iam.googleapis.com) - Cloud Logging API (
logging.googleapis.com) - Cloud Monitoring API (
monitoring.googleapis.com) - Config Monitoring for Ops API (
opsconfigmonitoring.googleapis.com) - Service Control API (
servicecontrol.googleapis.com) - Cloud Storage API (
storage.googleapis.com)
Wenn Sie einen Cluster mit bmctl erstellen oder upgraden, verwenden Sie das Flag --skip-api-check, um den Aufruf der Service Usage API (serviceusage.googleapis.com) zu umgehen. Die Service Usage API wird von VPC Service Controls nicht unterstützt.