TKG auf Supervisor unterstützt die Pod-Sicherheit mithilfe des Zugangscontrollers „Pod-Sicherheitsrichtlinie“, der standardmäßig für Tanzu Kubernetes-Cluster mit TKR v1.24 und früher aktiviert ist.
Voraussetzung: TKR 1.24 und früher
Der Inhalt dieses Themas gilt für TKG-Cluster auf Supervisor, die mit TKR v1.24 und früher bereitgestellt werden. Standardmäßig aktivieren diese Tanzu Kubernetes-Versionen die Zugangssteuerung für die Pod-Sicherheitsrichtlinie.
Der Nachfolger der Zugangssteuerung für die Pod-Sicherheitsrichtlinie ist die Zugangssteuerung „Pod-Sicherheit“. TKG-Cluster auf Supervisor, die mit TKR v1.25 und höher bereitgestellt wurden, aktivieren die Zugangssteuerung „Pod-Sicherheit“. Weitere Informationen finden Sie unter Konfigurieren von PSA für TKR 1.25 und höher.
Zugangssteuerung für Pod-Sicherheitsrichtlinie
Kubernetes-Pod-Sicherheitsrichtlinien (Pod Security Policies, PSPs) sind Ressourcen auf Clusterebene, die die Sicherheit der Pods kontrollieren. Mithilfe von PSPs haben Sie die Kontrolle darüber welche Pod-Typen von welchen Kontotypen bereitgestellt werden können.
Eine PodSecurityPolicy-Ressource definiert eine Reihe von Bedingungen, die ein Pod erfüllen muss, damit er bereitgestellt werden kann. Wenn diese Bedingungen nicht erfüllt sind, kann der Pod nicht bereitgestellt werden. Eine einzelne PodSecurityPolicy muss einen Pod in seiner Gesamtheit validieren. Ein Pod kann nicht einige seiner Regeln in einer Richtlinie und andere in einer anderen Richtlinie haben. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Pod Security Policies, RBAC.
Es gibt verschiedene Möglichkeiten, die Verwendung von Pod-Sicherheitsrichtlinien in Kubernetes zu implementieren. Der typische Ansatz ist die Verwendung von RBAC-Objekten (rollenbasierte Zugriffssteuerung, Role-Based Access Control). ClusterRole und ClusterRoleBinding werden clusterweit angewendet; Role und RoleBinding gelten für einen bestimmten Namespace. Wenn RoleBinding verwendet wird, können Pods nur im selben Namespace wie die Bindung ausgeführt werden. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter RBAC.
Es gibt zwei Methoden zum Erstellen von Kubernetes-Pods: direkt oder indirekt. Sie erstellen einen Pod direkt, indem Sie eine Pod-Spezifikation mit Ihrem Benutzerkonto bereitstellen. Sie erstellen einen Pod indirekt, indem Sie Ressourcen auf höherer Ebene definieren, z. B. eine Bereitstellung oder ein DaemonSet. In diesem Fall erstellt ein Dienstkonto den zugrunde liegenden Pod. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Service Accounts.
Um PSPs effektiv zu verwenden, müssen Sie beide Workflows zum Erstellen von Pods berücksichtigen: direkt und indirekt. Wenn ein Benutzer einen Pod direkt erstellt, steuert die an das Benutzerkonto gebundene PSP den Vorgang. Wenn ein Benutzer einen Pod mithilfe eines Dienstkontos erstellt, muss die PSP an das zum Erstellen des Pods verwendete Dienstkonto gebunden werden. Wenn in der Pod-Spezifikation kein Dienstkonto angegeben ist, wird das standardmäßige Dienstkonto für den Namespace verwendet.
PodSecurityPolicy-Standardressource für TKG-Cluster
| Standard-PSP | Berechtigung | Beschreibung | Zugeordnetes ClusterRole-Standardobjekt |
|---|---|---|---|
vmware-system-privileged |
Als beliebiger Benutzer ausführen | Uneingeschränkte PSP. Entspricht der Ausführung eines Clusters ohne aktivierten PSP-Zugangscontroller. | psp:vmware-system-privileged kann diese PSP verwenden. |
vmware-system-restricted |
Muss als Nicht-Root-Benutzer ausgeführt werden | Eingeschränkte PSP. Erlaubt keinen berechtigten Zugriff auf Pod-Container, blockiert mögliche Eskalationen zu Root und erfordert die Nutzung mehrerer Sicherheitsmechanismen. | psp:vmware-system-restricted kann diese PSP verwenden. |
Rollen- und ClusterRole-Bindungen für TKG-Cluster
TKG auf Supervisor stellt keine standardmäßigen RoleBinding- und ClusterRoleBinding-Objekte für TKG-Cluster zur Verfügung. Beispiele, die Sie verwenden können, finden Sie in dieser Dokumentation. Weitere Informationen finden Sie unter Anwenden der standardmäßigen Pod-Sicherheitsrichtlinie auf TKG-Dienstcluster.
Ein vCenter Single Sign-On-Benutzer, dem die Berechtigung Bearbeiten für einen vSphere-Namespace gewährt wird, wird der Rolle cluster-admin für jeden in diesem Namespace bereitgestellten Tanzu Kubernetes-Cluster zugeordnet. Ein authentifizierter Clusteradministrator kann implizit die PSP vmware-system-privileged verwenden. Obwohl es sich technisch nicht um ein ClusterRoleBinding-Objekt handelt, hat es dieselbe Wirkung.
Der Clusteradministrator muss beliebige Bindungen definieren, um die Pod-Typen, die Benutzer in einem Cluster bereitstellen können, zu erlauben oder einzuschränken. Wenn ein RoleBinding-Objekt verwendet wird, lässt die Bindung nur zu, dass Pods im selben Namespace wie die Bindung ausgeführt werden. Hierbei ist eine Kopplung mit Systemgruppen möglich, um Zugriff auf alle im Namespace ausgeführten Pods zu gewähren. Benutzer ohne Administratorrechte, die sich gegenüber dem Cluster authentifizieren, werden der Rolle authenticated zugewiesen und können als solche an die standardmäßige PSP gebunden werden.
- Ein Clusteradministrator kann berechtigte Pods mit seinem Benutzerkonto direkt in jedem Namespace erstellen.
- Ein Clusteradministrator kann im Namespace „kube-system“ Bereitstellungen, StatefulSet- und DaemonSet-Objekte erstellen (von denen jedes wiederum berechtigte Pods erstellt). Wenn Sie einen anderen Kubernetes-Namespace verwenden möchten, erstellen Sie dafür ein RoleBinding-Objekt oder ein ClusterRoleBinding-Objekt.
- Ein Clusteradministrator kann im Namespace „kube-system“ seine eigenen PSPs erstellen (zusätzlich zu den beiden Standard-PSPs) und diese PSPs an alle Benutzer binden. Wenn Sie Ihre eigene PSP definieren, finden Sie weitere Informationen in der englischsprachigen Dokumentation zu Kubernetes unter Policy Order (Reihenfolge der Richtlinien).
- Authentifizierte Benutzer können erst berechtigte oder nicht berechtigte Pods erstellen, nachdem der Clusteradministrator die PSPs an die authentifizierten Benutzer gebunden hat.
Beispiele für Bindungen finden Sie unter Anwenden der standardmäßigen Pod-Sicherheitsrichtlinie auf TKG-Dienstcluster.
