Cómo afectan las Pod Security Standards (PSS) en Kubernetes a las herramientas de monitorización

Con la evolución constante de Kubernetes como la solución preferida para la orquestación de contenedores, también aumenta la necesidad de mejorar la seguridad en los clústeres. Las Pod Security Standards (PSS) representan un avance significativo hacia la seguridad, pero también presentan desafíos para herramientas críticas como Prometheus, Dynatrace, New Relic, Datadog, y otras.

En este artículo, profundizaremos en cómo afectan las PSS a estas herramientas, los ajustes necesarios para implementarlas, y cómo manejar una migración a entornos productivos sin interrupciones.

1. ¿Qué son las Pod Security Standards (PSS) y por qué son esenciales?

Las Pod Security Standards son un mecanismo estándar de seguridad en Kubernetes diseñado para prevenir configuraciones inseguras en los pods. Sustituyen a las obsoletas PodSecurityPolicies (PSP), eliminadas desde Kubernetes 1.25, y se integran en los admission controllers para validar las configuraciones de los pods antes de su creación.

Los niveles de PSS:

1. Privileged:
   • Permite configuraciones con acceso elevado, como contenedores privilegiados, montajes de volúmenes del host, y capacidades avanzadas de Linux.
   • Útil solo en casos específicos, pero presenta un alto riesgo de seguridad.
2. Baseline:
   • Proporciona restricciones básicas para evitar configuraciones inseguras comunes.
   • Adecuado para la mayoría de las aplicaciones estándar.
3. Restricted:
   • Implementa restricciones estrictas, como el uso obligatorio de usuarios no root y perfiles AppArmor.
   • Es el nivel recomendado para clústeres productivos.

2. Importancia de las PSS en Kubernetes

Kubernetes, al ser una solución popular para cargas multi-tenant, requiere estándares que aseguren que cada pod opere de forma segura sin comprometer el clúster. Las PSS ayudan a:

• Prevenir errores humanos: Como ejecutar contenedores privilegiados sin justificación.
• Reducir la superficie de ataque: Impidiendo configuraciones que puedan ser explotadas.
• Fomentar mejores prácticas: Como el uso de usuarios no root y la eliminación de permisos innecesarios.

Sin embargo, implementar estas políticas puede ser un reto, especialmente para herramientas de monitorización que requieren acceso profundo al sistema para recopilar métricas.

3. Cómo afectan las PSS a las herramientas de monitorización

Las herramientas de monitorización necesitan configuraciones específicas para operar correctamente, y estas pueden entrar en conflicto con las restricciones de PSS, especialmente en modo Restricted.

Prometheus

Prometheus recopila métricas de nodos y aplicaciones a través de exportadores y agentes. Estas operaciones pueden verse afectadas por:

1. Restricciones de seguridad:
   • Problema: El nivel Restricted exige securityContext configurado para ejecutar como usuario no root.
   • Solución: Configurar Prometheus con:

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false

Acceso a volúmenes del host:

• Problema: Prometheus utiliza volúmenes para almacenar datos persistentes y puede necesitar acceso a /proc o /sys para ciertas métricas.
• Solución: Usar PersistentVolumeClaims (PVC) en lugar de volúmenes del host:

volumeMounts:
  - name: prometheus-data
    mountPath: /data
volumes:
  - name: prometheus-data
    persistentVolumeClaim:
      claimName: prometheus-pvc

1. Restricciones de exportadores:
   • Problema: El Node Exporter puede requerir capacidades privilegiadas para acceder a métricas del sistema.
   • Solución: Configurarlo en modo no privilegiado.

Dynatrace

Dynatrace utiliza agentes como OneAgent para recopilar métricas y trazas distribuidas. Las PSS afectan a Dynatrace en:

metadata:
  annotations:
    container.apparmor.security.beta.kubernetes.io/oneagent: runtime/default

1. Restricciones de seguridad:
   • Problema: El agente de Dynatrace puede necesitar permisos elevados.
   • Solución: Configurar el securityContext:

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false

New Relic

New Relic enfrenta desafíos similares en la recopilación de datos de nodos y aplicaciones:

1. Restricciones en acceso a nodos:
   • Problema: Los agentes pueden necesitar acceso a directorios del sistema, como /var/log.
   • Solución: Usar volúmenes específicos o logs centralizados.
2. Configuración de red:
   • Problema: Las políticas PSS pueden limitar la comunicación entre namespaces.
   • Solución: Configurar NetworkPolicies:kind: NetworkPolicy metadata: name: allow-newrelic-to-app spec: podSelector: matchLabels: app: newrelic-agent ingress: - from: - podSelector: matchLabels: app: monitored-app

kind: NetworkPolicy
metadata:
  name: allow-newrelic-to-app
spec:
  podSelector:
    matchLabels:
      app: newrelic-agent
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: monitored-app

Datadog

Datadog monitorea métricas, logs y trazas con un agente versátil:

1. Acceso a volúmenes del host:
   • Problema: Requiere acceso a /proc para métricas de nodos.
   • Solución:volumeMounts: - name: proc mountPath: /host/proc readOnly: true volumes: - name: proc hostPath: path: /proc

volumeMounts:
  - name: proc
    mountPath: /host/proc
    readOnly: true
volumes:
  - name: proc
    hostPath:
      path: /proc

• Restricciones de capacidades:
  • Problema: Puede necesitar capacidades como SYS_PTRACE.
  • Solución: Evaluar si es posible desactivar estas capacidades o configurar permisos específicos.

4. Pasos para migrar un clúster a PSS en entornos productivos

La migración a PSS en un entorno productivo debe ser metódica para evitar interrupciones:

1. Auditoría del clúster:
   • Usa herramientas como Kubescape para identificar pods que no cumplen con PSS.
2. Planificación por etapas:
   • Configura namespaces con PSS progresivamente:
     • Privileged → Baseline → Restricted.
3. Pruebas exhaustivas:
   • Despliega las herramientas de monitorización en un entorno de staging y valida:
     • La ejecución de pods.
     • La persistencia de datos.
     • La comunicación entre namespaces.
4. Despliegue gradual:
   • Activa PSS en modo Restricted un namespace a la vez, comenzando por aquellos con menor impacto.

5. Solución de problemas comunes

1. Error: pods is forbidden: violates PodSecurity:
   • Causa: Configuración incompatible con PSS.
   • Solución: Revisar el securityContext del pod.
2. Error: forbidden AppArmor profile:
   • Causa: Falta de perfiles AppArmor válidos.
   • Solución: Usar runtime/default.
3. Problemas de red:
   • Causa: Restricciones de comunicación entre namespaces.
   • Solución: Configurar NetworkPolicies adecuadas.

6. Mejores prácticas para configurar herramientas de monitorización con PSS

1. Namespaces dedicados:
   • Usa namespaces con políticas menos restrictivas (Baseline) para herramientas de monitorización.
2. Automatización:
   • Usa Helm o ArgoCD para desplegar configuraciones consistentes.
3. Documentación y comunicación:
   • Asegúrate de que los equipos comprendan los cambios y trabajen en conjunto para ajustar las configuraciones.
4. Auditorías regulares:
   • Revisa periódicamente que las herramientas cumplan con las PSS activadas.

Conclusión

Las Pod Security Standards son esenciales para asegurar clústeres Kubernetes, pero pueden complicar la integración de herramientas de monitorización. Con una planificación cuidadosa, ajustes técnicos, y pruebas rigurosas, es posible migrar a PSS manteniendo un equilibrio entre seguridad y operatividad. Al implementar estas estrategias, los técnicos pueden garantizar la continuidad de la monitorización y la seguridad de los entornos productivos.