Skip to main content

Pod Security Standards

Documentación

Los Pod Security Standards (PSS) son una serie de políticas de seguridad en Kubernetes para garantizar que los pods sean creados y ejecutados con las prácticas de seguridad adecuadas. Fueron introducidos para sustituir el modelo de PodSecurityPolicy (PSP), que fue descontinuado en la versión 1.25.

Funcionan a través de un Admission Controller que intercepta la solicitud y verifica la política.

Kubernetes permite aplicar esos estándares por namespace, usando labels para definir el nivel de seguridad que debe ser impuesto. Esto garantiza que cada namespace tenga sus propias reglas de seguridad, sin afectar todo el cluster.

Los PSS definen tres niveles de seguridad:

  • Privileged: Este nivel ofrece el mínimo de restricciones de seguridad, permitiendo pods con permisos amplios, como ejecución como root o uso de capacidades privilegiadas. Es utilizado para workloads que requieren más control sobre el sistema. Ejemplo de uso: ambientes de desarrollo o pods que necesitan acceder directamente al host.

  • Baseline (Predeterminado): Este es el nivel recomendado para la mayoría de los workloads, ofreciendo una seguridad balanceada. Impone restricciones mínimas para prevenir acciones inseguras, como la ejecución de procesos como root, pero aún permite alguna flexibilidad. Ejemplo de uso: aplicaciones comunes que no necesitan de permisos elevados o acceso directo al host.

  • Restricted: Este es el nivel más seguro y aplica las restricciones más rígidas, garantizando el uso de prácticas de seguridad ideales. Prohíbe el uso de root, previene contenedores privilegiados, e impone controles rígidos sobre permisos y capacidades. Ejemplo de uso: aplicaciones críticas o en ambientes altamente regulados, donde la seguridad es una prioridad.

Los niveles de seguridad pueden ser aplicados en 3 diferentes escenarios:

  • enforce: Imposición del nivel de la política que garantizará que todos los pods creados en el namespace atiendan, como mínimo, a esa política. Si un pod no está en conformidad con las reglas de la política elegida, será bloqueado.

  • warn: El nivel que irá a generar avisos. Así, cuando un pod no atienda a los estándares impuestos, los usuarios recibirán una notificación, pero el pod aún será permitido.

  • audit: La política de auditoría que irá a grabar eventos en logs, permitiendo que acompañes cuáles pods están violando esa política, sin afectar la ejecución de los pods.

Para aplicar un PSS es necesario solamente colocar la label correcta en el namespace.

metadata:
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: latest
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: latest

Esto permite que hagas la imposición de una política de seguridad más permisiva (como baseline), mientras simultáneamente audita y emite avisos para una política más restringida (como restricted). Vamos a detallar cada parte:

No es necesario usar todo esto, lo coloqué solo para mostrar posibilidades.

Explicación de cada label:

  • pod-security.kubernetes.io/enforce=baseline: Define que el nivel de seguridad baseline será enforced (impuesto) en el namespace. Esto significa que cualquier pod que viole las reglas mínimas de seguridad definidas por el nivel "baseline" será bloqueado durante la creación o modificación.

  • pod-security.kubernetes.io/enforce-version=latest: Especifica la versión de la política de seguridad que será aplicada. En el caso, usa la versión más reciente (latest) de la política de seguridad de pods. No es obligatorio.

  • pod-security.kubernetes.io/warn=restricted: Aplica el nivel de seguridad restricted en modo de aviso (warn). Esto significa que, si un pod viola las reglas más rígidas del nivel "restricted", Kubernetes emitirá un aviso para el usuario, pero no bloqueará la creación del pod. Es útil para preparar la transición para políticas más rígidas sin interrumpir operaciones.

  • pod-security.kubernetes.io/warn-version=latest: Define que la versión más reciente del nivel restricted será usada para generar los avisos.

  • pod-security.kubernetes.io/audit=restricted: Aplica el nivel de seguridad restricted en modo de auditoría (audit). Cuando un pod es creado o modificado y viola las reglas del nivel "restricted", esto será registrado en los logs de auditoría de Kubernetes, permitiendo rastrear eventos sin bloquear o avisar al usuario.

  • pod-security.kubernetes.io/audit-version=latest: Usa la versión más reciente del nivel restricted para la auditoría. Objetivo de la Configuración:

Si aplicas los Pod Security Standards (PSS) en un namespace que ya posee pods en ejecución, el comportamiento depende de la label que utilices y del estado actual de los pods.

  • Los pods que ya están en ejecución no serán afectados inmediatamente por las reglas de seguridad, pues el PSS es verificado apenas durante la creación o alteración de los pods. Si los pods no son reiniciados o recreados, continuarán ejecutando normalmente, aun que no estén en conformidad con las nuevas reglas del PSS.

  • Nuevos pods o pods recreados serán bloqueados caso no atiendan las reglas.

Si intentas crear nuevos pods o recrear (por ejemplo, en un escenario de rollout o upgrade de deployment) y no están en conformidad con el nivel de seguridad definido (como "baseline" o "restricted"), Kubernetes irá a impedir la creación de esos pods. Esto también afecta pods que pasan por eventos de reschedule (como fallas de nodo o mantenimientos) o pods que hacen parte de workloads como Deployments o StatefulSets. Ajustes necesarios:

Antes de aplicar una política de seguridad más restringida, como "restricted", es recomendable revisar y adaptar tus pods para garantizar que cumplan las nuevas reglas.