Kubernetes Pod Security: Standards, Admission y securityContext

Kubernetes Pod Security es la disciplina de restringir lo que cada pod tiene permitido hacer, de modo que un punto de apoyo dentro de un container no le entregue el node entero a un atacante. Es la capa donde la mayor parte del hardening real de clusters ocurre o, en silencio, deja de ocurrir — y, desde la eliminación de la PodSecurityPolicy, se sustenta en tres piezas móviles que necesitas entender en conjunto: los Pod Security Standards, el Pod Security Admission y el securityContext a nivel de pod. Esta guía recorre las tres, muestra los ajustes que importan y explica cómo adoptarlos sin romper las cargas de trabajo que ya ejecutas.

Este artículo forma parte de nuestro cluster de Kubernetes security. Si aún no has protegido el acceso y el tráfico, combínalo con nuestras guías sobre Kubernetes RBAC y Kubernetes network policies.

Por qué importa la seguridad a nivel de pod

Los containers comparten un kernel. Esa sola frase explica por qué la seguridad de pods tiene tanto peso. A diferencia de las máquinas virtuales, los containers en el mismo node están aislados por primitivas del kernel — namespaces, cgroups, capabilities, seccomp — y no por una frontera de hypervisor. Cuando a un pod se le concede más privilegio del que necesita, estás ampliando el radio de impacto de cualquier bug en tu aplicación o en sus dependencias.

La cadena de fallo clásica se ve así: un atacante explota una vulnerabilidad en un servicio expuesto a la web y obtiene ejecución de código dentro del container. Si ese container se ejecuta como root, tiene capabilities adicionales de Linux o monta un host path, el escape del container al node suele ser trivial. Desde el node, un atacante puede leer los secrets de todos los demás pods, manipular el kubelet o desplazarse lateralmente por el cluster. Un escape de container, en otras palabras, con frecuencia es un compromiso de node — y un node comprometido está a un paso muy corto de un cluster comprometido.

La seguridad de pods es la forma en que haces que ese paso sea largo y difícil. El objetivo no es confiar menos en el código de tu aplicación; es asumir que tarde o temprano será comprometido y asegurar que el compromiso quede contenido.

De la PodSecurityPolicy a los Pod Security Standards

Durante años, la respuesta al hardening de pods fue la PodSecurityPolicy (PSP) — un recurso de alcance de cluster que controlaba la creación de pods contra un conjunto de reglas. La PSP era potente, pero notoriamente incómoda: su modelo de autorización era confuso, el orden entre múltiples políticas no era evidente y era fácil dejarte fuera a ti mismo (o a tus cargas de trabajo).

La PSP quedó obsoleta en Kubernetes 1.21 y se eliminó por completo en la 1.25. Si todavía tienes objetos PSP dando vueltas, no hacen nada en los clusters modernos. El reemplazo es deliberadamente más simple y se divide en dos conceptos: un conjunto de perfiles estándar (los Pod Security Standards) y un mecanismo nativo de aplicación (el Pod Security Admission). Los Standards describen cómo se ve lo correcto; el Admission decide si permitir, advertir o auditar un pod frente a un Standard elegido.

Los tres niveles de los Pod Security Standards

Los Pod Security Standards definen tres niveles acumulativos, del más permisivo al más restringido:

• Privileged — esencialmente sin restricciones. Este nivel permite escaladas de privilegio conocidas y está pensado para cargas de trabajo confiables, de estilo infraestructura (piensa en componentes de sistema o un plugin CNI) que realmente necesitan acceso amplio. Los namespaces de aplicación casi nunca deberían ejecutarse aquí.
• Baseline — un perfil mínimamente restrictivo que bloquea las escaladas más obvias y peligrosas y, a la vez, resulta fácil de adoptar. Prohíbe cosas como host namespaces, containers privileged y volúmenes hostPath, pero todavía permite ejecutar como root. El baseline es un piso sensato para la mayoría de los namespaces de aplicación.
• Restricted — el perfil endurecido. Aplica las mejores prácticas actuales de hardening de pods: ejecutar como no-root, eliminar todas las capabilities, deshabilitar la escalada de privilegios y exigir un seccomp profile, entre otras. Este es el objetivo para cualquier cosa que maneje datos sensibles o quede expuesta a entradas no confiables.

