Asegurad vuestra cadena de suministro de imágenes de contenedor
¿Cómo asegurar vuestra cadena de suministro de software?
Asegurar vuestra cadena de suministro de software significa controlar cada artefacto entre una confirmación de código y la producción. En las canalizaciones contenerizadas se reduce a cuatro controles: un registro privado con RBAC, escaneo de CVE, firma criptográfica y una política que bloquee imágenes sin firmar o vulnerables en el despliegue.
Por qué los ataques a la cadena de suministro ahora tienen como objetivo vuestras imágenes de contenedor
SolarWinds, Log4Shell, xz-utils: la canalización de compilación es el nuevo perímetro
Los incidentes de seguridad de software más trascendentales de los últimos años no comenzaron con una brecha de firewall o una contraseña robada. Comenzaron dentro de la propia cadena de suministro de software.
- SolarWinds: el sistema de compilación fue comprometido para inyectar código malicioso en actualizaciones de software firmadas, llegando a agencias gubernamentales de los Estados Unidos y a miles de clientes empresariales en la cadena descendente.
- Log4Shell: un componente vulnerable de código abierto, enterrado en un árbol de dependencias compartido por innumerables proyectos, se convirtió en una vulnerabilidad grave que los atacantes explotaron en miles de organizaciones no relacionadas a la vez.
- xz-utils: el entorno de compilación de un mantenedor de paquetes de confianza se convirtió en un vector de ataque, dado un atacante lo suficientemente paciente como para explotar años de confianza acumulada.
El patrón es el mismo en los tres casos. El proceso de compilación, no la aplicación en ejecución, fue el punto de compromiso.
Una imagen de contenedor es el último artefacto antes de que el resultado de la compilación llegue a producción. También es el último lugar práctico para detectar un componente comprometido y sus dependencias antes de que un exploit cause daños.
Por qué Docker Hub y los registros públicos no son suficientes
Un registro público es público por defecto a menos que paguéis por repositorios privados. No tiene RBAC por equipo, ni aplicación de políticas de CVE, ni verificación de firmas al extraer.
Eso no es una carencia de funcionalidad que se pueda parchear. Es un tipo de producto diferente.
Los registros públicos existen para distribuir software de código abierto a cualquier consumidor que lo desee. El autor del paquete y el consumidor del paquete nunca se conocen, y ninguno de los dos puede verificar mucho sobre el otro.
Controlar exactamente qué imágenes de software tienen permiso para extraer los clústeres de Kubernetes de vuestra organización es un problema completamente diferente.
Un registro privado genérico sin una postura de seguridad documentada tampoco reduce el riesgo de la cadena de suministro de software. El riesgo es concreto: un ataque que logra introducir un componente malicioso en una imagen infecta a todos los clústeres que la extraen.
Ese riesgo se multiplica con cada equipo que comparte el registro. Sin un escaneo sistemático, sin una capa de políticas y sin un registro de auditoría de quién subió qué, cuándo y si estaba firmado, habéis movido imágenes de un registro público sin reducir el riesgo.
El punto de vista del cumplimiento: ISO 27001, SOC 2 e industrias reguladas
Los equipos de seguridad rara vez obtienen presupuesto para este trabajo hasta que una auditoría les obliga a ello. Las auditorías de cumplimiento tratan las imágenes de contenedor no escaneadas como un hallazgo crítico, no como una sugerencia.
La seguridad es una postura que se mantiene, no un producto que se compra, y un auditor evalúa la postura en lugar de la lista de herramientas. La seguridad de la cadena de suministro de software se evalúa como un conjunto de prácticas, y cada práctica necesita pruebas.
ISO 27001, SOC 2 y la mayoría de los estándares de seguridad de industrias reguladas, muchos desarrollados con agencias gubernamentales y organismos de orientación industrial, esperan un escaneo de vulnerabilidades y un control de acceso documentados y sistemáticos en cualquier software que llegue a producción. Las imágenes de contenedor son artefactos de producción como cualquier otro.
Las imágenes de contenedor también almacenan código de aplicación, configuración y, a veces, variables de entorno. Por tanto, los permisos del registro son un control de acceso sobre la propiedad intelectual de software sensible.
Este es exactamente el tipo de mejores prácticas de seguridad que un auditor espera ver documentadas, no asumidas.
La práctica recomendada en cada conjunto de directrices publicado, desde CISA hasta la CNCF, es la misma, y merece la pena aprenderla antes de que una auditoría os obligue a ello:
• Haced de cada control una práctica documentada con un responsable designado.
• Asegurad el entorno de compilación con tanto cuidado como el de ejecución.
• Mantened las dependencias actualizadas para que no se acumulen vulnerabilidades conocidas.
Los auditores quieren pruebas de cada uno de estos puntos, y el centro Identity, Security & Operations de OVHcloud cubre los servicios que las generan.
Los cuatro controles que necesita toda canalización contenerizada
Un marco de trabajo como SLSA (Supply-chain Levels for Software Artifacts) ofrece a los equipos una forma estructurada de medir la madurez de estos controles. No necesitáis adoptar un marco de trabajo completo para obtener el beneficio práctico.
Los niveles SLSA son principalmente útiles como lenguaje compartido con auditores y socios, y merece la pena aprender sobre SLSA solo por eso. Un socio externo declara su nivel, vosotros lo comparáis con el vuestro y nadie envía un cuestionario largo.
Los proveedores publican cada vez más uno, por lo que pedirle a un socio el suyo es una pregunta de adquisición normal.
El análisis estático, o SAST, se ejecuta en el código fuente antes de que se compile nada. Detecta una clase de vulnerabilidades diferente a la que detecta el escaneo de imágenes, y pertenece a una etapa anterior de la cadena, junto con el análisis de composición de software de vuestras dependencias.
SAST y el escaneo de imágenes son complementarios, no sustitutos. Ninguno detecta lo que el otro está diseñado para encontrar. Tres capas cubren toda la cadena:
1. Ejecutad SAST en vuestro propio código fuente.
2. Ejecutad el análisis de composición de software en las dependencias externas.
3. Ejecutad el escaneo de imágenes en el artefacto compilado.
Si omitís una de las tres, dejaréis sin medir toda una clase de vulnerabilidades, independientemente de lo que informen las otras herramientas.
Los cuatro controles siguientes se aplican en el momento en que una compilación genera una imagen de contenedor, el artefacto central de la cadena.
Almacenad las imágenes en un registro privado controlado por RBAC
El control fundamental de una cadena de suministro de software segura es un registro que esté cerrado por defecto, con RBAC por proyecto o por equipo. No un bucket compartido en el que todos puedan subir, ni un registro público con imágenes visibles por defecto.
Las cuentas de robot hacen el resto del trabajo:
• Limitad cada cuenta de robot a un único proyecto.
• Dad a los pasos de compilación permisos de subida de solo escritura, y a los pasos de despliegue permisos de extracción de solo lectura.
• Ejecutad un proyecto por equipo, de modo que un proyecto comprometido permanezca contenido.
• Aplicad una política central en todos los proyectos, auditada de forma centralizada.
• Mantened las credenciales personales y de administrador totalmente fuera de las compilaciones automatizadas.
Escanead cada imagen en busca de CVE en el envío y en la extracción
El escaneo de vulnerabilidades debe realizarse en dos puntos:
• En el envío, para que una nueva imagen se escanee en el momento en que se compila.
• En la extracción, para que se vuelva a ejecutar una comprobación de políticas antes de que una imagen más antigua se despliegue frente a una base de datos de vulnerabilidades más reciente.
Una imagen que estaba limpia en marzo puede contener tres vulnerabilidades conocidas en junio, y solo una comprobación en el momento de la extracción las detectará.
El escaneo asíncrono en el envío no ralentiza la compilación. El escaneo se ejecuta en paralelo mientras la canalización continúa, y los resultados están disponibles antes de que la imagen se promocione hacia producción.
Firmad los artefactos con Cosign o Notary v2
Firmar una imagen registra criptográficamente quién la construyó y confirma que no ha sido manipulada durante el tránsito. Establece una cadena de confianza desde el sistema de construcción hasta el clúster.
La confianza es lo que un atacante busca realmente. La puerta trasera de xz-utils funcionó porque la confianza en un mantenedor se había acumulado durante años, y los atacantes son lo suficientemente pacientes como para explotar a un mantenedor en lugar de a un cortafuegos.
Cosign, parte del proyecto Sigstore, y Notary v2 son los dos enfoques de código abierto dominantes para la firma de imágenes de contenedores hoy en día.
Sin una firma y una política que la verifique, no hay forma de demostrar después de un incidente que la imagen que se ejecuta en producción es exactamente el artefacto que vuestra canalización construyó. Una imagen sin firmar y una manipulada son indistinguibles en el momento del despliegue.
Aplicad una política de despliegue antes de que las imágenes lleguen a Kubernetes
El escaneo y la firma solo importan si algo los hace cumplir. Un controlador de admisión de Kubernetes, siendo Kyverno u OPA Gatekeeper las dos opciones comunes, comprueba cada imagen en el momento del despliegue y rechaza cualquier cosa que no cumpla la política:
• CVE críticas sin resolver.
• Una firma Cosign ausente o no válida.
• Una imagen de un registro no aprobado.
Ese es el control que hace que los demás sean exigibles, y el que un ataque tiene que superar. Convierte el escaneo de imágenes de una métrica reportada en una barrera estricta, de modo que ninguna imagen no escaneada llegue a producción, que es el requisito de cumplimiento real.
Los dos puntos de aplicación son complementarios. El registro bloquea el envío, el clúster bloquea el despliegue, y un ataque que supere uno sigue encontrándose con el otro. Ambos se sitúan sobre un clúster que no tenéis que gestionar vosotros mismos cuando ejecutáis Managed Kubernetes Service de OVHcloud.
Estos cuatro controles técnicos se sitúan junto a, no en lugar de, las prácticas organizativas que reducen el riesgo de forma más amplia. Las prácticas de este tipo son baratas en comparación con un incidente, y cada una es una práctica que un auditor puede verificar.
Estas son las prácticas que convierten un diseño seguro en un sistema seguro, y cada una es una práctica central, no un extra opcional:
• Actualizad regularmente las dependencias y los componentes de terceros para protegeros contra exploits conocidos.
• Limitad el acceso a sistemas de compilación sensibles y claves de firma.
• Formad a los empleados y realizad formación de concienciación sobre seguridad, para que los ingenieros reconozcan un paquete comprometido o un intento de phishing contra una cuenta de mantenedor.
• Realizad simulacros contra un plan de respuesta a incidentes, para que un equipo sepa cómo responder rápidamente cuando un control falla.
• Verificad la integridad del software continuamente en lugar de asumirla, para que cada artefacto permanezca asegurado mediante una comprobación en lugar de por costumbre.
Cualquier posible brecha de seguridad en esta lista suele ser una brecha de proceso, no de herramientas.
Cada componente de software que incorporáis, y cada componente transitivo que hay debajo, es una decisión que alguien tomó una vez y que rara vez vuelve a revisar. Una aplicación moderna incluye cientos de estos componentes, la mayoría de una parte externa a la que nadie conoce.
El inventario de componentes es, por tanto, la práctica de la que depende todo lo demás. La gestión de dependencias, saber qué software y qué componentes provienen de un tercero, es lo que hace que un SBOM (lista de materiales de software) sea útil una vez que tenéis uno.
Un SBOM enumera cada componente y cada versión, lo que convierte un nuevo aviso de CVE en una consulta de cinco minutos en lugar de una semana de arqueología. Sin uno, la respuesta honesta a si estáis expuestos es que nadie lo sabe.
Cómo cierra la brecha OVHcloud Managed Private Registry
Harbor bajo el capó: Graduado por la CNCF, estándar OCI, código abierto
Managed Private Registry es una instancia totalmente gestionada de Harbor, una tecnología de código abierto graduada por la CNCF creada para el almacenamiento de contenedores y gráficos de Helm, con la seguridad como una característica de primer nivel en lugar de un complemento.
Autohospedar Harbor significa ejecutar y parchear PostgreSQL, Redis, los servicios principales de Harbor y el escáner, además de TLS y las actualizaciones de cada uno de esos componentes.
OVHcloud elimina esa capa operativa. Vosotros creáis un registro, enviáis imágenes y configuráis la política, mientras que la infraestructura de Harbor subyacente es responsabilidad de OVHcloud. Eso libera a vuestro equipo de ciberseguridad para el modelado de amenazas y la resiliencia de la cadena de suministro en lugar de parchear una base de datos.
Como Harbor es de código abierto y se basa en estándares, no existe dependencia de un proveedor. Las imágenes residen en el formato OCI estándar, por lo que la migración a un Harbor autohospedado u otro registro compatible con OCI no requiere ningún paso de conversión ni deshacer ningún formato de extracción propietario.
Esa transparencia es, en sí misma, una propiedad de seguridad. Una comunidad global de revisores, no un único proveedor, revisa el código que ejecuta vuestro registro.
Un proyecto central con muchos revisores detecta una confirmación maliciosa más rápido que uno cerrado, y la inteligencia sobre amenazas acerca de las vulnerabilidades de Harbor o Trivy os llega a través de los mismos canales públicos en los que confían todos los demás usuarios.
Escaneo de vulnerabilidades con Trivy: Detección de CVE al subir y extraer
OVHcloud Managed Private Registry incluye Trivy, el escáner integrado de Harbor, activado a nivel de proyecto.
Configurad el escaneo al subir para que cada imagen se compruebe al llegar, y luego estableced un umbral de gravedad de CVE. Avisar en ALTA, bloquear en CRÍTICA es una política inicial recomendada.
Un escaneo en el momento de la extracción vuelve a comprobar una imagen antigua frente a una base de datos de vulnerabilidades más reciente.
Una política de despliegue de Harbor impide extraer imágenes con CVE CRÍTICAS sin resolver a los espacios de nombres de producción, que es lo que hace que el resultado del escaneo sea procesable en lugar de informativo.
Firma de imágenes con Cosign y Notary v2
El servicio está basado en Harbor, por lo que admite el escaneo de vulnerabilidades y el almacenamiento de gráficos Helm documentados para el producto.
La firma de imágenes en sí se ejecuta a través de herramientas estándar de código abierto Cosign en vuestra canalización CI/CD, apuntando al registro de OVHcloud en lugar de a un servicio de firma propietario.
Aplicación de políticas: bloquead imágenes con CVE críticos antes del despliegue
La política del lado del registro, bloquear ante CVE CRÍTICAS y requerir una firma válida, es solo la mitad de la historia de la aplicación.
La otra mitad se ejecuta en el propio Kubernetes. Una política de admisión de Kyverno o OPA Gatekeeper rechaza cualquier imagen sin una firma Cosign válida, o con una vulnerabilidad grave sin resolver, independientemente de cómo se haya desplegado o por qué actor.
Juntos proporcionan un bloqueo de CVE aplicado por políticas de extremo a extremo. Es una configuración que establecéis deliberadamente, no una garantía automática.
Almacenamiento de Helm charts (compatible con OCI)
Los Helm charts se almacenan en el mismo formato compatible con OCI que las imágenes de contenedor, en la misma estructura de proyecto, con las mismas cuentas RBAC y robot.
Los equipos que empaquetan despliegues como Helm charts obtienen un registro para ambos tipos de artefactos, en lugar de un repositorio de charts separado que asegurar y mantener.
Conectando vuestra canalización CI/CD (GitHub Actions, GitLab CI, Tekton)
Cuentas de robot: envío de solo escritura para compilaciones, extracción de solo lectura para despliegues
Cread un proyecto de Harbor por equipo o aplicación y, a continuación, emitid cuentas de robot con el alcance exacto que necesite cada etapa: solo escritura para la etapa de compilación, solo lectura para la etapa de despliegue.
Nunca integréis credenciales de administrador o personales, o el archivo de clave de una cuenta de robot,
en una definición de compilación. Una cuenta de robot de solo lectura filtrada es un incidente contenido. Una credencial de administrador filtrada en manos de un actor externo no lo es.
Para las claves de firma de Cosign específicamente, OVHcloud OVHcloud Key Management Service admite el uso de claves propias (BYOK) con almacenamiento respaldado por HSM FIPS 140-2, lo que mantiene vuestras claves fuera de los portátiles de los desarrolladores y de los ejecutores de CI.
Ejemplo de GitHub Actions: construir, escanear, firmar y enviar
Una única etapa cubre todo el control:
1. Construid la imagen.
2. Enviadla con una cuenta de robot de solo escritura.
3. Esperad el resultado del escaneo de Trivy.
4. Firmad con Cosign solo si el escaneo supera el umbral de CVE configurado.
Esta secuencia mantiene una barrera estricta entre la existencia de una imagen y que una imagen sea lo suficientemente fiable como para firmarla, en lugar de firmarla incondicionalmente en el momento de la construcción.
El mismo patrón se aplica tanto si la construcción se ejecuta en GitHub Actions, GitLab CI o Tekton. Solo cambia la sintaxis para llamar al registro y al escáner, independientemente del lenguaje de programación en el que esté escrita vuestra aplicación.
Políticas de admisión de Kyverno en Managed Kubernetes Service
En OVHcloud Managed Kubernetes Service, una política de Kyverno, definida como un archivo de política estándar de Kubernetes, comprueba cada especificación de pod entrante en busca de una firma Cosign válida y rechaza el despliegue si la firma falta o no es válida.
Combinado con la política de CVE del lado del registro, esto cierra el círculo entre lo que construís y lo que el clúster puede ejecutar. Una imagen sin firmar o sin escanear nunca se inicia, independientemente de quién haya solicitado el despliegue.
Cadena de suministro soberana: por qué importa la jurisdicción de vuestro registro
Las imágenes de contenedor conllevan PI, y con ellas la exposición a la Ley CLOUD
Una imagen de contenedor agrupa código de aplicación, capas de configuración y, a veces, variables de entorno: una parte significativa de la propiedad intelectual de vuestra organización. Un registro central es donde se concentra esa propiedad intelectual, por lo que su jurisdicción es importante. Almacenar esa imagen con un proveedor con sede en EE. UU., incluso uno con centros de datos en la UE, la coloca bajo la jurisdicción de la Ley CLOUD de EE. UU., porque la exposición sigue a la empresa matriz, no a la ubicación de almacenamiento. La misma lógica se aplica a cualquier despliegue de AWS ECR, Google Artifact Registry o Docker Hub: La jurisdicción de la Ley CLOUD de EE. UU. se aplica independientemente de la región.
Sede europea, sin empresa matriz en EE. UU., RGPD por jurisdicción
Una imagen de contenedor agrupa código de aplicación, capas de configuración y, a veces, variables de entorno: una parte significativa de la propiedad intelectual de vuestra organización.
Un registro central es donde se concentra esa propiedad intelectual, por lo que su jurisdicción es importante.
Almacenar esa imagen con un proveedor con sede en EE. UU., incluso uno con centros de datos en la UE, la sitúa bajo la jurisdicción de la Ley CLOUD de EE. UU., porque la exposición sigue a la empresa matriz en lugar de a la ubicación de almacenamiento.
Lo mismo se aplica a cualquier registro operado por un proveedor con sede en EE. UU.: La jurisdicción de la Ley CLOUD de EE. UU. se aplica independientemente de la región.
Sede europea, sin empresa matriz en EE. UU., RGPD por jurisdicción
OVHcloud es un operador europeo sin empresa matriz estadounidense, por lo que no existe exposición estructural a la CLOUD Act en nada de lo almacenado en el registro.
La infraestructura del registro se ejecuta bajo el RGPD por jurisdicción en lugar de por compromiso político.
La protección legal proviene de dónde se encuentran la empresa y la infraestructura, no de una promesa contractual añadida sobre una infraestructura que una autoridad extranjera aún podría obligar a revelar.
Ruta de extremo a extremo: De Managed Private Registry a Managed Kubernetes Service
Cread un proyecto de Registro Privado Gestionado, subid una imagen y activad el escaneo y la firma. MKS Free cubre el desarrollo y la puesta en escena sin coste alguno, por lo que podéis validar toda la cadena de políticas antes de que el tráfico de producción dependa de ella. Para múltiples clústeres de producción, sectores regulados o grupos de nodos GPU, un arquitecto de soluciones de OVHcloud os ayudará a dimensionarlo. El centro de orquestación de contenedores es donde aprender el resto.
Disponibilidad 3-AZ en París y Milán, SLA de disponibilidad del 99,99 % en MKS estándar
El registro se ejecuta en 3-AZ en París con alta disponibilidad integrada. Un fallo en una sola zona no detiene ni vuestras compilaciones ni vuestros despliegues, lo cual es importante porque una interrupción del registro bloquea ambos.
El servicio gestionado de Kubernetes estándar se ejecuta en 3-AZ en París y Milán con un SLA de disponibilidad del 99,99 %, por lo que el registro y el clúster que extrae de él comparten una misma postura de disponibilidad en lugar de que uno sea el eslabón débil.
MKS Free para empezar, MKS Standard para producción
Managed Kubernetes Service tiene un nivel gratuito para desarrollo y pruebas, suficiente para validar toda la cadena de suministro de software: registro, escaneo, firma y política de admisión, antes de comprometerse con un clúster de producción.
El anclaje de versiones en vuestros archivos de política mantiene esa validación reproducible.
Cuando estéis listos para el tráfico de producción, MKS Standard añade el nivel de 3 zonas de disponibilidad con un SLA de disponibilidad del 99,99%, y las mismas políticas de Kyverno u OPA Gatekeeper se trasladan sin cambios a ambos niveles.
Los equipos que ejecutan varios clústeres añaden Managed Rancher Service encima para obtener un plano de control único para todos ellos.
Empezad: activad vuestro registro y enviad imágenes seguras hoy mismo
Cread un proyecto de Registro Privado Gestionado, subid una imagen y activad el escaneo y la firma. MKS Free cubre el desarrollo y la puesta en escena sin coste alguno, por lo que podéis validar toda la cadena de políticas antes de que el tráfico de producción dependa de ella. Para múltiples clústeres de producción, sectores regulados o grupos de nodos GPU, un arquitecto de soluciones de OVHcloud os ayudará a dimensionarlo. El centro de orquestación de contenedores es donde aprender el resto.