Las tres lecciones anteriores han asegurado la identidad, el canal y el código. Todo eso se ejecuta encima de una plataforma —imágenes, pods, secretos, red del clúster, permisos del API server, pipelines— y un fallo en esa capa deja sin efecto las demás: una imagen con una biblioteca vulnerable, un contenedor que corre como root y escapa al nodo, un Secret legible por cualquiera del namespace, un pod que puede hablar con quien quiera, o un token de CI con permisos de cluster-admin. Esta lección cierra el módulo endureciendo la plataforma de TechCorp: modelo de amenazas y las 4C, imágenes seguras (escaneo con Trivy, firma con cosign, digests), securityContext completo y Pod Security Admission, secretos (Kubernetes Secrets, External Secrets Operator, rotación, OIDC en CI), NetworkPolicy con deny-all por defecto (cerrando lo que 07-02 remitió aquí), RBAC y ServiceAccount por servicio, auditoría y detección, cadena de suministro, y una lista de comprobación con el estado real de TechCorp. Autenticación de usuarios (07-01), TLS/mTLS (07-02) y OWASP/código (07-03) solo se enlazan.

Aviso. Las políticas, versiones y valores de esta lección son didácticos. Antes de aplicarlos en un clúster real, revísalos con un profesional de seguridad de plataforma y con quien responda del cumplimiento; y prueba cada restricción en staging, porque muchas rompen cargas de trabajo que hasta ahora funcionaban.

1. Modelo de amenazas de la plataforma y las 4C
2. Imágenes seguras: base mínima, escaneo, firma y digests
3. Seguridad del pod: securityContext completo y Pod Security Admission
4. Secretos: Kubernetes Secrets, External Secrets Operator y rotación
5. Secretos en CI: GitHub Environments y OIDC
6. Red: NetworkPolicy con deny-all por defecto
7. RBAC de Kubernetes: ServiceAccount por servicio y roles mínimos
8. Auditoría y detección
9. Cadena de suministro: lockfile, SBOM y SLSA
10. Lista de comprobación de plataforma para TechCorp

Antes de endurecer nada, qué puede salir mal y en qué capa:

Las 4C de la seguridad cloud native (Cloud, Cluster, Container, Code) recuerdan que cada capa hereda la seguridad de la exterior: el mejor securityContext no salva un clúster con el API server abierto a Internet, y el mejor clúster no salva un servicio-pedidos con inyección SQL. Esta lección cubre Container y Cluster; Code fue 07-01/07-03; Cloud es del proveedor y de Plataforma.

El Dockerfile de 05-01 ya cumple lo esencial: node:20-alpine, multi-stage (nada de compiladores ni devDependencies en la imagen final), USER node, COPY --chown, HEALTHCHECK y npm ci --omit=dev con el .npmrc como secreto de build. Lo que se añade:

• Base mínima: alpine reduce la superficie a unos pocos MB; una alternativa aún menor es distroless (gcr.io/distroless/nodejs20-debian12: sin shell, sin gestor de paquetes; kubectl exec ... sh deja de funcionar, lo que es una ventaja de seguridad y un coste de depuración —se resuelve con kubectl debug y contenedores efímeros—). TechCorp mantiene alpine en la fase 1 y evalúa distroless para Pagos.
• Escaneo en CI con Trivy, que 05-03 dejó configurado con severity: CRITICAL. La política definitiva: fallar con CRITICAL y HIGH que tengan parche disponible, ignorar las que no lo tienen pero registrarlas, y volver a escanear las imágenes ya desplegadas cada noche (las CVE aparecen después de construir):

• Firma de imágenes con cosign (Sigstore): tras el push, el pipeline firma la imagen con la identidad OIDC del workflow (sin claves que guardar, keyless), y el clúster verifica la firma antes de arrancar un pod, con un controlador de admisión (Kyverno o el policy controller de Sigstore). Solo mención con los comandos:

• imagePullPolicy y digest: una etiqueta (1.0.1) puede reapuntarse; un digest (@sha256:…) no. En producción, el overlay de Kustomize fija newTag y digest (kustomize edit set image ghcr.io/techcorp/servicio-pedidos@sha256:9f1c…), imagePullPolicy: IfNotPresent es seguro porque el digest es inmutable, y el registro ghcr.io/techcorp es privado con imagePullSecrets (o identidad de nube) en el ServiceAccount. latest sigue prohibido (05-01).

