Kubernetes DevSecOps: cómo automatizar el cumplimiento de SOC 2, ISO 27001 y CIS Benchmarks

Un auditor no te va a preguntar si tu clúster de Kubernetes es seguro. Te va a pedir que demuestres que un control existía, que funcionó durante todo el periodo auditado y que cada desviación fue aprobada. Un clúster bien endurecido pero sin registros no supera esa prueba.

Esta guía trata de generar esos registros desde el propio clúster. La seguridad de las cargas de trabajo en producción está en nuestra guía de DevSecOps para Kubernetes. Aquí verás una línea base del CIS Benchmark que puedes ejecutar hoy, reglas de admisión que escriben sus propios informes, excepciones con responsable y fecha de caducidad, y un almacén de evidencias mapeado a SOC 2 e ISO 27001.

Qué muestrea realmente un auditor

Sea cual sea el marco, cada control del clúster tiene que producir tres cosas:

• Una definición. La regla, escrita y versionada: un fichero de política en Git, integrado tras revisión.
• Prueba de que funcionó. Registros fechados que demuestren que la regla se aplicó durante todo el periodo, no solo el día de la auditoría: resultados de escaneos, informes, entradas de log.
• Un registro de excepciones. Cada sitio donde la regla no se aplica, con quién lo aprobó, por qué y hasta cuándo.

En un informe SOC 2 Tipo II, el auditor elige fechas de toda la ventana de observación y pide la evidencia de cada una, así que los registros tienen que generarse de forma programada y guardarse donde nadie pueda editarlos sin que se note. Nuestro playbook de SOC 2 para startups cubre el alcance y los controles organizativos; esto es la parte del clúster.

Paso 1: ejecuta hoy un escaneo del CIS Benchmark

El CIS Kubernetes Benchmark es una línea base de hardening, no una certificación: un estándar de configuración publicado que puedes citar en tu política de seguridad. kube-bench, un escáner open source, comprueba tus nodos contra él.

kube-bench lee ficheros del host e inspecciona sus procesos, algo que el nivel baseline de Pod Security prohíbe. Dale su propio namespace:

apiVersion: v1
kind: Namespace
metadata:
  name: compliance-scans
  labels:
    # kube-bench reads host files and processes, which baseline forbids.
    # Record this namespace as an exception, with the reason, in your register.
    pod-security.kubernetes.io/enforce: privileged
    pod-security.kubernetes.io/warn: baseline

Esa etiqueta es tu primera excepción. Ahora el Job:

apiVersion: batch/v1
kind: Job
metadata:
  name: kube-bench-node
  namespace: compliance-scans
spec:
  backoffLimit: 0
  template:
    spec:
      hostPID: true
      restartPolicy: Never
      containers:
        - name: kube-bench
          # Mirror the official kube-bench image into your registry and pin the release
          image: registry.example.com/mirror/kube-bench:v0.16.0
          command: ["kube-bench", "run", "--targets", "node"]
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              memory: 256Mi
          volumeMounts:
            - name: var-lib-kubelet
              mountPath: /var/lib/kubelet
              readOnly: true
            - name: etc-systemd
              mountPath: /etc/systemd
              readOnly: true
            - name: lib-systemd
              mountPath: /lib/systemd
              readOnly: true
            - name: etc-kubernetes
              mountPath: /etc/kubernetes
              readOnly: true
            - name: usr-bin
              mountPath: /usr/local/mount-from-host/bin
              readOnly: true
      volumes:
        - name: var-lib-kubelet
          hostPath:
            path: /var/lib/kubelet
        - name: etc-systemd
          hostPath:
            path: /etc/systemd
        - name: lib-systemd
          hostPath:
            path: /lib/systemd
        - name: etc-kubernetes
          hostPath:
            path: /etc/kubernetes
        - name: usr-bin
          hostPath:
            path: /usr/bin

Ejecútalo y guarda la salida:

kubectl apply -f compliance-scans-namespace.yaml -f kube-bench-node.yaml
kubectl -n compliance-scans wait --for=condition=complete job/kube-bench-node --timeout=5m
kubectl -n compliance-scans logs job/kube-bench-node > "kube-bench-$(date -u +%F).txt"
grep -E '^\[(FAIL|WARN)\]' "kube-bench-$(date -u +%F).txt"

Un Job solo escanea el nodo en el que cae, así que añade un nodeSelector, ejecuta uno por node pool y borra el Job terminado antes de la siguiente ejecución. En un servicio gestionado, parte de la variante del Job para tu proveedor que incluye el repositorio de kube-bench; monta las rutas que usan esos nodos. kube-bench elige el benchmark según tu versión de Kubernetes y, si no la conoce, recurre al más reciente que tenga; pasa --benchmark para evaluar cada ejecución contra el mismo documento, y --json cuando la salida vaya a tu almacén de evidencias.

Cómo leer los resultados

Cada comprobación imprime una línea, con este formato:

[PASS] 4.2.1 Ensure that the --anonymous-auth argument is set to false (Automated)
[FAIL] 4.2.6 Ensure that the --make-iptables-util-chains argument is set to true (Automated)
[WARN] 4.2.13 Ensure that a limit is set on pod PIDs (Manual)

• FAIL significa que una comprobación automatizada se ejecutó y el nodo no cumple. Cada una se convierte en un ticket o en una aceptación de riesgo por escrito.
• WARN no significa que pase. kube-bench informa como WARN de todas las comprobaciones Manual y de las no puntuadas que no pudo confirmar. Alguien tiene que revisar cada una y dejar constancia de la respuesta.
• La sección de remediación da la corrección de cada FAIL y WARN. Aplica las correcciones del kubelet en la imagen de nodo o en la configuración del node pool; un cambio hecho en un nodo en marcha se pierde cuando se reemplaza el nodo.

Los identificadores de las comprobaciones cambian entre versiones del benchmark, así que guarda la versión junto a cada resultado.

Lo que no te toca en un control plane gestionado

En un servicio gestionado, el control plane se ejecuta en máquinas del proveedor, fuera de tu alcance. Los CIS Benchmarks para servicios gestionados reducen sus capítulos a poco más que activar los logs de auditoría, y añaden un capítulo para los ajustes que controlas a través de la API del proveedor.

• Responsabilidad del proveedor: flags y permisos de ficheros de los componentes del control plane, configuración y cifrado de etcd, parches del control plane. Tu evidencia aquí es el propio informe de auditoría o certificación del proveedor, archivado en la gestión de proveedores.
• Sigue siendo tuyo: la configuración de los worker nodes (a través de la imagen de nodo y los ajustes del node pool), si los logs de auditoría del control plane están activos y adónde van, el acceso de red al endpoint de la API, el cifrado de los Secrets con una clave que gestionas tú, las identidades cloud que usan nodos y cargas de trabajo, y qué registries de imágenes están aprobados.

Si esos ajustes viven en Terraform, el código y su historial de revisión son la definición y el registro de cambios. En un clúster autogestionado, ejecuta además un Job en un nodo del control plane con los targets master, controlplane y etcd; el repositorio también incluye esa variante.

Paso 2: Pod Security Admission, sin instalar nada

Pod Security Admission viene integrado en Kubernetes y es estable desde la 1.25. Aplica los niveles de los Pod Security Standards (privileged, baseline, restricted) por namespace, mediante etiquetas, en tres modos: enforce rechaza, audit registra y warn avisa a quien aplica el manifiesto.

Un punto de partida sensato es aplicar baseline y auditar y avisar en restricted:

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/audit-version: latest
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: latest

Antes de etiquetar namespaces de producción, un dry run en el servidor avisa de los pods existentes que violarían el nivel, sin cambiar nada:

kubectl label --dry-run=server --overwrite ns --all \
  pod-security.kubernetes.io/enforce=baseline

Dos detalles pillan a muchos equipos:

• Enforce comprueba pods, no cargas de trabajo. Un Deployment que viola el nivel aplicado se acepta; después su ReplicaSet no consigue crear pods y el único rastro es un evento FailedCreate. Los modos warn y audit sí comprueban los recursos de carga de trabajo, y por eso se configuran junto a enforce.
• El modo audit escribe en el log de auditoría del API server, como anotación de la petición (pod-security.kubernetes.io/audit-violations). Si el log de auditoría está desactivado, el modo audit no registra nada.

Lo que Pod Security Admission no puede hacer es comprobar nada fuera de los Pod Security Standards, producir un informe exportable o conceder una excepción más estrecha que un namespace. Para eso hace falta un motor de políticas.

¿Quieres comprobarlo en tus propios clústeres? En una evaluación gratuita de cumplimiento en Kubernetes ejecutamos el escaneo CIS contigo, revisamos las etiquetas de tus namespaces y tus políticas de admisión, y separamos los hallazgos que son tuyos de los que corresponden a tu proveedor.

Paso 3: políticas como código con Kyverno

Kyverno es un motor de políticas open source que funciona como webhook de admisión. Además, vuelve a escanear en segundo plano los recursos existentes y escribe objetos PolicyReport: la prueba de funcionamiento que pide un auditor.

Una nota de versión: desde Kyverno 1.19, el veterano tipo ClusterPolicy está obsoleto y aplicar uno devuelve un aviso. Su sustituto, ValidatingPolicy, se escribe en CEL, el lenguaje de expresiones de las políticas de admisión integradas en Kubernetes. Los ejemplos de abajo se probaron con el CLI de Kyverno 1.19.2.

Ojo también con el alcance: por defecto, el Helm chart hace que Kyverno ignore kube-system, kube-public, kube-node-lease y su propio namespace. Si no lo cambias, anota esos namespaces en tu mapeo de controles como excluidos, con el motivo: un auditor preguntará qué namespaces no cubre cada control.

Prohibir contenedores privilegiados

El nivel baseline de Pod Security ya los bloquea en los namespaces etiquetados. Repetir la regla en Kyverno cubre además los namespaces sin etiquetas o etiquetados como privileged, genera una entrada de informe por carga de trabajo y te permite eximir una sola imagen en lugar de un namespace. También detecta las sesiones de kubectl debug, ya que añaden contenedores efímeros a pods en marcha.

apiVersion: policies.kyverno.io/v1
kind: ValidatingPolicy
metadata:
  name: disallow-privileged-containers
spec:
  validationActions: [Audit, Warn]
  evaluation:
    background:
      enabled: true
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
      - apiGroups: ["apps"]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["deployments", "statefulsets", "daemonsets"]
      - apiGroups: ["batch"]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["jobs", "cronjobs"]
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["UPDATE"]
        resources: ["pods/ephemeralcontainers"]
  variables:
    - name: podSpec
      expression: >-
        object.spec.?jobTemplate.?spec.?template.?spec.orValue(
        object.spec.?template.?spec.orValue(object.spec))
    - name: allContainers
      expression: >-
        variables.podSpec.containers +
        variables.podSpec.?initContainers.orValue([]) +
        variables.podSpec.?ephemeralContainers.orValue([])
  validations:
    - expression: >-
        variables.allContainers.all(c,
        (has(exceptions.allowedImages) && c.image in exceptions.allowedImages) ||
        !c.?securityContext.?privileged.orValue(false))
      message: "Privileged containers are not allowed. Remove securityContext.privileged or request an exception."

Cada política cubre los recursos de carga de trabajo además de los pods: una política solo para pods en modo Deny acepta el Deployment y rechaza sus pods en silencio, la misma trampa que el modo enforce de Pod Security.

Exigir requests y limits

apiVersion: policies.kyverno.io/v1
kind: ValidatingPolicy
metadata:
  name: require-requests-limits