El modelo mental es una escalera: todo lo que bloquea el baseline también lo bloquea el restricted, y mucho más. Eliges el nivel más alto que una carga de trabajo pueda tolerar.

Cómo aplica el Pod Security Admission por namespace

El Pod Security Admission (PSA) es el admission controller — habilitado por defecto en el Kubernetes actual — que aplica un Standard elegido a un namespace. Lo configuras no con un objeto de política, sino con etiquetas en el propio namespace. Hay tres modos:

• `enforce` — los pods que violan el nivel son rechazados en el momento de la creación.
• `audit` — las violaciones se permiten, pero se registran en el log de auditoría.
• `warn` — las violaciones se permiten, pero devuelven una advertencia al usuario que creó el pod.

Cada modo recibe un nivel (privileged, baseline o restricted) y, opcionalmente, una versión fijada. Un namespace puede llevar los tres a la vez, que es exactamente la forma de adoptarlos con seguridad — advertir y auditar en restricted mientras solo se aplica baseline, por ejemplo.

apiVersion: v1

kind: Namespace

metadata:

  name: payments

  labels:

    pod-security.kubernetes.io/enforce: baseline

    pod-security.kubernetes.io/enforce-version: latest

    pod-security.kubernetes.io/audit: restricted

    pod-security.kubernetes.io/warn: restricted

Ese único conjunto de etiquetas bloquea de inmediato los peores comportamientos (enforce: baseline), a la vez que te indica, en cada deploy, exactamente qué necesitarías corregir para alcanzar restricted. Ten en cuenta que el PSA trabaja con granularidad de namespace — no hay exención por pod dentro de un namespace con enforcement, así que diseña la disposición de tus namespaces pensando en niveles de seguridad.

Los ajustes de securityContext que de verdad endurecen un pod

Los Standards y el Admission deciden qué reglas se aplican. El securityContext es donde escribes las reglas en tus manifests. Estos son los ajustes que tienen más peso:

spec:

  securityContext:

    runAsNonRoot: true

    seccompProfile:

      type: RuntimeDefault

  containers:

    - name: app

      image: registry.example.com/app:1.4.2

      securityContext:

        allowPrivilegeEscalation: false

        readOnlyRootFilesystem: true

        privileged: false

        capabilities:

          drop: ["ALL"]

• `runAsNonRoot: true` (y un runAsUser concreto) evita que el container se ejecute como UID 0. Esto por sí solo derrota una gran categoría de escapes.
• `allowPrivilegeEscalation: false` impide que un proceso obtenga más privilegios que su padre — por ejemplo, mediante binarios setuid.
• `readOnlyRootFilesystem: true` hace inmutable el sistema de archivos raíz del container, de modo que un atacante no pueda soltar un payload ni modificar binarios. Monta un emptyDir para las pocas rutas que genuinamente necesitan ser escribibles.
• `capabilities.drop: ["ALL"]` elimina todas las capabilities de Linux y te obliga a volver a agregar solo lo que realmente necesitas (rara vez algo).
• `seccompProfile.type: RuntimeDefault` aplica el filtro seccomp por defecto del runtime de container, bloqueando syscalls peligrosas.
• `privileged: false` — un container privileged es efectivamente root en el node. Casi nunca hay una buena razón para que una aplicación se ejecute en modo privileged.

Igual de importantes son las cosas que no debes definir. Evita `hostNetwork`, `hostPID` y `hostIPC`, que rompen el aislamiento entre el pod y el node. Evita los volúmenes `hostPath`, que montan directorios del node directamente dentro del pod. Estos son precisamente los comportamientos que los niveles baseline y restricted existen para bloquear.

Los límites de recursos son parte de la seguridad de pods

La seguridad no se trata solo de privilegio — la disponibilidad también cuenta. Un pod sin límites puede consumir toda la CPU o la memoria de un node y dejar sin recursos a sus vecinos, lo cual es una condición de denegación de servicio, ya sea que ocurra por accidente o por malicia. Define siempre requests y limits:

resources:

  requests:

    cpu: "100m"

    memory: "128Mi"

  limits:

    cpu: "500m"

    memory: "256Mi"