El Deployment de 05-02 tenía runAsNonRoot, runAsUser: 1000, allowPrivilegeEscalation: false y readOnlyRootFilesystem: true. La versión completa, la que exige el perfil restricted:

Qué aporta cada línea nueva: seccompProfile: RuntimeDefault activa el perfil seccomp del runtime (containerd) que bloquea decenas de syscalls que ninguna aplicación normal usa y que son la vía de muchas fugas del contenedor; capabilities: drop: [ALL] quita hasta las capabilities que Docker concede por defecto (NET_RAW, CHOWN...): si un atacante ejecuta código dentro, no puede abrir sockets raw ni cambiar propietarios; emptyDir para /tmp hace compatible readOnlyRootFilesystem con librerías que escriben temporales (con sizeLimit para que no llene el nodo); fsGroup permite leer secretos montados como ficheros sin ser root.

Pod Security Admission (PSA) hace que el clúster rechace pods que no cumplan un perfil, en vez de confiar en que cada Deployment lo escriba bien. Tres perfiles: privileged (todo), baseline (sin lo peor: privilegiado, hostPath, hostNetwork), restricted (todo lo anterior más runAsNonRoot, drop ALL, seccomp, sin escalada). Se activa con etiquetas en el namespace:

El Job de migraciones de 05-02, el gateway, RabbitMQ y Keycloak deben cumplirlo también (o vivir en otro namespace con baseline justificado). Para reglas más finas que las de PSA (exigir digest, prohibir latest, exigir resources), se usa un motor de políticas como Kyverno u OPA Gatekeeper; mención.

Un Secret de Kubernetes (05-02: pedidos-db, pedidos-rabbitmq, y desde 07-01 pedidos-oidc; pagos-pasarela en 07-02) es base64, no cifrado: kubectl get secret pedidos-db -o jsonpath='{.data.PEDIDOS_DB_URL}' | base64 -d lo muestra a cualquiera con permiso de lectura. Tres capas para que sea seguro:

1. Cifrado en reposo en etcd (EncryptionConfiguration del API server con aescbc/kms): responsabilidad de Plataforma o del proveedor gestionado (activo por defecto en los principales). Sin esto, una copia de etcd es una copia de todos los secretos.
2. RBAC de lectura (apartado 7): solo los ServiceAccount de los pods que los montan y unas pocas personas de Plataforma pueden get secretos; los desarrolladores de Pedidos, no. Y el manifiesto del Secret nunca está en techcorp/plataforma (GitOps es público dentro de la empresa).
3. Fuente de verdad externa con External Secrets Operator (ESO): el secreto vive en un gestor (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager...), y ESO crea y actualiza el Secret de Kubernetes a partir de él. Así git solo contiene la referencia:

Rotación de credenciales. Una contraseña de base de datos vive años porque rotarla da miedo; con esta arquitectura, el procedimiento es rutinario (y se ejecuta al menos semestralmente y siempre tras una fuga, 07-03):

Un Reloader (Stakater) o la anotación de Argo CD pueden automatizar el paso 3 cuando cambia el Secret.

En 05-03 el pipeline tenía GITHUB_TOKEN, PACT_BROKER_TOKEN, PLATAFORMA_TOKEN y KUBECONFIG_STAGING, y quedó pendiente la mención a OIDC. Lo que se cierra aquí:

• Environments de GitHub (staging, production): secretos por entorno, required reviewers para producción, y deployment branches para que solo main pueda usarlos. Un workflow de una rama de funcionalidad no ve KUBECONFIG_STAGING.
• OIDC en vez de tokens de larga duración: con permissions: id-token: write, el workflow obtiene un JWT firmado por GitHub que dice "soy el workflow X del repo Y en la rama Z", y la nube o el registro lo canjean por credenciales de minutos. Es el mismo client credentials de 07-01, con GitHub como emisor. Para el registro (ghcr.io) ya lo hace GITHUB_TOKEN; para un clúster gestionado en la nube:

