Seguridad CI/CD: cómo Cilium aísla credenciales

Cilium acaba de cerrar su trilogía sobre endurecimiento de CI/CD con un enfoque que cualquier equipo de infraestructura debería mirar de cerca. El 26 de junio de 2026, André Martins y Feroz Salam publicaron la tercera parte, centrada en algo que suele ser el eslabón más flojo: las credenciales. La receta es simple en concepto pero jodida de implementar bien — separar tajantemente lo que puede tocar un pipeline de CI de lo que llega a producción, y firmar cada release como si el mundo se fuera a acabar mañana.

La seguridad en CI/CD para un proyecto open source como Cilium es una estrategia de defensa en profundidad que asume que cualquier capa puede fallar y, por eso, nunca deja que un solo incidente de seguridad escale hasta producción. Básicamente, se trata de controlar quién ejecuta qué, aislar las credenciales de desarrollo de las de despliegue real y garantizar que cada artefacto que sale al mundo esté firmado y verificable, sin depender de la buena fe de un pipeline automatizado.

¿Por qué aislar las credenciales de CI de las de producción?

Ponele que un workflow de CI se ve comprometido — ya sea por una acción maliciosa, una dependencia infectada o un error de configuración. Si ese pipeline tiene acceso a los secretos de producción, el desastre es inmediato. El equipo de Cilium lo entendió y partió de una premisa dura: asumir que cualquier capa individual puede fallar. Por eso, en la tercera entrega publicada el 26 de junio de 2026, detallan que mantienen dos grupos de credenciales completamente separados detrás de entornos protegidos de GitHub.

Las credenciales de CI solo pueden empujar imágenes al registro de desarrollo, quay.io/cilium. Incluso si alguien tomara control total de un build de integración, no podría tocar los tags de producción. Las credenciales de producción, en cambio, residen detrás de un entorno que requiere la aprobación explícita de un mantenedor (sí, un humano apretando un botón). Así, ni forks, ni feature branches, ni builds automáticos llegan a esos secretos. Solo los workflows disparados por tags de release que un mantenedor haya revisado y autorizado pueden usarlos.

¿Y qué pasa si el atacante intenta desde un fork? Nada. GitHub bloquea el acceso a secretos de entornos protegidos desde forks por diseño, y Cilium se apoya en eso sin agregar complejidad innecesaria. Ojo, esto no es magia: requiere que los workflows soliciten explícitamente permisos mínimos, y los que necesitan más tienen que declararlo paso a paso. Si un workflow se olvida de declarar permisos, no hereda accesos amplios de escritura sobre la organización. Ya lo cubrimos antes en en nuestra guía comparativa de CI/CD 2026.

¿Cómo se firman y atestan los releases en Cilium?

Acá es donde la cosa se pone interesante. Firmar releases no es opcional, y menos en un proyecto que mueve infraestructura de red a nivel kernel. El pipeline de Cilium integra Sigstore Cosign con OIDC keyless: cada vez que se genera una imagen o un Helm chart a partir de un tag aprobado, Cosign firma el artefacto y adjunta un SBOM (Software Bill of Materials) generado automáticamente. Esto significa que, sin necesidad de gestionar claves privadas, podés vincular criptográficamente cada release con la identidad del workflow que lo creó.

Lo clave es que el firmado solo se dispara para builds originados en tags — no en commits sueltos, no en PRs. Ese tag ya pasó por la aprobación del mantenedor, así que el nivel de confianza es alto. Después, la firma y el SBOM quedan publicados en el registro público, listos para que cualquiera los verifique. La combinación de firma keyless + SBOM es un golazo porque, más adelante, podés responder preguntas como “¿esta imagen incluye la versión parcheada de OpenSSL?” sin depender de la documentación.

¿Qué brechas de seguridad aún quedan abiertas?

Si algo valoro de esta serie es que no venden humo. El mismo equipo de Cilium enumera los gaps que todavía tienen sobre la mesa, algunos de los cuales son bastante comunes en proyectos open source que no cuentan con un ejército de security engineers full-time (spoiler: casi nadie los tiene).

Falta SLSA provenance. Todavía no generan atestaciones de procedencia que cumplan con SLSA. Esto significa que, si bien la firma te dice quién construyó la imagen, no tenés una cadena de confianza completa sobre cómo se construyó, en qué entorno y con qué parámetros exactos. Es una deuda técnica que planean saldar, pero no es trivial. Cubrimos ese tema en detalle en como explicamos al comparar Jenkins y GitHub Actions.

No hay revisión de dependencias en tiempo de PR. En la parte 2 de la serie cubrieron el pinning de acciones e imágenes por SHA, pero aún no ejecutan un escaneo automático de dependencias cuando alguien abre un pull request. Si una dependencia nueva trae una vulnerabilidad, recién se enterarían más tarde en el ciclo.

Govulncheck ausente en CI. Relacionado con lo anterior, no corren govulncheck (la herramienta oficial de Go para detectar vulnerabilidades) dentro del pipeline. Para un proyecto escrito en Go como Cilium, esto es un faltante que debería resolverse rápido.

Referencias a @main en workflows internos. Algunos flujos todavía referencian acciones compuestas desde la rama @main en lugar de usar un repositorio dedicado y versionado. Cualquier cambio en esas acciones podría impactar los pipelines sin que nadie lo note hasta que algo falle o, peor, no falle pero se comporte distinto.

¿Cómo funciona la verificación de firmas en el consumidor?