Combínalos con un LimitRange y un ResourceQuota por namespace, para que incluso las cargas de trabajo olvidadas hereden límites sensatos.

Cuándo necesitas un admission controller más allá del PSA

El Pod Security Admission tiene un alcance intencionalmente acotado: aplica los tres Standards y nada más. Eso cubre muchísimo, pero no puede expresar reglas específicas de la organización. El PSA no puede, por ejemplo, exigir que las imágenes provengan solo de tu registry, imponer una etiqueta determinada, prohibir el tag latest o bloquear una ruta de mount específica mientras permite otras.

Cuando necesitas ese tipo de política personalizada, recurres a un motor de políticas de propósito general que se conecta a Kubernetes como un validating admission webhook. Los motores de policy-as-code te permiten escribir reglas en un lenguaje de política dedicado, probarlas y versionarlas junto con el resto de tu infraestructura. El patrón es dejar que el PSA se encargue del enforcement estándar de baseline/restricted y agregar un motor de políticas por encima para todo lo que es único de tu entorno. Mantén ambos complementarios, en lugar de duplicar los Standards en políticas personalizadas.

Cómo desplegarlo sin romper tus cargas de trabajo

La forma más rápida de perder la confianza de tu equipo es cambiar un namespace a enforce: restricted y ver cómo fallan la mitad de los deployments. Adóptalo por etapas, en cambio:

1. Observa primero. Agrega las etiquetas warn: restricted y audit: restricted a un namespace sin ninguna etiqueta enforce. Nada se rompe; simplemente recopilas una lista de todas las violaciones que tus cargas de trabajo disparan actualmente.
2. Corrige los manifests. Repasa las advertencias y agrega los campos de securityContext anteriores. La mayoría de las correcciones son pequeñas y mecánicas.
3. Aplica el piso. Una vez que las cargas de trabajo estén limpias, define enforce: baseline y luego elévalo a enforce: restricted en los namespaces que puedan soportarlo.
4. Define el valor por defecto de los nuevos namespaces. Configura un valor por defecto en todo el cluster para que los nuevos namespaces comiencen al menos en baseline, y no completamente abiertos.

Este enfoque de "auditar primero" hace que el interruptor de enforcement sea una formalidad para cuando lo accionas — las cargas de trabajo ya cumplen.

Shift left: escanea los manifests en el CI

Todo lo anterior ocurre en la frontera del cluster. El lugar más barato para detectar un pod mal configurado es mucho antes de que llegue a un cluster — en el pull request que lo introduce. Los manifests, los Helm charts y los overlays de Kustomize son código, y se pueden escanear como código.

Conectar las comprobaciones de seguridad de pods al CI significa que un manifest que se ejecuta como root, monta un hostPath u olvida los límites de recursos hace fallar el build con un mensaje claro que apunta a la línea infractora. Los desarrolladores reciben feedback en segundos, en la herramienta que ya usan, en lugar de descubrir el problema cuando un deploy es rechazado — o peor, cuando no lo es. Este es el mismo principio de shift left que aplicamos a lo largo del resto del ciclo de vida de Kubernetes security.

Cómo ayuda Rainforest

Rainforest lleva el enforcement de seguridad de pods al flujo de trabajo del desarrollador, en lugar de añadirlo al final. Nuestro escaneo de infraestructura como código analiza tus manifests de Kubernetes, Helm charts y Terraform exactamente en busca de los problemas que cubre este artículo — containers ejecutándose como root, campos de securityContext ausentes, host namespaces, flags de privileged y límites de recursos inexistentes — y los expone directamente en los pull requests. Nuestro escaneo de seguridad de containers extiende esa cobertura a las imágenes que ejecutan esos pods, para que una spec de pod endurecida no quede socavada por una imagen base vulnerable.

El resultado es una imagen única y coherente: comprobaciones de política en el CI que reflejan lo que el Pod Security Admission aplicará en el cluster, de modo que las configuraciones incorrectas se detectan mientras todavía son un cambio de código y aún no un incidente.

Si quieres ver cómo encaja esto en tu pipeline, agenda una demostración y repasaremos tus propios manifests.