Contexto que conviene no separar: este artículo asume que ya has decidido usar AKS. Si esa decisión sigue abierta —AKS, EKS o GKE— la comparativa completa de seguridad, cumplimiento y TCO para sectores regulados está en Kubernetes en sectores regulados: AKS, EKS o GKE. Aquí me quedo con la pregunta siguiente: una vez elegido AKS, ¿cómo se construye el pipeline que lo hace operable en un entorno auditado?
El falso trade-off entre velocidad y control
La objeción más habitual a acelerar el ritmo de despliegue en un entorno regulado no es técnica, es cultural: "cuantos más despliegues, más riesgo, más difícil de auditar". Es una intuición razonable si el control de seguridad vive fuera del pipeline, como una revisión manual antes de cada release trimestral. Deja de serlo en cuanto el control vive dentro del pipeline, ejecutándose en cada commit en vez de una vez cada tres meses.
La entidad de capital markets de este caso operaba 18 aplicaciones Java monolíticas sobre máquinas virtuales on-premise, con ventanas de despliegue de 6 horas en fin de semana y un release trimestral. El CTO no quería solo modernizar la plataforma: quería pasar a despliegue continuo sin exponer un sistema de negociación con SLA de disponibilidad del 99,95% a más riesgo operativo, y sin perder la capacidad de responder ante MIFID II, DORA y EMIR Refit con la velocidad que el regulador empezaba a exigir.
El pipeline de cinco etapas
La respuesta no fue un único control de seguridad más estricto. Fue repartir el control en cinco etapas, cada una con su propia responsabilidad, de forma que ningún artefacto llegue a producción sin haber pasado por las cinco:
| Etapa | Controles | Qué evita |
|---|---|---|
| Code | SAST con SonarQube · escaneo de secretos en el propio commit | Vulnerabilidades de código y credenciales filtradas antes de que lleguen a build |
| Build | Escaneo de imagen con Trivy y Defender for Containers · SBOM generado y firmado | Dependencias vulnerables e imágenes sin trazabilidad de componentes |
| Test | DAST contra OWASP Top 10 · gates de pen test automatizado | Vulnerabilidades que solo aparecen con la aplicación en ejecución |
| Deploy | Publicación en ACR · despliegue con Helm · aprobación gated · verificación de firma (Notation) | Artefactos sin firma o sin aprobación llegando a producción |
| Runtime | Istio mTLS entre microservicios · OPA Gatekeeper · Workload Identity | Tráfico interno sin cifrar, despliegues fuera de política, secretos estáticos en código |
Code y Build: lo que se detecta antes de que exista un contenedor que desplegar
SAST con SonarQube y escaneo de secretos se ejecutan en el propio commit, no en una revisión posterior. La lógica es la misma que en cualquier práctica de shift-left: cuanto más tarde se detecta un problema, más caro es corregirlo y más fácil es que alguien, bajo presión de fecha, decida asumir el riesgo en vez de arreglarlo. En build, cada imagen se escanea con Trivy y Defender for Containers, y se genera un SBOM (Software Bill of Materials) que se firma junto con la imagen. Ningún artefacto sin firma llega a producción — esto no es una recomendación, es una verificación de integridad automatizada en el propio despliegue.
Deploy: por qué GitOps es el control de auditoría, no solo de despliegue
El estado deseado de cada clúster se gestiona desde repositorios Git con Flux CD. Cada cambio en el repositorio dispara la reconciliación automática. Los rollbacks se hacen con un git revert, sin scripts manuales ni coordinación ad-hoc entre equipos. La consecuencia que más valoró el equipo de cumplimiento no fue operativa, fue de auditoría: cada despliegue tiene un commit, cada commit tiene un autor, una fecha y un diff. Eso es exactamente el tipo de evidencia que un auditor DORA pide y que, con despliegues manuales o ad-hoc, es costoso reconstruir a posteriori.
Runtime: el perímetro que no termina en el "deploy" con éxito
Istio gestiona mTLS entre microservicios sin tocar el código de aplicación. OPA Gatekeeper aplica políticas de admisión: nada se despliega si no cumple la política, con una salvedad operativa importante que conviene no saltarse.
Lo que el pipeline no cubre: por qué runtime necesita su propia capa
Es tentador tratar un pipeline con cinco gates como una garantía completa. No lo es, y este proyecto tiene el dato que lo demuestra: Falco y Defender for Containers detectaron en producción un intento de exfiltración que había pasado todos los gates del CI/CD. El pipeline verifica lo que puede verificarse antes del despliegue —código, dependencias, imagen, comportamiento esperado—. No puede anticipar un comportamiento anómalo que solo se manifiesta con el sistema en producción y bajo tráfico real. Por eso Defender for Containers y Falco operan como capa de detección runtime independiente del pipeline, no como una repetición de sus controles.
El matiz que conviene no pasar por alto: un pipeline con controles de seguridad no sustituye la detección en runtime, la complementa. Si tu modelo de amenaza asume que "si pasó el pipeline, es seguro", tienes una falsa sensación de cobertura. Los controles de shift-left reducen drásticamente la superficie que llega a producción; no la reducen a cero.
Por qué esto es lo que un auditor DORA acepta como evidencia
El resultado de cumplimiento no fue un documento preparado para la auditoría. Fue una consecuencia de cómo se diseñó el pipeline: el audit trail de GitOps y los controles DevSecOps integrados satisficieron los requerimientos de evidencia de la auditoría DORA del primer año sin trabajo adicional de preparación. Esa es la diferencia práctica entre cumplimiento como proceso y cumplimiento como ejercicio de recopilación de capturas de pantalla la semana antes de la auditoría.
| Pregunta del auditor | Evidencia que el pipeline genera por diseño |
|---|---|
| ¿Quién aprobó este cambio en producción? | Commit de Git con autor, fecha y diff — sin necesidad de reconstruir manualmente el histórico |
| ¿Cómo se verificó la integridad de este artefacto? | SBOM firmado y verificación de firma (Notation) en el propio despliegue |
| ¿Qué vulnerabilidades tenía esta imagen antes de desplegarse? | Resultado de escaneo Trivy / Defender for Containers asociado al build |
| ¿Cómo se detectaría un comportamiento anómalo en producción? | Falco + Defender for Containers como capa de detección runtime, con caso demostrado |
| ¿Qué credenciales estáticas existen en el código? | Ninguna — Workload Identity elimina la pregunta en vez de responderla |
El plan de trabajo, en orden
- Empieza por Code y Build, no por Runtime — el escaneo de código y la firma de artefactos generan la mayoría de la evidencia de auditoría con la menor complejidad operativa.
- GitOps desde el primer clúster, no como migración posterior. Reconstruir audit trail sobre despliegues ya existentes es mucho más caro que diseñarlo desde el origen.
- OPA Gatekeeper en modo warn durante al menos un ciclo de release antes de pasar a enforce, midiendo cuántos despliegues existentes romperían la política nueva.
- Workload Identity antes de escalar el número de microservicios — es mucho más barato no crear secretos estáticos que migrar los que ya existen.
- Defender for Containers y Falco desde el día uno de producción, no como respuesta a un incidente. La capa de detección runtime no es una mejora incremental, es la que cubre lo que el pipeline, por diseño, no puede ver.
El patrón de migración usado —Strangler Fig, con un API gateway enrutando tráfico entre el monolito on-premise y los nuevos microservicios en AKS durante la coexistencia— evitó además la ventana de migración de fin de semana. Cuando una aplicación completaba su migración al 100%, el monolito correspondiente se desconectaba. Sin big bang, sin fin de semana de máxima tensión operativa.