Seguridad en Kubernetes: Todo sobre Pod Security Standards (PSS)

El Pod Security Standards (PSS) es un estándar de seguridad introducido en Kubernetes para garantizar que los pods, que son las unidades de trabajo básicas en un clúster Kubernetes, se ejecuten dentro de un marco seguro y predefinido. Esto significa que los pods deben cumplir con ciertas configuraciones que minimicen riesgos de seguridad, como la ejecución con permisos elevados o el acceso directo al sistema operativo del host.

El PSS se convirtió en una característica estándar a partir de Kubernetes v1.25, reemplazando las políticas de seguridad de pods anteriores basadas en PodSecurityPolicy (PSP), que han quedado obsoletas.

Objetivo de PSS

• Proporcionar un marco de seguridad simple y efectivo.
• Evitar configuraciones inseguras en los pods que puedan ser explotadas por atacantes.
• Ayudar a los administradores y equipos de DevOps a aplicar buenas prácticas de seguridad de manera consistente.

¿Cómo funciona el PSS?

El PSS clasifica los niveles de seguridad en tres categorías principales, cada una con reglas específicas que definen qué configuraciones son permitidas o restringidas. Esto permite a los administradores seleccionar el nivel de seguridad más apropiado para sus necesidades.

1. Privileged (Privilegiado):

• Propósito: Uso mínimo en aplicaciones estándar. Este nivel está diseñado para pods que necesitan acceso completo a los recursos del host o privilegios elevados.
• Permite:
  • Acceso al sistema de archivos del host (hostPath).
  • Escalación de privilegios (allowPrivilegeEscalation: true).
  • Ejecución como usuario root sin restricciones.
  • Configuraciones críticas de red y sistema (hostNetwork, hostPID, hostIPC).
• Uso común: Herramientas de monitoreo (e.g., Dynatrace, Prometheus node-exporter) o aplicaciones críticas del sistema.

2. Baseline (Básico):

• Propósito: Es el nivel mínimo recomendado para la mayoría de las aplicaciones, balanceando seguridad y funcionalidad.
• Permite:
  • Ejecución como root en casos específicos.
  • Uso limitado de capacidades adicionales necesarias para la operación del contenedor.
• Restringe:
  • La escalación de privilegios (allowPrivilegeEscalation: false).
  • Configuraciones críticas como hostNetwork, hostPID y hostIPC.
• Uso común: Aplicaciones estándar que no necesitan acceso elevado al host ni configuraciones críticas.

3. Restricted (Restringido):

• Propósito: Es el nivel más seguro y recomendado para entornos de producción.
• Permite:
  • Solo configuraciones consideradas seguras según las mejores prácticas actuales.
• Restringe:
  • Ejecución como root (runAsNonRoot: true).
  • Uso de capacidades adicionales o escalación de privilegios.
  • Montajes de volúmenes que comprometan la seguridad del host, como hostPath.
• Uso común: Aplicaciones que siguen estrictamente las mejores prácticas de seguridad.

¿Por qué es PSS el Estándar en Kubernetes?

El PSS se introdujo como respuesta a la necesidad de un marco más simple y directo que las antiguas PodSecurityPolicy (PSP). Las PSP, aunque poderosas, eran difíciles de configurar y generaban complejidad innecesaria en la gestión de políticas de seguridad.

Ventajas de PSS sobre PSP

1. Simplicidad: Aplicar etiquetas a los namespaces es mucho más fácil que configurar PSP.
2. Flexibilidad: Permite diferentes niveles de seguridad para distintos namespaces dentro del mismo clúster.
3. Estandarización: Los niveles predefinidos (Privileged, Baseline, Restricted) siguen buenas prácticas reconocidas.
4. Compatibilidad: No requiere cambios drásticos en las configuraciones existentes si se aplica progresivamente.

Cómo Afecta PSS a los Pods ya Desplegados

Cuando implementas PSS en un clúster Kubernetes, los pods existentes no se ven afectados inmediatamente. Sin embargo, al intentar actualizar, escalar o reemplazar pods que no cumplan con las políticas, estos podrían ser rechazados por el Admission Controller.

Impacto de PSS en Pods Existentes

1. Modos de Operación:
   • Audit: Registra violaciones en los logs, pero permite que los pods se ejecuten.
   • Warn: Muestra advertencias al usuario durante el despliegue.
   • Enforce: Rechaza directamente los pods que no cumplen las políticas.
2. Acción Requerida:
   • Revisa y actualiza los manifiestos YAML de los pods existentes para que cumplan con las políticas aplicadas al namespace.

Impacto en Herramientas de Monitorización

Herramientas como Dynatrace, Prometheus y Fluentd necesitan configuraciones específicas para operar correctamente. Por ejemplo:

• Dynatrace OneAgent: Requiere permisos elevados para acceder a métricas del host y realizar inyecciones en procesos. Sin estos permisos, la monitorización Full-Stack podría no ser funcional.
• Prometheus node-exporter: Necesita acceso al sistema de archivos del host, lo que podría estar restringido en el modo Restricted.

Soluciones:

• Crear un namespace con política Baseline o Privileged para estas herramientas.
• Ajustar el securityContext y las capacidades de los pods según las políticas.

Cómo Implementar PSS de Forma Segura

Pasos para Configurar PSS:

1. Etiquetar Namespaces:
   • Aplica las políticas de seguridad necesarias usando etiquetas.
   • Ejemplo para modo Restricted:
     kubectl label namespace <nombre-namespace> pod-security.kubernetes.io/enforce=restricted
2. Revisar y Ajustar Pods:
   • Modifica los manifiestos YAML para que cumplan con las restricciones del PSS.
3. Probar Antes de Aplicar:
   • Usa los modos Audit o Warn antes de habilitar Enforce para identificar posibles problemas.

Mejores Prácticas:

1. Dividir Namespaces por Niveles de Seguridad:
   • Usa namespaces dedicados para aplicaciones con diferentes necesidades de seguridad.
   • Ejemplo:
     • production: Restricted
     • monitoring: Baseline
2. Validar Configuraciones:
   • Usa herramientas como kube-score o OPA Gatekeeper para verificar el cumplimiento de las políticas.
3. Documentar Cambios:
   • Asegúrate de que todos los equipos entiendan las políticas aplicadas y los ajustes requeridos.

Cómo Hacer Pruebas con PSS

1. Configurar un Entorno de Prueba:
   • Crea namespaces de prueba con diferentes niveles de políticas.
2. Desplegar Pods de Prueba:
   • Usa pods con configuraciones variadas para verificar el impacto de las políticas.
3. Revisar Logs de Auditoría:
   • Habilita el modo Audit para identificar configuraciones que violen las políticas.
4. Simular Escenarios de Producción:
   • Despliega aplicaciones reales para evaluar el impacto en su funcionalidad.

Resumiendo:

El Pod Security Standards (PSS) es un estándar esencial y ahora predeterminado en Kubernetes para garantizar la seguridad de los pods. Entender cómo funciona, cómo afecta a los pods existentes y cómo impacta herramientas críticas como Dynatrace, es clave para mantener un clúster seguro y funcional.

Adoptar PSS requiere planificación y pruebas, pero con las mejores prácticas descritas, podrás implementar políticas de seguridad efectivas sin comprometer la operatividad de tu clúster.