servicio Tanzu Kubernetes Grid aprovisiona clústeres de Tanzu Kubernetes con la controladora de admisión de PodSecurityPolicy habilitada. Esto significa que se requiere la directiva de seguridad de pods para implementar cargas de trabajo. Los administradores de clústeres pueden implementar pods desde su cuenta de usuario a cualquier espacio de nombres y desde cuentas de servicio al espacio de nombres de kube-system. En todos los demás casos prácticos, debe establecer un enlace de manera explícita a un objeto PodSecurityPolicy. Los clústeres incluyen directivas de seguridad de pods predeterminadas a las que se puede enlazar, o bien puede crear una propia.
Acerca de las directivas de seguridad de pods de Kubernetes
Las directivas de seguridad de pods (Pod Security Policy, PSP) de Kubernetes son recursos del nivel del clúster que controlan la seguridad de los pods. Las PSP le permiten controlar los tipos de pods que se pueden implementar y los tipos de cuentas que pueden implementarlos.
Un recurso PodSecurityPolicy define un conjunto de condiciones que un pod debe cumplir para que pueda implementarse. Si no se cumplen las condiciones, el pod no puede implementarse. Un único recurso PodSecurityPolicy debe validar un pod por completo. Algunas de las reglas de un pod no pueden estar en una directiva y algunas de ellas en otra.
Existen varias formas de implementar el uso de directivas de seguridad de pods en Kubernetes. El método habitual consiste en usar objetos de control de acceso basado en funciones (Role-Based Access Control, RBAC). ClusterRole y ClusterRoleBinding se aplican en todo el clúster, mientras que Role y RoleBinding se aplican en un espacio de nombres específico. Si se utiliza RoleBinding, solo permite que los pods se ejecuten en el mismo espacio de nombres que el enlace.
Los pods de Kubernetes pueden crearse de forma directa o indirecta. Un pod se crea de forma directa mediante la implementación de una especificación de pod con la cuenta de usuario. Para crear un pod de forma indirecta, se define un recurso de nivel superior (como Deployment o DaemonSet). En este caso, una cuenta de servicio crea el pod subyacente.
Para utilizar las PSP de forma efectiva, debe tener en cuenta ambos flujos de trabajo de creación de pods. Si un usuario crea un pod de forma directa, la PSP enlazada a la cuenta de usuario controla la operación. Si un usuario crea un pod por medio de una cuenta de servicio, la PSP debe estar enlazada a la cuenta de servicio que se utiliza para crear el pod. Si no se define ninguna cuenta de servicio en la especificación del pod, se utiliza la cuenta de servicio predeterminada del espacio de nombres.
Para obtener más información, consulte Directivas de seguridad de pods, RBAC y Cuentas de servicio en la documentación de Kubernetes.
PodSecurityPolicy predeterminado para clústeres de Tanzu Kubernetes
| PSP predeterminada | Permiso | Descripción | Objeto ClusterRole predeterminado asociado |
|---|---|---|---|
vmware-system-privileged |
Ejecutar como cualquiera | PSP permisiva. Equivale a la ejecución de un clúster sin la controladora de admisión de PSP habilitada. | psp:vmware-system-privileged puede utilizar esta PSP |
vmware-system-restricted |
Debe ejecutarse como no raíz | PSP restrictiva. No permite el acceso con privilegios a los contenedores de pods, bloquea las posibles escalaciones en la raíz y requiere el uso de varios mecanismos de seguridad. | psp:vmware-system-restricted puede utilizar esta PSP |
No hay enlaces predeterminados para clústeres de Tanzu Kubernetes
El servicio Tanzu Kubernetes Grid no ofrece RoleBinding ni ClusterRoleBinding predeterminados para los clústeres de Tanzu Kubernetes.
Un usuario de vCenter Single Sign-On al que se otorga el permiso Editar en un espacio de nombres de vSphere se asigna a la función cluster-admin para cualquier clúster de Tanzu Kubernetes implementado en ese espacio de nombres. Un administrador de clústeres autenticado puede usar implícitamente la PSP de vmware-system-privileged. Aunque técnicamente no es un ClusterRoleBinding, tiene el mismo efecto.
El administrador de clústeres debe definir los enlaces para permitir o restringir los tipos de pods que los usuarios pueden implementar en un clúster. Si se utiliza un RoleBinding, el enlace solo permite que los pods se ejecuten en el mismo espacio de nombres que el enlace. Esto puede emparejarse con los grupos del sistema para conceder acceso a todos los pods que se ejecutan en el espacio de nombres. Los usuarios que no son administradores y que se autentican en el clúster se asignan a la función authenticated y se pueden enlazar a la PSP predeterminada como tal. Consulte Conceder acceso de desarrollador a clústeres de Tanzu Kubernetes.
Efecto del PodSecurityPolicy predeterminado en los clústeres de Tanzu Kubernetes
- Un administrador de clústeres puede crear pods con privilegios directamente en cualquier espacio de nombres mediante su cuenta de usuario.
- Un administrador de clústeres puede crear implementaciones, StatefulSets y DaemonSet (cada uno de los cuales crea pods con privilegios) en el espacio de nombres kube-system. Si desea utilizar un espacio de nombres diferente, consulte Tutorial del libro de visitas de Tanzu Kubernetes.
- Un administrador de clústeres puede crear sus propias PSP (además de las dos PSP predeterminadas) y enlazar estas PSP a cualquier usuario. Si define su propia PSP, consulte Orden de directivas en la documentación de Kubernetes.
- Ningún usuario autenticado puede crear pods con privilegios o sin privilegios hasta que el administrador del clúster enlaza PSP a los usuarios autenticados. Consulte Tutorial del libro de visitas de Tanzu Kubernetes.