spec:
  validationActions: [Audit, Warn]
  evaluation:
    background:
      enabled: true
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
      - apiGroups: ["apps"]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["deployments", "statefulsets", "daemonsets"]
      - apiGroups: ["batch"]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["jobs", "cronjobs"]
  variables:
    - name: podSpec
      expression: >-
        object.spec.?jobTemplate.?spec.?template.?spec.orValue(
        object.spec.?template.?spec.orValue(object.spec))
  validations:
    - expression: >-
        variables.podSpec.containers.all(c,
        c.?resources.?requests.?cpu.hasValue() &&
        c.?resources.?requests.?memory.hasValue() &&
        c.?resources.?limits.?memory.hasValue())
      message: "Every container needs CPU and memory requests and a memory limit."

Restringir las imágenes a un registry aprobado

apiVersion: policies.kyverno.io/v1
kind: ValidatingPolicy
metadata:
  name: restrict-image-registries
spec:
  validationActions: [Audit, Warn]
  evaluation:
    background:
      enabled: true
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
      - apiGroups: ["apps"]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["deployments", "statefulsets", "daemonsets"]
      - apiGroups: ["batch"]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["jobs", "cronjobs"]
  variables:
    - name: podSpec
      expression: >-
        object.spec.?jobTemplate.?spec.?template.?spec.orValue(
        object.spec.?template.?spec.orValue(object.spec))
    - name: allContainers
      expression: >-
        variables.podSpec.containers +
        variables.podSpec.?initContainers.orValue([]) +
        variables.podSpec.?ephemeralContainers.orValue([])
  validations:
    - expression: >-
        variables.allContainers.all(c,
        c.image.startsWith('registry.example.com/'))
      message: "Images must come from registry.example.com. Mirror third-party images there first."

Si las imágenes de terceros se replican en tu registry y se escanean allí, esta política hace obligatoria esa convención. El Job de kube-bench de arriba cumple las tres políticas.

Primero auditar, después bloquear

Las tres políticas empiezan con validationActions: [Audit, Warn]: las infracciones van a los informes y quien aplica un manifiesto no conforme ve un aviso, pero no se bloquea nada. Cuando el informe de una política no muestre fallos fuera de las excepciones registradas, cámbiala a [Deny] mediante un merge request revisado, que además sirve como registro del cambio. Cambia una política cada vez.

Ejecuta las mismas políticas en CI para que los desarrolladores se enteren antes. Esto termina con un código distinto de cero cuando un manifiesto falla, y carga los ficheros de excepciones (siguiente apartado) para que las cargas de trabajo aprobadas no rompan el build:

kyverno apply policies/ --resource manifests/ \
  --exception "$(find exceptions -name '*.yaml' | paste -sd, -)"

Nuestra guía sobre un pipeline de CI/CD seguro con GitOps muestra dónde encaja esa puerta.

Excepciones, registradas

Algunas cargas de trabajo necesitan de verdad lo que una política prohíbe: los drivers de almacenamiento y de red suelen ejecutarse como privilegiados. Las excepciones vienen desactivadas por defecto en el Helm chart de Kyverno. Actívalas para un único namespace, de modo que crear una sea un permiso que concedes a propósito:

# values.yaml for the Kyverno Helm chart
features:
  policyExceptions:
    enabled: true
    namespace: policy-exceptions

Cada excepción es entonces un fichero revisado en Git:

apiVersion: policies.kyverno.io/v1
kind: PolicyException
metadata:
  name: csi-node-driver-privileged
  namespace: policy-exceptions
spec:
  policyRefs:
    - name: disallow-privileged-containers
      kind: ValidatingPolicy
  # Exact image reference: a new driver version needs a new approval
  images:
    - registry.example.com/mirror/csi-node-driver:2.1.0
  expiresAt: "2027-04-30T00:00:00Z"
  properties:
    reason: "Storage driver mounts volumes on the host; needs privileged mode"
    ticket: "SEC-142"
    approved-by: "head-of-engineering"

