TKG en Supervisor admite la seguridad de pods mediante la controladora de admisión de la directiva de seguridad de pods, que está habilitada de forma predeterminada para los clústeres de Tanzu Kubernetes que utilizan TKR v1.24 y versiones anteriores.
Requisito previo: TKR 1.24 y versiones anteriores
El contenido de este tema se aplica a los clústeres de TKG en Supervisor que se aprovisionan con TKR v1.24 y versiones anteriores. De forma predeterminada, versiones de Tanzu Kubernetes habilita la controladora de admisión de la directiva de seguridad de pods.
La controladora de admisión de la directiva de seguridad de pods es la controladora de admisión de seguridad de pods. Los clústeres de TKG en Supervisor aprovisionados con TKR v1.25 y versiones posteriores habilitan la controladora de admisión de seguridad de pods. Consulte Configurar PSA para TKR 1.25 y versiones posteriores.
Controladora de admisión de la directiva de seguridad de pods
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. Para obtener más información, consulte Directivas de seguridad de pods y RBAC en la documentación de Kubernetes.
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. Para obtener más información, consulte RBAC en la documentación de Kubernetes.
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 obtener más información, consulte Cuentas de servicio en la documentación de Kubernetes.
Para utilizar las PSP de forma efectiva, debe tener en cuenta ambos flujos de trabajo de creación de pods: directo e indirecto. 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.
PodSecurityPolicy predeterminada para clústeres TKG
| 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 |
Enlaces de función y ClusterRole para clústeres de TKG
TKG en Supervisor no ofrece objetos RoleBinding ni ClusterRoleBinding predeterminados para los clústeres de TKG. En esta documentación se proporcionan ejemplos que puede utilizar. Consulte Aplicar la directiva de seguridad de pods predeterminada a clústeres de servicio TKG.
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.
- 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 de Kubernetes diferente, cree un objeto RoleBinding para él o un objeto ClusterRoleBinding.
- 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.
Para ver ejemplos de enlaces, consulte Aplicar la directiva de seguridad de pods predeterminada a clústeres de servicio TKG.
