Saltar a contenido

Admission Policies

Pod Security Standards (PSS) y Pod Security Admission (PSA)

La regla de oro para no confundirlos es esta: PSS es el "Qué" (las reglas escritas) y PSA es el "Cómo" (el policía que hace cumplir esas reglas).

Pod Security Standards (PSS) - Las Reglas

Son tres (3) perfiles o niveles de seguridad definidos oficialmente por Kubernetes. Dictan qué características de seguridad puede o no puede tener un Pod (ej. si puede ser root, si puede usar la red del host, etc.).

  • 🟢 Privileged (Privilegiado): Sin restricciones. Permite todo. Se usa únicamente para Pods del sistema o de infraestructura (como plugins de red o CSI drivers) que necesitan acceso profundo al Nodo.

  • 🟡 Baseline (Base): La política por defecto. Permite configuraciones estándar pero bloquea escaladas de privilegios conocidas. Es ideal para aplicaciones de negocio comunes.

  • 🔴 Restricted (Restringido): Máxima seguridad. Obliga a seguir las mejores prácticas actuales de endurecimiento (hardening). Por ejemplo, los Pods deben ejecutarse como usuarios no-root y deben descartar capacidades (capabilities) del kernel.

Pod Security Admission (PSA) - El Policía

Es un Admission Controller (Controlador de Admisión) nativo que viene activado por defecto. Su trabajo es interceptar las peticiones de creación de Pods y verificar si cumplen con el perfil PSS que hayas configurado.

El PSA evalúa los Pods a nivel de Namespace basándose en etiquetas (labels). Para cada perfil (Privileged, Baseline, Restricted), el PSA puede actuar en tres Modos:

  • ⛔ Enforce (Forzar): Si el Pod viola la regla, la creación es rechazada (bloqueada).

  • ⚠️ Warn (Advertir): El Pod se crea, pero el usuario que ejecutó el comando recibe un mensaje de advertencia en su consola.

  • 📝 Audit (Auditar): El Pod se crea silenciosamente, pero se registra una alerta en los logs de auditoría (audit logs) del kube-apiserver para revisión de seguridad.

[!NOTE] 

# Ver todos los eventos del namespace, aquí verás el rechazo del ReplicaSet
kubectl get events -n finance-app 

# O, la forma más rápida y directa en un examen:
kubectl describe replicaset <nombre-del-replicaset> -n finance-app

Implementación Práctica (Modo Examen CKS)

En el examen, te pedirán que asegures un Namespace específico usando PSS/PSA. No tienes que crear YAMLs complejos, todo se hace etiquetando el Namespace.

La sintaxis de la etiqueta siempre es: pod-security.kubernetes.io/<MODO>=<PERFIL>

Ejemplo 1: Bloquear Pods inseguros en el namespace "produccion"

# Etiquetar el namespace para que RECHACE (enforce) cualquier pod que no cumpla el nivel MAXIMO (restricted)
kubectl label namespace produccion pod-security.kubernetes.io/enforce=restricted

Ejemplo 2: Auditoría y Advertencias para migraciones

A veces no quieres romper la aplicación de golpe, solo quieres saber qué fallaría:

# Permite que los pods funcionen, pero advierte y audita si no cumplen con 'baseline'
kubectl label namespace desarrollo pod-security.kubernetes.io/warn=baseline
kubectl label namespace desarrollo pod-security.kubernetes.io/audit=baseline

Escenario Práctico de Laboratorio (Tu turno)

Vamos a poner a prueba tu conocimiento con un escenario típico de examen:

1. Problema:

El equipo de seguridad ha detectado que en el namespace finance-app, los desarrolladores están desplegando Pods que corren como root.

2. Objetivo:

Debes configurar el namespace finance-app para que bloquee inmediatamente cualquier nuevo Pod que no cumpla con las políticas de máxima seguridad de Kubernetes. Además, quieres que si alguien intenta desplegar algo que viole el nivel de seguridad "baseline", se le muestre una advertencia en consola (pero la política de bloqueo principal sigue mandando).

