← Todas las noticias
ARTÍCULO
4 de octubre de 2026 Actualizado el 24 de septiembre de 2026 4 min de lectura

Cosign y External Secrets Operator: una base de supply chain Kubernetes para MSP

Firma cada imagen en el build y verifícala en el deploy con Cosign, y mantén las credenciales fuera de Git con External Secrets Operator: dos controles, una sola base para los MSP.

En este artículo
  1. Firma en el build, verifica en el deploy
  2. Lo que la firma no sustituye
  3. Mantener los secretos fuera de Git con External Secrets Operator
  4. Por qué esta combinación importa para los MSP
  5. Qué hacer

Esta guía combina dos controles de código abierto que los MSP pueden aplicar en una flota Kubernetes gestionada: firmar y verificar imágenes de contenedor con Sigstore Cosign, y mantener las credenciales fuera de Git con External Secrets Operator. Juntos cierran dos de las brechas más comunes en la supply chain de Kubernetes — imágenes sin verificar y secretos escritos directamente en los manifiestos — sin necesidad de una plataforma nueva ni de atarse a un proveedor.

Contenedores de transporte apilados de distintos colores en una terminal portuaria
Foto: Roy Luck (CC BY 2.0), Wikimedia Commons.

Firma en el build, verifica en el deploy

Cosign, parte del proyecto de código abierto Sigstore, firma y verifica imágenes de contenedor para que un clúster Kubernetes pueda confirmar que una imagen procede realmente de un pipeline de build aprobado antes de ejecutarla. El patrón que importa para los MSP es simple: firma cada imagen en el momento del build, verifica esa firma en la admisión o en el deploy, y rechaza todo lo que no supere el control.

La firma puede hacerse con claves de larga duración que controla el equipo de seguridad, o con el flujo keyless de Sigstore, en el que Fulcio emite un certificado de corta duración que vincula una clave efímera a una identidad OpenID Connect verificada — un sistema de CI o una persona — mientras el registro de transparencia Rekor sella el evento con una marca de tiempo. La verificación ocurre en el punto donde la imagen está a punto de ejecutarse: un admission controller o una puerta de deploy comprueba la firma frente a una identidad o clave aprobada, y bloquea lo que no esté firmado o no sea de confianza antes de que llegue a un clúster gestionado.

Lo que la firma no sustituye

Una firma demuestra procedencia — que un digest concreto viene de un pipeline o una identidad específica — pero no dice nada sobre si ese digest contiene vulnerabilidades conocidas. Cosign está pensado para acompañar a un escáner de imágenes como Trivy o Grype, no para sustituirlo: el escáner evalúa qué hay dentro de la imagen, la firma demuestra de dónde viene. Tratar "firmado" como sinónimo de "seguro" deja la mitad del control sin cubrir.

Mantener los secretos fuera de Git con External Secrets Operator

External Secrets Operator es un controlador de Kubernetes que conecta gestores de secretos externos — entre ellos AWS Secrets Manager, HashiCorp Vault y Azure Key Vault — con los Secrets nativos de Kubernetes, de modo que las credenciales ya no necesitan estar en un repositorio Git ni en un chart de Helm. Vigila un recurso SecretStore o ClusterSecretStore y sincroniza los valores en los Secrets de Kubernetes según una programación, sin que el propio operador tenga que registrar el texto plano.

Limitar cada ExternalSecret al namespace y a la carga de trabajo que realmente lo necesita reduce el radio de impacto si un pod se ve comprometido. El operador sigue dependiendo de los controles de acceso y de la política de rotación del propio gestor de secretos: saca las credenciales del control de versiones, pero no sustituye la seguridad del gestor de secretos.

Por qué esta combinación importa para los MSP

Las flotas Kubernetes gestionadas tienden a acumular ambos problemas a la vez: secretos escritos directamente por comodidad e imágenes descargadas de un registro sin control de firma. Integrar External Secrets en el flujo de deploy elimina la excusa de guardar credenciales en los manifiestos, mientras que una política de admisión de Cosign da al MSP una única puerta auditable para saber si una imagen procede de su propio pipeline.

Ninguna de las dos herramientas es por sí sola un programa de seguridad completo. La verificación de Cosign vale lo que valga la gestión de claves y la confianza en los emisores que hay detrás, y el mínimo privilegio, la segmentación de red y la respuesta a incidentes siguen siendo trabajo aparte. Combinados, sin embargo, los dos controles forman una base repetible que se puede aplicar por tenant, con un proceso de excepción documentado para lo que todavía no cumple.

Los MSP que necesiten demostrar que estos controles resisten una auditoría pueden recurrir a los servicios de ciberseguridad de Altovar, que cubren pruebas de penetración, evaluación de vulnerabilidades, respuesta a incidentes y cumplimiento de NIS2/DORA/GDPR.

Qué hacer

  • Firma cada imagen en el momento del build y vuelve a verificarla en la admisión o en el deploy; nunca confíes solo en la firma del paso de build.
  • Prueba primero la ruta de fallo: confirma que una imagen sin firmar o manipulada se rechaza de verdad antes de confiar en la puerta en producción.
  • Combina Cosign con un escáner de vulnerabilidades como Trivy o Grype, porque una firma válida no equivale a un escaneo limpio.
  • Saca cada credencial de los manifiestos y los charts de Helm y llévala a un SecretStore gestionado por External Secrets Operator.
  • Limita cada ExternalSecret al namespace y a la carga de trabajo que lo necesita, y rota claves y credenciales según un calendario definido.
  • Documenta el proceso de excepción para lo que todavía no cumple, y valida los cambios de política en un clúster que no sea de producción antes de aplicarlos a toda la flota.

Fuentes: GitHub — sigstore/cosign, documentación de Sigstore, External Secrets Operator en GitHub.