La lista images exige coincidencia exacta, así que actualizar el driver requiere una nueva aprobación. expiresAt y properties llegaron con Kyverno 1.19: pasada la fecha, la excepción deja de aplicarse, y el motivo, el ticket y quien la aprobó viajan con ella en cada exportación.

Paso 4: convierte informes y logs en evidencias

Los informes de políticas muestran el estado actual: cuando se corrige una infracción, desaparece también el registro de que existió. Los eventos de Kubernetes caducan, por defecto al cabo de una hora. Ninguno de los dos es historial, así que haz snapshots de forma programada.

El log de auditoría del API server

El log de auditoría registra quién cambió qué, incluida cada petición que el control de admisión denegó. En un clúster autogestionado, la política de auditoría la escribes tú:

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
  - "RequestReceived"
rules:
  # Secrets: record who touched them, never their content
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets"]
  # RBAC and admission policy changes: the full request and response
  - level: RequestResponse
    resources:
      - group: "rbac.authorization.k8s.io"
      - group: "policies.kyverno.io"
  # Interactive access to running containers
  - level: Metadata
    resources:
      - group: ""
        resources: ["pods/exec", "pods/attach", "pods/portforward"]
  # Every other change, including admission denials
  - level: Metadata
    verbs: ["create", "update", "patch", "delete", "deletecollection"]

En un servicio gestionado, normalmente activas los logs de auditoría del control plane y eliges adónde van. Hazlo el primer día: un periodo de auditoría no puede empezar antes que sus logs.

Una exportación diaria

Ejecuta esto desde un job de CI programado o desde un CronJob con acceso de solo lectura:

#!/usr/bin/env bash
set -euo pipefail
OUT="evidence/$(date -u +%F)"
mkdir -p "$OUT"

# What is enforced, and every approved exception
kubectl get validatingpolicies.policies.kyverno.io -o yaml > "$OUT/policies.yaml"
kubectl get policyexceptions.policies.kyverno.io -A -o yaml > "$OUT/exceptions.yaml"
kubectl get namespaces -L pod-security.kubernetes.io/enforce,pod-security.kubernetes.io/audit,pod-security.kubernetes.io/warn > "$OUT/psa-labels.txt"

# Policy results as they stand today
kubectl get policyreports -A -o json > "$OUT/policyreports.json"
kubectl get clusterpolicyreports -o json > "$OUT/clusterpolicyreports.json"

