En el acelerado ecosistema cloud-native actual, Kubernetes se ha vuelto el estándar de facto para orquestar contenedores. Levantamos pods en cuestión de segundos y, muchas veces, descargamos imágenes desde distintos registros. Pero en esta carrera por innovar, queda una pregunta crítica: ¿realmente sabes qué se está ejecutando en tu cluster?
Si tu respuesta se basa en la confianza o en suposiciones sobre la integridad de las imágenes, lo más probable es que tu cluster esté operando a ciegas, un enfoque arriesgado en una era de ataques cada vez más sofisticados a la cadena de suministro.
A medida que las organizaciones dependen más de los contenedores para empaquetar y desplegar sus aplicaciones, garantizar la integridad y autenticidad de las imágenes que corren en sus clusters se vuelve fundamental. Verificar las imágenes no es un "nice-to-have": es un pilar innegociable de cualquier estrategia sólida de seguridad en Kubernetes.
¿Por qué deberías verificar las imágenes de contenedores?
Las imágenes de contenedores son los bloques con los que se construyen tus aplicaciones de Kubernetes. Encapsulan tu código, sus dependencias y el entorno de ejecución. Sin embargo, esa misma comodidad abre la puerta a vulnerabilidades si las imágenes no se revisan adecuadamente.
Estas son las razones por las que verificar imágenes ya no es opcional:
- 🔓 Ataques a la cadena de suministro: los atacantes apuntan cada vez más a la cadena de suministro de software e inyectan código malicioso en imágenes que parecen legítimas. Sin verificación, te vuelves una víctima en potencia.
- 🐞 Vulnerabilidades conocidas: muchas imágenes se basan en capas que incluyen paquetes desactualizados o vulnerables. Las imágenes sin verificar pueden exponerte a CVEs (Common Vulnerabilities and Exposures) sin que lo notes.
- 🔧 Configuraciones erróneas: las imágenes que corren como root, exponen puertos sin uso o contienen secretos hardcodeados se convierten en puntos de acceso fáciles para los atacantes.
- 🎯 Error humano: los desarrolladores pueden usar por accidente una versión de imagen más antigua o con un nombre similar pero insegura. Sin controles estrictos, esos errores terminan en producción.
- 📋 Incumplimiento normativo: estándares como PCI DSS, SOC 2 e HIPAA exigen pruebas de integridad y procedencia del software. Ejecutar imágenes sin verificar puede traducirse en auditorías fallidas y sanciones regulatorias.
Sin sistemas de verificación robustos, tu cluster de Kubernetes puede convertirse en un entorno sin control, lleno de software no revisado, y exponer a tu organización a un riesgo considerable.
Cómo Kyverno resuelve y simplifica la verificación de imágenes
El ecosistema de Kubernetes ofrece herramientas potentes para dejar atrás la confianza ciega y aplicar una integridad verificable. Una solución que destaca es Kyverno, un motor de políticas diseñado específicamente para Kubernetes.
Kyverno actúa como un admission controller: intercepta las solicitudes a la API y aplica políticas antes de que los workloads se admitan en el cluster. Esto lo vuelve ideal para aplicar políticas de verificación de imágenes en el momento del despliegue.
Principales beneficios de usar Kyverno para verificar imágenes:
- ✅ Verificar firmas de imágenes: aplica firma criptográfica para asegurar que las imágenes son auténticas y no han sido manipuladas.
- 📜 Revisar attestations: valida metadatos firmados sobre la imagen, como el estado del escaneo o la procedencia del build.
- 🔒 Restringir registros: solo permite imágenes desde fuentes confiables.
- 🏷️ Aplicar estándares de etiquetado: asegura que las imágenes usen tags explícitos (por ejemplo, evitar
latest) y sigan convenciones de versionado.
Ejemplos de políticas de Kyverno para verificación de imágenes
Veamos algunos ejemplos reales de políticas. Antes de usarlos, asegúrate de tener Kyverno instalado en tu cluster.
Escenario 1: restringir las imágenes a registros aprobados
Una política sencilla pero eficaz consiste en garantizar que las imágenes solo provengan de los registros confiables de tu organización.
---
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: restrict-image-registries
spec:
validationFailureAction: Enforce # Bloquea los despliegues si la validación falla
rules:
- name: validate-registries
match:
any:
- resources:
kinds:
- Pod
- Deployment
- StatefulSet
- Job
- CronJob
validate:
message: "Las imágenes deben descargarse desde registros aprobados (gcr.io o my.private.registry)."
pattern:
spec:
containers:
- image: "gcr.io/* | my.private.registry/*" # Patrones de registros permitidos
Si se usa una imagen de un registro no aprobado, el despliegue se bloqueará con un mensaje de validación claro.
Escenario 2: garantizar que las imágenes estén firmadas con Cosign
Cosign, un componente clave del proyecto Sigstore, es una herramienta ampliamente adoptada para firmar y verificar criptográficamente artefactos de software, además de almacenar esas firmas y attestations dentro de un registro OCI. Asegúrate de que las claves públicas para la verificación de imágenes estén accesibles, ya sea en Secrets de Kubernetes o vía URL.
Kyverno se integra directamente con Cosign mediante su regla verifyImages para aplicar políticas que validan firmas de imágenes de contenedores y attestations in-toto. Así se garantiza que solo se desplieguen imágenes confiables y verificadas en el cluster de Kubernetes.
Aquí tienes un ClusterPolicy de Kyverno que verifica que todas las imágenes desplegadas en el namespace production estén firmadas con una clave pública específica:
---
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: check-image-signatures
spec:
validationFailureAction: Enforce
background: false
webhookTimeoutSeconds: 30
failurePolicy: Fail
rules:
- name: verify-image-signature
match:
any:
- resources:
kinds:
- Pod
namespaces:
- production
verifyImages:
- imageReferences:
- "registry.example.com/*:*" # Ajusta al patrón de tus imágenes
attestors:
- count: 1
entries:
- keys:
publicKeys: | #La clave pública puede definirse directamente en la política o referenciar un Secret estándar de Kubernetes en otro punto del cluster especificándolo con el formato k8s://<namespace>/<secret_name>. El Secret nombrado debe especificar una clave cosign.pub que contenga la clave pública usada para la verificación.
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEyourPublicKeyContentHere...
-----END PUBLIC KEY-----
Una imagen firmada se puede desplegar con normalidad; en cambio, intentar ejecutar una imagen sin firmar generará un error de política como el siguiente:
Escenario 3: verificar attestations de escaneo de vulnerabilidades
Un aspecto clave para mantener la integridad de la cadena de suministro de software es realizar escaneos periódicos de vulnerabilidades sobre las imágenes. Los escaneos iniciales en el momento del build son un punto de partida, pero deben repetirse a medida que aparecen nuevas vulnerabilidades. Kyverno ayuda a aplicar esto comprobando attestations que demuestran que una imagen ha pasado recientemente por un escaneo de vulnerabilidades.
Aquí tienes un ClusterPolicy de Kyverno tomado de Trivy que aplica una validación sobre las imágenes de los Pods para asegurar que sus escaneos de vulnerabilidades no tengan más de una semana.
---
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: check-vulnerabilities
spec:
validationFailureAction: enforce
webhookTimeoutSeconds: 30
failurePolicy: Fail
rules:
- name: not-older-than-one-week
match:
any:
- resources:
kinds:
- Pod
verifyImages:
- imageReferences:
- "registry.example.com/*:*" # Ajusta al patrón de tus imágenes
attestations:
- predicateType: cosign.sigstore.dev/attestation/vuln/v1
conditions:
- all:
- key: "{{ time_since('','{{metadata.scanFinishedOn}}','') }}"
operator: LessThanOrEquals
value: "168h"
Kyverno bloqueará la creación del pod si la imagen no se ha escaneado recientemente en busca de vulnerabilidades y le falta una attestation de escaneo firmada con Cosign.
Estos son solo algunos ejemplos. La flexibilidad de Kyverno permite un control mucho más granular, desde verificar tags y labels específicos hasta rechazar imágenes con vulnerabilidades de alta severidad a partir de los datos de las attestations.
Verificar las imágenes no es solo una buena práctica: es una necesidad fundamental para operar de forma segura en entornos cloud-native. Herramientas como Kyverno ofrecen una forma potente y flexible de pasar de la confianza ciega a una seguridad verificable. Y cuando se trata de asegurar que tus workloads no solo sean seguros, sino también right-sized, confiables y rentables, plataformas como PerfectScale complementan a las herramientas de seguridad analizando de forma continua los workloads de Kubernetes en busca de oportunidades de optimización, sin poner en riesgo el rendimiento ni el cumplimiento.
Al implementar verificación de firmas de imágenes, validación de attestations y restricciones de registros, puedes construir una defensa sólida frente a un amplio abanico de amenazas dirigidas a la cadena de suministro de software.
Explora la documentación de Kyverno y Cosign para empezar a proteger tus workloads de contenedores hoy mismo. Si quieres saber más o te interesan nuestros servicios, no dudes en escribirnos aquí.