Con esto KUBECONFIG_STAGING desaparece como secreto (la confianza es "este repo, esta rama, este workflow", configurada en la política del rol de la nube), y en producción no hay credencial ninguna: Argo CD hace pull (05-03). PLATAFORMA_TOKEN (para abrir el PR de promoción) se sustituye por una GitHub App con permisos acotados al repositorio plataforma. PACT_BROKER_TOKEN se mantiene como secreto de entorno, rotado por calendario.

Ficheros frente a variables de entorno. Las variables de entorno se ven en kubectl describe pod (no los valores de secretRef, pero sí de env: value), en /proc/<pid>/environ y las heredan los procesos hijos; los ficheros montados desde un Secret (volumes: - secret: { secretName: pedidos-db } + PEDIDOS_DB_URL_FILE=/etc/secretos/PEDIDOS_DB_URL) solo los lee quien tiene el UID/fsGroup adecuado, y Kubernetes los actualiza en caliente cuando el Secret cambia. La convención <VARIABLE>_FILE de 04-03 ya está implementada: TechCorp migra a ficheros los secretos de Pagos primero (auditoría) y el resto conforme se toque cada servicio.

Sin NetworkPolicy, cualquier pod del clúster puede abrir una conexión con cualquier otro: un pod comprometido en techcorp llega a servicio-inventario:3006 con X-Usuario-Roles: admin (07-01) o a postgres:5432 para probar contraseñas. Las NetworkPolicy son firewall por etiquetas; requieren un CNI que las aplique (Calico, Cilium; los gestionados suelen traerlo). Estrategia: denegar todo en el namespace y abrir explícitamente.

Y servicio-pagos es el único con egress a Internet (la pasarela): ipBlock: { cidr: 0.0.0.0/0, except: [10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16] } en el puerto 443, o mejor, si el CNI lo soporta (Cilium), una política por FQDN (api.pasarela-pagos.example). El resto de servicios no salen del clúster: un servicio-catalogo comprometido no puede exfiltrar datos ni descargar herramientas.

Con las políticas, la advertencia de 07-01 sobre X-Usuario-* pasa de "cualquier pod" a "solo el gateway y Prometheus pueden alcanzar Pedidos" —y mTLS con mesh (07-02) añadirá, cuando llegue, identidad criptográfica además de red. Las políticas viven en techcorp/plataforma/k8s/red/ y las revisa Plataforma; cada servicio nuevo llega con la suya en la plantilla.

Todo pod corre con un ServiceAccount (SA); por defecto, default, con un token montado en /var/run/secrets/kubernetes.io/serviceaccount que permite hablar con el API server. servicio-pedidos no necesita hablar con el API server, así que: SA propio (identidad clara para NetworkPolicy en algunos CNI, para mTLS con mesh en 07-02, y para imagePullSecrets) y sin token montado:

Quien sí habla con el API server, con lo mínimo:

• Audit log del API server: registra quién hizo qué contra la API (kubectl get secret pedidos-db por parte de una persona, un create de Role, un pod que no cumple PSA). Se configura con una Policy de auditoría (nivel Metadata para todo, RequestResponse para secrets, roles y rolebindings) y se envía a Loki (06-01) con retención larga, separada de los logs de aplicación (07-03). En clústeres gestionados se activa desde el proveedor.
• Detección en tiempo de ejecución: Falco (mención) observa syscalls en los nodos y alerta ante comportamientos anómalos —una shell abierta en un contenedor de producción, un proceso que lee /etc/shadow, una conexión saliente desde un pod que no debería salir— y se integra con Alertmanager (06-05). Con readOnlyRootFilesystem, drop ALL y NetworkPolicies, la mayoría de esos comportamientos ya fallan; Falco cuenta el intento.
• Higiene: kube-bench (CIS Benchmark) para la configuración del clúster y kubectl get events -A --field-selector reason=FailedCreate para ver pods rechazados por PSA.