Del otro lado del mostrador, el que consume las imágenes de Cilium también tiene herramientas para no confiar ciegamente. Con un comando como el que mostraron en el blog, podés verificar que la imagen que estás por desplegar fue firmada por el pipeline oficial y que el SBOM coincide con lo que esperás: Lo explicamos a fondo en en nuestra guía de hreflang para SEO internacional.

• Verificación de firma: cosign verify quay.io/cilium/cilium:v1.16.0 te devuelve la identidad OIDC que firmó la imagen. Si el certificado no matchea con el issuer esperado, algo raro pasa.
• Inspección del SBOM: Podés extraer el SBOM adjunto y revisar que todos los paquetes listados sean los correctos. Si de repente aparece una biblioteca que no debería estar, saltan las alarmas.

Esto es particularmente útil en entornos regulados o en empresas que necesitan demostrar conformidad. No alcanza con decir “confiamos en Cilium”; ahora podés auditarlo técnicamente. Y lo más piola es que no necesitás pedirle nada a nadie: la información está pública y la verificación es local.

Tabla comparativa de las capas de seguridad en el CI/CD de Cilium

Capa	Medida implementada	Qué protege
Control de acceso	Ariane + CODEOWNERS en .github	Quién puede disparar builds y qué flujos se ejecutan según quién modifica cada path
Endurecimiento de dependencias	Pinning por SHA de acciones e imágenes, actionlint, CodeQL	Ejecución de código no deseado en el pipeline y errores de configuración
Aislamiento de credenciales	Entornos protegidos separados para CI y producción	Que un workflow comprometido escale a producción
Firma de releases	Cosign OIDC keyless + SBOM en cada release	Garantizar integridad del artefacto y trazabilidad de paquetes
Verificación del consumidor	cosign verify público + validación de SBOM	Permite a terceros auditar antes de desplegar

Errores comunes al asegurar pipelines CI/CD

Después de leer las tres partes, hay patrones que se repiten y que cualquiera que mantenga CI/CD debería anotar. Estos son los que más veo en proyectos — y los que Cilium evitó de entrada o está corrigiendo.

• Usar las mismas credenciales para todo. Es tentador tener un solo token o service account que haga todo, pero un solo descuido en un workflow de pruebas y se te escapó acceso completo a producción.
• No verificar firmas en el consumidor. Firmar está bárbaro, pero si del otro lado nadie verifica, es como ponerle llave a la puerta y dejarla abierta.
• Dejar secretos accesibles desde forks. GitHub permite restringir secretos a entornos protegidos, pero mucha gente no lo configura y después se sorprende cuando un PR malicioso los lee.
• Referenciar acciones por tag en lugar de SHA. Un tag se puede mover, un SHA no. Si no pineás por hash, estás aceptando que el código de tus acciones cambie sin que te enteres.

Preguntas Frecuentes

¿Cómo proteger credenciales en un pipeline CI/CD?

Separándolas en entornos protegidos con permisos mínimos. Las credenciales de CI deben tener alcance limitado a registros de desarrollo, mientras que las de producción deben estar bloqueadas detrás de aprobación manual y no ser accesibles desde forks ni ramas de feature. Cilium logra esto con entornos protegidos de GitHub y exigiendo que cada workflow declare explícitamente los permisos que necesita.

¿Cómo firmar releases en CI/CD con Cosign?

Integrando Cosign con OIDC keyless en el paso de release del pipeline, idealmente solo para builds disparados por tags aprobados. Cosign genera una firma vinculada a la identidad del workflow sin necesidad de gestionar claves privadas. Además, se puede adjuntar un SBOM con los paquetes de la imagen para que el consumidor verifique. Más contexto en en la guía OpenClaw para agentes sin API.

¿Qué es SLSA y cómo mejora la seguridad?

SLSA (Supply-chain Levels for Software Artifacts) es un framework que define niveles crecientes de integridad en la cadena de suministro de software. Mejora la seguridad al exigir atestaciones de procedencia que prueban cómo, dónde y con qué herramientas se construyó un artefacto. Cilium todavía no genera provenance SLSA, pero lo tiene en su roadmap para cerrar el círculo de confianza.

¿Qué brechas de seguridad quedan en CI/CD después de aplicar estas medidas?

Las principales brechas que Cilium reconoce son la falta de SLSA provenance, la ausencia de revisión de dependencias en tiempo de PR, no ejecutar govulncheck en CI y mantener referencias a @main en workflows internos. Son gaps comunes que requieren inversión de tiempo y herramientas adicionales para cerrarse por completo.

Conclusión

La serie de Cilium deja una lección clara: la seguridad en CI/CD no se compra con una herramienta mágica, se construye por capas. Arrancaron controlando quién dispara qué, después endurecieron dependencias y ahora cerraron con aislamiento de credenciales y firma de releases. Lo más valioso es que no ocultan lo que falta — SLSA provenance, escaneo en PRs y govulncheck siguen en el debe — y eso te da una hoja de ruta realista para cualquier proyecto, sea open source o interno.

Si estás armando o auditando pipelines, lo mínimo que podés llevarte es separar credenciales, firmar todo lo que salga a producción y darle al consumidor la posibilidad de verificar. Lo demás se puede ir sumando, pero sin esas tres patas, la mesa se tambalea.

Fuentes

• CNCF Blog – Securing CI/CD for an open source project, part 3: Credentials, verification, and what’s next — publicación del 26 de junio de 2026 por André Martins y Feroz Salam.
• CNCF Blog – Part 2: Locking down dependencies — endurecimiento de dependencias en el pipeline de Cilium.
• CNCF Blog – Part 1: Controlling who runs what — control de acceso y ejecución de workflows.