# One line per namespace: failures and passes
jq -r '.items | group_by(.metadata.namespace)[]
  | [.[0].metadata.namespace, (map(.summary.fail // 0) | add), (map(.summary.pass // 0) | add)]
  | @tsv' "$OUT/policyreports.json" > "$OUT/summary-by-namespace.tsv"

# Fingerprint the snapshot before it leaves the cluster
(cd "$OUT" && sha256sum -- * > SHA256SUMS)

Añade el JSON de kube-bench de cada escaneo y la exportación de los bindings de RBAC que describe el playbook de SOC 2. Después fija la cadencia:

• Informes de políticas, excepciones y etiquetas de namespaces: a diario.
• kube-bench: cada semana, y después de cada actualización de Kubernetes o cambio de imagen de nodo.
• Log de auditoría: de forma continua, enviado a medida que se escribe.

Guárdalo todo en almacenamiento de objetos con versionado y bloqueo de retención, en una cuenta separada de la que los administradores del clúster no puedan borrar, escrito con credenciales que puedan añadir objetos pero no eliminarlos. Consérvalo al menos durante el periodo auditado más el tiempo hasta que se emite el informe, o más si tu SGSI lo exige.

Cómo mapear los controles del clúster a SOC 2 e ISO 27001

Ninguno de los dos marcos menciona Kubernetes, pero cada exportación de arriba encaja en un área de control que ambos exigen:

• Resultados del escaneo CIS y tickets de remediación. ISO 27001: gestión de la configuración y gestión de las vulnerabilidades técnicas. SOC 2: operaciones del sistema, que incluye detectar cambios de configuración que introducen vulnerabilidades.
• Etiquetas de Pod Security y la política de contenedores privilegiados. ISO 27001: derechos de acceso privilegiado y gestión de la configuración. SOC 2: acceso lógico, restringir el acceso privilegiado a la infraestructura.
• La política de registry aprobado. ISO 27001: instalación de software en sistemas en producción. SOC 2: gestión de cambios, ya que solo llegan a producción imágenes de un registry que controlas.
• Requests y limits. ISO 27001: gestión de la capacidad. SOC 2: los criterios de disponibilidad, si la disponibilidad entra en tu alcance.
• Cambios de políticas mediante merge requests. Gestión de cambios, en ambos marcos.
• Log de auditoría y snapshots de los informes de políticas. ISO 27001: registro de eventos y actividades de monitorización. SOC 2: operaciones del sistema.
• El registro de excepciones. Ambos esperan que las desviaciones estén aprobadas, limitadas en el tiempo y revisadas; los auditores muestrean el registro como cualquier otra población.

Si te aplican NIS2 o DORA, las mismas exportaciones respaldan sus requisitos de gestión del riesgo TIC. Pon el mapeo por escrito en un documento breve que apunte cada control a la ruta de su evidencia: es lo que entregas al auditor el primer día.

Un despliegue en seis semanas

• Semana 1, línea base. Ejecuta kube-bench en cada node pool y convierte cada FAIL en un ticket o en una aceptación de riesgo por escrito. Activa el log de auditoría del API server. Entregables: el primer escaneo en el almacén de evidencias, una lista de hallazgos clasificada, logs de auditoría fluyendo.
• Semana 2, Pod Security. Haz el dry run y después etiqueta los namespaces de aplicaciones para aplicar baseline, con audit y warn en restricted. Registra cada namespace que no pueda cumplir baseline, con su motivo. Entregables: la exportación de etiquetas de namespaces y su lista de excepciones.
• Semana 3, Kyverno en auditoría. Instálalo con las excepciones activadas para un namespace, aplica las políticas con [Audit, Warn] y añade la comprobación en CI. Entregables: políticas en Git, el primer snapshot de informes, la puerta de CI.
• Semana 4, corregir y exceptuar. Repasa los fallos con los equipos responsables; lo que no se pueda corregir recibe una excepción con fecha de caducidad y aprobador. Entregables: un recuento de fallos a la baja y el registro de excepciones.
• Semana 5, bloquear. Pasa a [Deny] cada política con el informe limpio, un merge request por política. Entregables: los registros de cambios.
• Semana 6, evidencias. Programa la exportación diaria, bloquea el almacenamiento y escribe el mapeo de controles. Después ensaya: elige una fecha pasada al azar y presenta la evidencia de cada control. Entregables: el almacén de evidencias, el mapeo y las notas del ensayo.

A partir de ahí el trabajo es rutina: escaneos semanales, una revisión mensual de excepciones y una comprobación trimestral de que el mapeo sigue coincidiendo con el clúster.

Solicita una evaluación gratuita de cumplimiento en Kubernetes

Si tienes una auditoría a la vista y no sabes qué mostrarían hoy tus clústeres, nuestro equipo de DevSecOps lo revisa contigo sin coste.

La evaluación gratuita incluye:

• Una ejecución del CIS Benchmark en tus node pools, con cada hallazgo clasificado como tuyo, de tu proveedor o riesgo aceptado
• Una revisión de tus controles de admisión: etiquetas de namespaces, políticas, y cómo se aprueban las excepciones y si caducan
• Una lista de carencias de evidencias por área de control de SOC 2 o ISO 27001: qué registran hoy tus clústeres, qué falta y cómo recogerlo de forma automática

Recibes una lista por escrito y un plan a la medida de tu equipo, sin ningún compromiso. Solicita tu evaluación gratuita de cumplimiento en Kubernetes, o descubre cómo nuestro equipo de consultoría Kubernetes gestiona clústeres en producción.