La cadena de suministro es todo lo que hay entre el código de Luis y el pod en producción, y cada eslabón puede sustituirse por algo malicioso. Lo que TechCorp fija: package-lock.json y npm ci (05-01/07-03: exactamente lo que se probó es lo que se despliega); dependencias y acciones de CI fijadas por versión (actions/checkout@v4, mejor por SHA para las críticas) y la imagen base por digest (node:20-alpine@sha256:…, actualizada por Renovate); SBOM por imagen con Syft (syft ghcr.io/techcorp/servicio-pedidos:1.0.1 -o spdx-json > sbom.json) adjunto a la imagen (cosign attest) para responder en minutos "¿qué servicios llevan libxml2 2.9.x?"; firma cosign y verificación en admisión (apartado 2); y SLSA (Supply-chain Levels for Software Artifacts) como marco de referencia: TechCorp está en el nivel 2 (build en CI con procedencia firmada) y aspira al 3 (runners efímeros y aislados). Solo mención: lo esencial es que el pipeline de 05-03 sea el único camino a producción, y que produzca artefactos verificables.

Estado al cierre del módulo 7, mantenido en techcorp/plataforma/SEGURIDAD.md:

• Aplicar deny-all sin la política de DNS: todo deja de resolver y parece que "Kubernetes se ha roto". DNS primero, siempre.
• Olvidar el scraping de Prometheus, Jaeger o Keycloak en las políticas: métricas y trazas desaparecen en silencio. Revisa cada to/from con los diagramas de 06-01/06-02.
• readOnlyRootFilesystem sin emptyDir en /tmp: la aplicación falla al arrancar con EROFS en la primera escritura de una dependencia.
• PSA enforce de golpe en un namespace con RabbitMQ, Keycloak o el ingress controller: pods rechazados. warn/audit primero, luego enforce.
• Secret en el repositorio GitOps "porque está en base64": es texto plano. Referencia con ExternalSecret, valor en el gestor.
• Rotar la contraseña y no reiniciar los pods (variables de entorno): fallan al reconectar horas después, de madrugada. Rotación = cambio + sincronización + rollout restart (o ficheros en caliente).
• cluster-admin para el pipeline o Argo CD "de momento": el momento dura años. Role por namespace desde el primer día.
• Consejo: cada restricción nueva se prueba con un game day (06-03): intenta hacer lo prohibido (kubectl run con root, curl a Inventario desde otro pod, kubectl get secret como desarrollador) y comprueba que falla y que queda en el audit log.

Ejercicio 1. Escribe la NetworkPolicy de servicio-notificaciones (puerto 3005): consume de RabbitMQ (amqps), envía correo a un proveedor externo por HTTPS, expone /metrics a Prometheus, y nadie del clúster debe poder llamar a su API salvo Prometheus. Indica el riesgo que introduce el egress externo y cómo acotarlo.

Ejercicio 2. Un desarrollador de Catálogo pide poder ejecutar kubectl exec en los pods de servicio-catalogo en staging "para depurar Mongo". Diseña el Role/RoleBinding mínimo, di qué no incluye y propón una alternativa mejor coherente con esta lección.

Ejercicio 3. Recorre el modelo de amenazas del apartado 1 para el escenario "un atacante consigue ejecutar código dentro del pod de servicio-catalogo gracias a una dependencia comprometida" y enumera, capa por capa, qué medidas de esta lección limitan el daño y qué podría hacer aún.

Solución 1.

(DNS lo cubre permitir-dns.) El riesgo: el egress a "cualquier IP pública en 443" permite exfiltrar datos (correos, nombres) si el pod se compromete. Acotarlo: política por FQDN del proveedor de correo con Cilium (toFQDNs: [{ matchName: api.correo.example }]), o un proxy de salida (egress gateway) con lista blanca de dominios que además da un único punto de auditoría; y la minimización de 07-03 (Notificaciones no persiste datos personales) reduce lo que hay para exfiltrar.

Solución 2. Role depurador-catalogo en techcorp con pods (get/list), pods/log (get), pods/exec (create) limitado a los pods de Catálogo — RBAC no filtra por etiqueta, así que se hace con resourceNames (frágil, los nombres cambian) o, mejor, dando el Role en un namespace techcorp-catalogo si se separa por equipo; RoleBinding al grupo equipo-experiencia-compra del SSO. No incluye secrets, exec en otros pods, ni nada de escritura. Alternativas mejores: (1) kubectl debug con un contenedor efímero (kubectl debug -it pod/servicio-catalogo-xxx --image=mongo:7 --target=servicio-catalogo) en vez de exec en el contenedor de la aplicación, que además funciona con distroless; (2) un port-forward a MongoDB (pods/portforward) y el cliente de Mongo en local con el usuario svc_catalogo_ro de solo lectura; (3) que lo que necesite verse esté en logs/métricas (06-01) para no entrar en producción nunca. Y todo exec/debug queda en el audit log (apartado 8).