3. Restricciones:

  • Debes usar comandos imperativos.
  • No modifiques ningún Pod existente, actúa solo sobre el Namespace.

Kyverno

Kyverno es un motor de políticas nativo de Kubernetes que permite validar, mutar y generar configuraciones de forma muy sencilla, utilizando YAML sin necesidad de aprender lenguajes complejos (como pasa con OPA/Rego).

Laboratorio

Objetivo del Laboratorio

  1. Instalar Kyverno en un clúster local.
  2. Crear una política de Validación (Evitar que se desplieguen Pods sin una etiqueta obligatoria).
  3. Comprobar que Kyverno bloquea los recursos mal configurados y permite los correctos.

Requisitos Previos

Para este laboratorio necesitarás tener instalados en tu máquina:

  • kubectl (para interactuar con el clúster).
  • Helm (el gestor de paquetes de Kubernetes).

Paso 1: Instalar Kyverno

# Agrega el repositorio de Helm de Kyverno e instálalo:
helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update

# Instalamos Kyverno en su propio namespace
helm install kyverno kyverno/kyverno --values k8s-lab/kyverno/values.yaml -n kyverno --create-namespace

# Verifica que Kyverno esté corriendo:
kubectl get pods -n kyverno
# (Espera a que los pods de kyverno estén en estado Running antes de continuar).

Paso 2: Crear una Política de Validación (ClusterPolicy)

Vamos a crear una regla estricta: "Ningún Pod puede ser creado en el clúster si no tiene la etiqueta (label) team asignada".

Crea un archivo llamado require-team-label.yaml con el siguiente contenido:

apiVersion: policies.kyverno.io/v1alpha1
kind: ValidatingPolicy
metadata:
  name: require-labels
spec:
  validationActions:
    - Deny
  matchConstraints:
    resourceRules:
      - apiGroups: ['']
        apiVersions: ['v1']
        operations: ['CREATE', 'UPDATE']
        resources: ['pods']
  validations:
    - message: "label 'team' is required"
      expression: "has(object.metadata.labels) && has(object.metadata.labels.team) && object.metadata.labels.team != ''"

kubectl apply -f require-team-label.yaml

# Verifica que la política está activa:
kubectl get clusterpolicy

Paso 3: Poner a Prueba la Política

Ahora vamos a actuar como un desarrollador intentando desplegar aplicaciones.

  • Prueba 1: Intento fallido (Sin la etiqueta requerida)

    Intenta crear un Pod básico de Nginx sin especificar ninguna etiqueta:

    kubectl create deployment nginx --image=nginx

    Resultado esperado: Kyverno interceptará la petición y te arrojará un error en la consola:

    error: failed to create deployment: admission webhook "vpol.validate.kyverno.svc-fail" denied the request: Policy require-labels failed: label 'team' is required

  • Prueba 2: Intento exitoso (Cumpliendo la regla)

    Ahora, vamos a crear el Pod pero añadiendo la etiqueta obligatoria team:

    kubectl run nginx --image nginx --labels team=backend

    Resultado esperado: pod/pod-bueno created

    Puedes verificar que el Pod se está ejecutando:

    kubectl get pods --show-labels

Paso 4 (Opcional): Explorar los Reportes de Políticas

Si en el Paso 2 hubiéramos puesto validationFailureAction: Audit en lugar de Deny, Kyverno habría dejado crear el "pod-malo", pero habría generado un reporte de violación de política. Puedes ver estos reportes (Policy Reports) con el comando:

kubectl get policyreports -A

¿Qué más puedes hacer con Kyverno? (Para futuros laboratorios)

Una vez domines este laboratorio básico, te recomiendo probar:

  1. Mutación (Mutation): Crear una política que en lugar de bloquear, añada automáticamente etiquetas, inyecte sidecars o modifique variables de entorno en los Pods que se desplieguen.

  2. Generación (Generation): Crear una política que genere automáticamente secretos o configmaps por defecto cada vez que alguien cree un Namespace nuevo.

  3. Restringir imágenes seguras: Bloquear imágenes que usen la etiqueta :latest para forzar a los desarrolladores a usar versiones específicas.