In diesem Dokument wird beschrieben, wie Sie die Sicherheit Ihrer Anthos-Cluster in Bare-Metal-Clustern erhöhen.
Container mit SELinux schützen
Sie können Ihre Container sichern, indem Sie SELinux aktivieren, das für Red Hat Enterprise Linux (RHEL) und CentOS unterstützt wird. Wenn auf Ihren Hostcomputern RHEL oder CentOS ausgeführt wird und Sie SELinux für Ihren Cluster aktivieren möchten, müssen Sie SELinux auf allen Hostcomputern aktivieren. Weitere Informationen finden Sie unter Container mit SELinux sichern.
Container nicht als root-Nutzer ausführen
Prozesse in Containern werden standardmäßig als root ausgeführt. Dies stellt ein potenzielles Sicherheitsproblem dar, da ein Prozess, der den Container verlässt, als Root auf dem Hostcomputer ausgeführt wird. 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 erstellt der Linux-Befehl useradd -u einen Nutzer namens nonroot im Container. 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 Anthos-Clustern in Bare-Metal verwenden UIDs und GIDs im Bereich von 2000 bis 4999. Verwenden Sie daher UIDs und GIDs, die nicht in diesem reservierten Bereich liegen, wenn Sie Nutzerarbeitslasten Berechtigungen zuweisen.
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 Anthos-Clustern auf Bare-Metal bereitstellen, müssen Sie die folgenden Parameter in Constraint festlegen:
parameters:
allowedGroups:
- system:masters
allowedUsers: []
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 Sicherheitsteam von Anthos veröffentlicht Sicherheitsbulletins für Sicherheitslücken mit hohem und kritischem Schweregrad.
Diese Bulletins folgen einem gängigen Schema zur Sicherheitslückennummer in Google Cloud und sind über die Hauptseite der Google Cloud-Bulletins und über die Anthos-Cluster auf Bare Metal-Versionshinweise verknüpft. Verwenden Sie diesen XML-Feed, um Sicherheitsbulletins für Anthos-Cluster auf Bare-Metal und zugehörige Produkte zu abonnieren: https://cloud.google.com/feeds/anthos-gke-security-bulletins.xml 
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 Anthos verwaltet, finden Sie unter Sicherheitspatches.
Cluster aktualisieren
Kubernetes implementiert regelmäßig neue Sicherheits-Features und bietet Sicherheitspatches. Anthos-Cluster auf Bare-Metal-Releases enthalten Kubernetes-Sicherheitserweiterungen, die Sicherheitslücken beheben, die sich auf Ihre Cluster auswirken können.
Sie sind selbst dafür verantwortlich, Ihre Anthos-Cluster auf dem neuesten Stand zu halten. Lesen Sie für jede Version die Versionshinweise. Um Sicherheitsrisiken für Ihre Anthos-Cluster zu minimieren, sollten Sie jeden Monat neue Patchversionen und Nebenversionen alle drei Monate aktualisieren.
Einer der vielen Vorteile eines Upgrades eines Clusters 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.