Solución 3. Con código ejecutándose como el usuario node (uid 1000) en el pod de Catálogo: Contenedor: no es root, drop ALL y seccomp bloquean la mayoría de vías de escape; readOnlyRootFilesystem impide instalar herramientas (solo /tmp de 64 MB); resources.limits evitan tumbar el nodo. Secretos: ve las variables de entorno del proceso (MONGO_URL de Catálogo) —con ficheros _FILE seguiría viéndolas, es su propio secreto—; no puede leer otros Secret (SA sin token, y sin RBAC). Red: solo alcanza MongoDB de Catálogo, Keycloak y lo que su política permita; no llega a Pedidos, Inventario, PostgreSQL ni RabbitMQ, y no sale a Internet (sin egress externo): puede leer/modificar el catálogo (su daño real) pero no exfiltrarlo fácilmente ni pivotar. Identidad: sin cabeceras válidas ni token de servicio de otro (los X-Usuario-* no le sirven porque no llega a otros servicios; con mesh, tampoco tendría certificado). Detección: Falco alertaría de la shell o del proceso raro; el audit log no vería nada porque no toca la API. Qué podría hacer aún: cambiar precios o descripciones en MongoDB (mitigado por auditoría de 07-03 y el usuario svc_catalogo sin dropDatabase), servir respuestas falsas a Pedidos (mitigado por validación con zod del ACL en Pedidos y precios congelados en el pedido) y consumir CPU hasta el límite. Y la lección de fondo: la dependencia comprometida debió detectarla Trivy/npm audit/SBOM antes de llegar (apartados 2 y 9).

Con esta lección la plataforma deja de ser el eslabón débil bajo la identidad, el canal y el código. TechCorp tiene un modelo de amenazas por capas (4C); imágenes mínimas escaneadas con Trivy (CRITICAL/HIGH bloqueante) y referenciadas por digest, con cosign y verificación en admisión como siguiente paso; pods con securityContext completo (runAsNonRoot, drop ALL, seccompProfile: RuntimeDefault, readOnlyRootFilesystem con emptyDir en /tmp) y Pod Security Admission restricted en techcorp; secretos cifrados en etcd, restringidos por RBAC y provistos por External Secrets Operator (ExternalSecret pedidos-db desde el gestor externo) con un procedimiento de rotación y rollout restart; CI con Environments y OIDC en lugar de kubeconfig y tokens de larga duración, y secretos como ficheros _FILE donde más importa; NetworkPolicy deny-all con DNS, gateway como única entrada desde el Ingress, Pedidos hacia Catálogo/Clientes/RabbitMQ/PostgreSQL/Keycloak, Inventario solo desde Pedidos —cerrando lo que 07-02 remitió aquí— y solo Pagos con salida a Internet; ServiceAccount por servicio sin token, Role desplegador y Argo CD acotados, sin cluster-admin; audit log del API server y Falco como detección; lockfile, versiones fijadas, SBOM y SLSA como cadena de suministro; y una lista de comprobación con lo hecho y lo pendiente. El módulo 7 termina así donde empezó el 6: con un sistema observable, resiliente, escalable, operable y ahora también seguro por capas —autenticación y autorización con Keycloak y JWT, canal cifrado y firmado, código validado y auditado, plataforma endurecida—, y con una lista honesta de lo que queda para la fase 2 (mTLS con mesh, cosign en admisión, PSA enforce, ESO para todos los servicios). El módulo 8 recoge todo el recorrido: cómo se ejecutó la migración del monolito paso a paso, la implementación completa de los servicios, su despliegue y operación de extremo a extremo, y las lecciones aprendidas por Marta, Luis y los cuatro equipos de TechCorp.