Por qué Kubernetes eliminó PodSecurityPolicy y qué lo reemplazó

En una publicación en el blog de Kubernetes en agosto de 2022, el proyecto ofreció contexto histórico sobre la eliminación de PodSecurityPolicy (PSP). Este controlador de admisión fue oficialmente eliminado en Kubernetes v1.25 tras un largo ciclo de obsolescencia que comenzó con la versión v1.21. El artículo explica por qué PSP no alcanzó la estabilidad y cómo su sucesor, Pod Security Admission, aborda esas deficiencias.

Qué ocurrió

PodSecurityPolicy se originó a partir de las SecurityContextConstraints (SCC) de OpenShift, que existían desde la primera versión de Red Hat OpenShift Container Platform antes de Kubernetes 1.0. PSP era esencialmente una versión reducida de SCC diseñada para el Kubernetes upstream. Su creación precedió al proceso formal de Propuestas de Mejora de Kubernetes (KEP), lo que dificulta rastrear su historia de diseño inicial. Sin embargo, los archivos muestran que la propuesta de diseño final se creó después de que ya hubieran comenzado las fusiones iniciales del código.

Las raíces de PSP se añadieron mediante una serie de solicitudes de extracción (pull requests) a partir de 2015. Antes de que existiera PSP, Kubernetes 1.0, lanzado el 10 de julio de 2015, carecía de mecanismos para restringir los contextos de seguridad más allá de un plugin de calidad alpha llamado SecurityContextDeny. El primer objeto PSP, basado en las SCC de OpenShift, se fusionó en el Kubernetes upstream en febrero de 2016 tras nueve meses de discusión. El controlador de admisión siguió en mayo de 2016, y los mecanismos de autorización se añadieron más tarde ese mismo año para permitir diferentes políticas para distintos usuarios.

A pesar de sus intenciones, PSP nunca llegó a un estado estable. Sufrió de un modelo de autorización defectuoso, dificultades de despliegue y una API inconsistente. Como resultado, la comunidad de Kubernetes decidió eliminarlo por completo en la v1.25. Ha sido reemplazado por Pod Security Admission, un nuevo plugin integrado que aplica los Estándares de Seguridad de Pods a nivel de namespace.

Cómo funciona

PodSecurityPolicy funcionaba como un plugin especializado de control de admisión que proporcionaba permisos granulares sobre los campos de seguridad de los pods. Su objetivo era desacoplar las decisiones de seguridad de bajo nivel de Linux del proceso de despliegue, permitiendo a los administradores del clúster establecer valores predeterminados seguros sin requerir que cada usuario comprendiera primitivas complejas de seguridad. El sistema dependía de mutación y validación para aplicar reglas como ejecutar como no-root o restringir la escalada de privilegios.

Sin embargo, PSP operaba sobre una base de "fail-closed" (bloqueo ante fallos). Si no existía ninguna política, todos los pods eran denegados. Esto hacía difícil habilitarlo por defecto, ya que los administradores tenían que crear políticas para cada carga de trabajo antes de activar la función. No había modo de auditoría para identificar qué pods fallarían bajo nuevas políticas, lo que llevaba a frecuentes roturas y cobertura de pruebas insuficiente. Además, la API creció de manera inconsistente con el tiempo al acomodar casos de uso específicos, dificultando su composición con otros controladores de admisión.

El reemplazo, Pod Security Admission, simplifica este modelo aplicando tres Estándares de Seguridad de Pods predefinidos: Privileged, Baseline y Restricted. Privileged es sin restricciones, Baseline permite configuraciones predeterminadas y Restricted impone mejores prácticas de seguridad. Este enfoque elimina la necesidad de conocimientos profundos de seguridad para la mayoría de los usuarios y proporciona un mecanismo de aplicación estable a nivel de namespace, más fácil de adoptar y mantener.

Detalles clave

• PodSecurityPolicy fue eliminado en Kubernetes v1.25 tras ser marcado como obsoleto en v1.21.
• PSP se originó a partir de las SecurityContextConstraints de OpenShift y se fusionó en Kubernetes en febrero de 2016.
• La función no alcanzó un estado estable debido a un modelo de autorización defectuoso y complejidad de despliegue.
• PSP operaba sobre una base de "fail-closed", requiriendo políticas para todas las cargas de trabajo antes de su habilitación.
• Pod Security Admission reemplaza a PSP con tres estándares: Privileged, Baseline y Restricted.
• El nuevo controlador de admisión es estable en Kubernetes v1.25 y opera a nivel de namespace.

Por qué importa

Para ingenieros de software y equipos de plataforma, entender el cambio de PSP a Pod Security Admission es crítico para mantener clústeres seguros. PSP requería experiencia significativa en primitivas de seguridad de Linux y una gestión cuidadosa de políticas para evitar romper despliegues. Su eliminación señala un movimiento hacia valores predeterminados de seguridad más simples y opinativos, que son más fáciles de implementar y menos propensos a errores de configuración.

Los nuevos Estándares de Seguridad de Pods ofrecen una ruta clara para asegurar cargas de trabajo sin la sobrecarga de gestionar políticas personalizadas complejas. Al centrarse en tres niveles distintos de restricción, Kubernetes facilita que los desarrolladores adopten mejores prácticas de seguridad sin necesitar conocimiento profundo de los mecanismos de seguridad subyacentes. Este cambio reduce el riesgo de mala configuración y mejora la postura general de seguridad de los clústeres de Kubernetes.

Qué puedes hacer

• Actualiza tus clústeres a Kubernetes v1.25 o posterior para usar el controlador estable Pod Security Admission.
• Revisa tus cargas de trabajo existentes para asegurarte de que cumplen con los Estándares de Seguridad de Pods Baseline o Restricted.
• Considera migrar cualquier lógica personalizada basada en PSP a las etiquetas de namespace de Pod Security Admission.