Esta página proporciona un resumen de las mejores prácticas para aplicar los estándares de seguridad de Pods.
El controlador de admisión de seguridad de Pods pretende reemplazar a las obsoletas PodSecurityPolicies.
Los namespaces que carecen de cualquier configuración deberían ser considerados una brecha significativa en el modelo de seguridad de tu clúster. Recomendamos tomar tiempo para analizar los tipos de cargas de trabajo que se ejecutan en cada namespace y, tomando como referencia los estándares de seguridad de Pods, decidir un nivel apropiado para cada una de ellas. Los namespaces sin etiquetas solo deberían indicar que todavía deben ser evaluados.
En el escenario en que todas las cargas de trabajo en todos los namespaces tienen los mismos requerimientos de seguridad, proporcionamos un ejemplo que ilustra cómo las etiquetas de PodSecurity pueden ser utilizadas de forma masiva.
En un mundo ideal, cada pod en cada namespace cumpliría los requerimientos de la política restricted.
Sin embargo, esto no es posible ni práctico debido a que algunas cargas de trabajo requerirán privilegios
elevados por razones legítimas.
privileged deberían establecer y aplicar controles de acceso apropiados.Los modos audit y warn del controlador de admisión de estándares de seguridad de Pods facilitan
recopilar información de seguridad importante de tus pods sin romper tus cargas de trabajo existentes.
Es una buena práctica habilitar estos modos para todos los namespaces, configurando el nivel deseado
y la versión que te gustaría eventualmente enforce. Las advertencias y anotaciones de auditoría generadas en
esta fase pueden guiarte hacia ese estado. Si esperas que los autores de las cargas de trabajo hagan cambios para ajustarse
al nivel deseado, habilita el modo warn. Si esperas utilizar los registros de auditoría para monitorear o gestionar
cambios para ajustarse al nivel deseado, habilita el modo audit.
Cuando tienes configurado el modo enforce en tu valor deseado, estos modos todavía pueden ser útiles de
diferentes maneras:
warn en el mismo nivel que enforce, los clientes recibirán advertencias cuando intenten
crear Pods (o recursos que tienen plantillas de Pod) que no superen la validación. Esto les ayudará
a actualizar aquellos recursos para que cumplan con la normativa.enforce a una versión específica que no sea la más reciente, configurar los modos audit y warn
al mismo nivel que enforce, pero en la versión latest, proporciona visibilidad sobre las configuraciones
que estaban permitidas en versiones anteriores pero que ya no se permiten según las mejores prácticas actuales.Otras alternativas para aplicar perfiles de seguridad están siendo desarrolladas en el ecosistema de Kubernetes:
La decisión de optar por una solución nativa (ej. el controlador de admisión PodSecurity) en vez de una herramienta de terceros depende completamente de tu propia situación. Cuando evalúes cualquier solución, confiar en tu cadena de suministro es crucial. Finalmente, utilizar cualquiera de los enfoques mencionados anteriormente será mejor que no hacer nada.
Los elementos de esta página se refieren a productos o proyectos de terceros que proporcionan la funcionalidad requerida por Kubernetes. Los autores del proyecto Kubernetes no son responsables de esos productos o proyectos de terceros. Consulta las directrices del sitio web de la CNCF para más detalles.
Deberías leer la guía de contenido antes de proponer un cambio que añada un enlace adicional de terceros.