Der Tanzu Kubernetes Grid-Dienst stellt Tanzu Kubernetes-Cluster mit aktiviertem PodSecurityPolicy-Zugangscontroller bereit. Dies bedeutet, dass zur Bereitstellung von Arbeitslasten die Pod-Sicherheitsrichtlinie (Pod Security Policy, PSP) erforderlich ist. Clusteradministratoren können Pods von ihrem Benutzerkonto für einen beliebigen Namespace und von Dienstkonten für den Namespace „kube-system“ bereitstellen. Für alle anderen Anwendungsfälle müssen Sie explizit eine Bindung an ein PodSecurityPolicy-Objekt herstellen. Cluster enthalten standardmäßige Pod-Sicherheitsrichtlinien, an die Sie binden können. Sie haben aber auch die Möglichkeit, eigene Sicherheitsrichtlinien zu erstellen.
Informationen zu Kubernetes-Pod-Sicherheitsrichtlinien
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.
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.
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.
Um PSPs effektiv zu verwenden, müssen Sie beide Workflows zum Erstellen von Pods berücksichtigen. 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.
Weitere Informationen finden Sie unter Pod Security Policies, RBAC und Service Accounts in der Kubernetes-Dokumentation.
PodSecurityPolicy-Standardressource für Tanzu Kubernetes-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. |
Keine Standardbindungen für Tanzu Kubernetes-Cluster
Der Tanzu Kubernetes Grid-Dienst stellt kein standardmäßiges RoleBinding- und ClusterRoleBinding-Objekt für Tanzu Kubernetes-Cluster bereit.
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. Weitere Informationen hierzu finden Sie unter Gewähren des Entwicklerzugriffs auf Tanzu Kubernetes-Cluster.
Wirkung der PodSecurityPolicy-Standardressource auf Tanzu Kubernetes-Cluster
- 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 Namespace verwenden möchten, finden Sie weitere Informationen unter Lernprogramm für Tanzu Kubernetes Guestbook.
- 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. Weitere Informationen hierzu finden Sie unter Lernprogramm für Tanzu Kubernetes Guestbook.
