Firma de imágenes de contenedor: comparación entre Sigstore, Notary y Docker Content Trust

En el ecosistema de software actual, la contenerización se ha convertido en un método popular para empaquetar e implementar aplicaciones. Junto con esta tendencia creciente, garantizar la seguridad de las cadenas de suministro de software se ha vuelto una preocupación fundamental para empresas de todos los tamaños. Implementar prácticas recomendadas, como firmar y verificar imágenes para mitigar los ataques de intermediario (MITM) y validar su autenticidad y vigencia, desempeña un papel fundamental en la protección de la integridad de la cadena de suministro de software.

Firmar imágenes de contenedor implica usar técnicas criptográficas que vinculan la imagen con una entidad u organización específica y crean una cadena de confianza. Esto ayuda a garantizar la autenticidad e integridad del código dentro de las imágenes.

Además, firmar imágenes de contenedor ayuda a establecer la propiedad y la responsabilidad. Las firmas pueden ser útiles para las auditorías, ya que permiten a las organizaciones rastrear y verificar el origen de las imágenes y los cambios que se les han hecho con el tiempo, además de aplicar estándares y regulaciones de cumplimiento específicos.

En este artículo, compararemos tres soluciones populares para firmar contenedores: Sigstore Cosign, Notary v2 y Docker Content Trust (DCT), también conocido como Notary v1. Conocerás sus características, capacidades e idoneidad para proteger las cadenas de suministro de imágenes de contenedor. Al final, también encontrarás un tutorial que te enseñará a integrar una de estas herramientas en tu flujo de trabajo.

Herramientas para firmar contenedores

Cuando se trata de firmar tus imágenes de forma segura, hay numerosas herramientas disponibles. Tres de las más destacadas son Cosign, Notary y DCT; cada una tiene especificaciones y requisitos diferentes.

Sigstore Cosign

Cosign es una herramienta que permite firmar, verificar y proteger software de forma sencilla y segura. Se distribuye bajo la licencia Apache 2.0 y se basa en el estándar Sigstore, que garantiza la integridad y autenticidad de las imágenes de contenedor. Cosign está ganando popularidad rápidamente, con más de 3400 estrellas en GitHub.

Cosign es conocido por permitir la firma sin claves mediante la autoridad de certificación Sigstore Fulcio y el registro de transparencia inmutable Rekor, con una identidad OpenID Connect (OIDC) autenticada. Este enfoque aprovecha una infraestructura invisible, lo que significa que los usuarios no tienen que preocuparse por administrar o mantener claves. Cosign simplifica el proceso al generar claves efímeras, lo que facilita verificar y firmar la autenticidad de imágenes y blobs firmados.

Docker Content Trust

Docker desarrolló Docker Content Trust (DCT) en 2015 y, posteriormente, lo donó a la Cloud Native Computing Foundation (CNCF) como el proyecto Notary; actualmente, es un proyecto en incubación.

DCT permite firmar y verificar imágenes de contenedor, al tiempo que garantiza la integridad y autenticidad de etiquetas de imagen específicas mediante la verificación del cliente o en tiempo de ejecución.

Notary v1 funciona agregando tu clave pública al registro y firmando la imagen con su clave privada correspondiente antes de subirla. Luego, los usuarios pueden verificar la imagen comparando la clave pública con los datos obtenidos mediante el grupo de comandos del registro. Además, puedes automatizar las cadenas de suministro de software firmando el contenido como parte del proceso de lanzamiento.

Notary v2

El sistema de firma Notary v2 es una versión nueva y mejorada que busca superar las limitaciones de su predecesor. Con Notation y Notary v2, los usuarios pueden crear e integrar su propia implementación de las especificaciones en sus flujos de trabajo de firma y verificación para firmar varios artefactos (por ejemplo, imágenes de contenedor, listas de materiales de software y resultados de análisis). Esto es posible gracias a un grupo formado en diciembre de 2019, cuyo objetivo es mejorar la experiencia de firma de imágenes y resolver problemas como la compatibilidad con varios registros y el traslado de imágenes entre registros con la implementación original de v1.

Notary v2 es relativamente nuevo y se lanzó en diciembre de 2022. Busca funcionar como una especificación intersectorial y compatible con distintos registros para firmar y verificar cualquier imagen de Open Container Initiative (OCI) o artefacto de registro. El proyecto sigue en desarrollo y se agregarán nuevas capacidades en el futuro.

Comparación entre Cosign, Notary v2 y Docker Content Trust

En este artículo, analizaremos cuatro características clave que te ayudarán a determinar qué herramienta se adapta mejor a tus necesidades:

1. El modelo de delegación de confianza es el mecanismo que se usa para establecer y distribuir la confianza entre los artefactos y el registro, a fin de garantizar su integridad y autenticidad.

2. La transparencia y auditabilidad consisten en la capacidad de observar y verificar acciones y cambios dentro del sistema para garantizar la responsabilidad y la integridad.

3. La facilidad de uso abarca la simplicidad y facilidad de uso de las herramientas de firma, que permiten adoptarlas e integrarlas fácilmente.

4. El soporte de la comunidad incluye el nivel de participación, colaboración y recursos que ofrece la comunidad en torno al sistema, para garantizar el desarrollo continuo y la asistencia.

Cada uno de estos factores puede influir considerablemente en la eficacia de cada herramienta. En las siguientes secciones, revisaremos cada categoría y evaluaremos las herramientas según estos factores.

Modelo de delegación de confianza

Cosign usa un modelo descentralizado y federado de delegación de confianza, con una raíz de confianza formada por certificados y claves públicas proporcionados por el proyecto Sigstore. The Update Framework (TUF) se usa para distribuir y obtener material de claves. La raíz de confianza de Sigstore también se usa para verificar las pruebas de inclusión en Rekor.

En cambio, Notary v2 y v1 usan un modelo jerárquico de delegación de confianza que implica distribuir imágenes mediante TUF. En este modelo, se utiliza un almacén de confianza para guardar identidades confiables.

Para producir artefactos en v2, los usuarios o administradores configuran la política de confianza para definir qué identidades se consideran confiables. La autenticidad de los artefactos firmados se determina en función de la confianza derivada de las identidades del almacén de confianza y de la política de confianza.

En v1, DCT usa una clave sin conexión como fuente de confianza para las etiquetas de imagen. La confianza se delega a claves de repositorio o de etiquetado, mientras que las claves administradas por el servidor proporcionan seguridad adicional. Este modelo permite establecer distintos niveles de confianza dentro del sistema para aplicar distintas políticas de seguridad y controles de acceso.

En resumen, como Cosign prioriza la confianza descentralizada y federada con una raíz de confianza proporcionada por Sigstore, es una buena opción para delegar confianza. Implementa un esquema de descubrimiento basado en etiquetas y es compatible con la mayoría de los registros de producción. En cambio, deberías elegir Notary v1 cuando no necesites compatibilidad con varios registros, ya que no hay interoperabilidad entre ellos. Si necesitas interoperabilidad, v2 la ofrece y permite distribuir la confianza entre distintos registros.

Transparencia y auditabilidad

En cuanto a transparencia y auditabilidad, Sigstore ofrece un sistema seguro y transparente para las actualizaciones de software, ya que almacena todas las firmas en un registro público. Esto permite que las organizaciones verifiquen fácilmente la autenticidad de las actualizaciones de software. Además, Rekor permite auditar públicamente todos los eventos de firma. Esto ayuda a garantizar la responsabilidad y la confianza en la cadena de suministro de software.

En cambio, DCT tiene algunas desventajas. Solo admite una firma por imagen, lo que significa que, si el proveedor ya firmó la imagen en Docker Hub, no puedes agregar tu propia firma para indicar que es adecuada para tu organización. Esto puede limitar tu flexibilidad y control sobre la cadena de suministro de software.

Por su parte, Notary v2 adopta un enfoque más integral para mantener la confianza en todo el ecosistema. Pone en duda la suposición de que las imágenes obtenidas directamente de Docker Hub son seguras por naturaleza. Al admitir varias firmas, Notary v2 permite validar la seguridad de las imágenes y que las organizaciones agreguen su propio sello de aprobación, lo que garantiza un mayor nivel de confianza en la cadena de suministro de software.

Al momento de publicar este artículo, Notary v2 1.0.0 está en fase de versión candidata, pero aún no cuenta con una versión general. Por eso, en entornos nuevos y complejos, Sigstore puede ser una mejor opción gracias a su madurez e integraciones.

Facilidad de uso

Cosign busca ofrecer una experiencia fácil de usar al simplificar la administración de claves y el proceso de firma. Además, los desarrolladores pueden integrarlo fácilmente en sus flujos de trabajo actuales mientras crean imágenes. La firma sin claves elimina la complejidad de administrar claves y, gracias al par de claves pública y privada generado por Cosign, los pasos para implementarla son sencillos.

En cambio, Notary se integra a la perfección con el ecosistema de contenedores de Docker y ofrece herramientas de línea de comandos y API para firmar y verificar contenedores. Sin embargo, como es relativamente nuevo, no es compatible con muchos clientes, excepto Notation. Además, en ambas versiones de Notary hay que administrar muchas claves, por lo que es necesario conocer bien TUF.

Por su parte, DCT está estrechamente integrado con Docker, lo que facilita habilitar la firma y verificación de imágenes con comandos intuitivos. Sin embargo, no funciona entre distintos registros y los datos de firma se pierden al obtener una imagen pública y subirla a un registro privado sin un servidor Notary asociado. Además, para configurar un servicio Notary se necesitan un servidor Notary, un firmante Notary, un cliente Notary y una base de datos MySQL, además de mTLS (TLS mutuo) entre el servidor y el firmante Notary. Esto suele requerir un esfuerzo adicional y, según se dice, desaparecerá a medida que v2 se generalice.

En cuanto a la facilidad de uso, Cosign parece tener ventaja gracias a su enfoque intuitivo, la administración simplificada de claves y su integración con los flujos de trabajo existentes. Notary v2 también ofrece integración y herramientas de línea de comandos, pero configurarlo y administrarlo requiere más esfuerzo y conocimientos que DCT. Sin embargo, incluye docker trust, que es muy fácil de usar.

Soporte de la comunidad

Todos los proyectos forman parte de la CNCF, por lo que cuentan con un buen soporte de la comunidad. Sin embargo, Cosign también ha recibido el respaldo de socios del sector y cuenta con una comunidad activa de colaboradores que garantizan el desarrollo continuo, el soporte y la colaboración. Notary también es un proyecto de código abierto con un sólido soporte de la comunidad y se usa ampliamente en el ecosistema de Docker, donde se beneficia de las contribuciones y comentarios de una gran base de usuarios. Como el proyecto v2 es relativamente nuevo, no cuenta con tanta documentación ni tantos tutoriales como las otras soluciones, lo que puede dificultar que los nuevos usuarios aprendan a usar v2 con interfaces de línea de comandos como Notation.

DCT forma parte de la plataforma Docker y se beneficia de la amplia comunidad de Docker. Ha ganado mucha popularidad y cuenta con un sólido ecosistema de herramientas e integraciones, lo que facilita su habilitación. Además, hay numerosos tutoriales para ayudarte a comenzar.

Y el ganador es…

La elección del ganador depende de los requisitos, las prioridades y las limitaciones específicas de la organización o el sistema con el que trabajas. Sigstore es una buena opción para las organizaciones que priorizan actualizaciones de software seguras y transparentes para distintos artefactos, incluidos los gráficos de Helm y las imágenes. Cuenta con un excelente soporte de la comunidad y funciones como la interoperabilidad entre registros, lo que lo convierte en una gran opción para la mayoría de las organizaciones. Además, la mayoría de los registros de contenedores admiten el formato de firma.

En comparación, DCT destaca en situaciones donde la simplicidad y la integración fluida con Docker son esenciales. Su estrecha integración con Docker y sus comandos intuitivos facilitan la firma y verificación de imágenes, sin necesidad de modelos de confianza complejos ni de interoperabilidad entre distintos registros.

Notary v2 ofrece una solución más completa para mantener la confianza en la cadena de suministro de software y aborda las limitaciones de DCT. Sin embargo, como todavía está en desarrollo, puede requerir una evaluación y planificación cuidadosas para implementarlo en una organización. El proceso de configuración y la administración de certificados TLS y claves TUF pueden ser complejos, exigir una curva de aprendizaje más pronunciada y convertirse en una carga operativa si no se configuran correctamente. Además, no todos los registros son compatibles, por lo que quizá tengas que hacer algunas concesiones si decides usarlo.

Cómo firmar con Cosign

Ahora que sabes un poco más sobre Cosign, Notary y DCT, iremos un paso más allá y usaremos una de estas herramientas: Cosign. Para este ejemplo, usaremos la imagen de referencia simple de Docker registry:2 para ejecutar un registro sencillo. En un escenario real, usarías un registro administrado como Harbor, Amazon ECR, Docker Hub, etc.

Requisitos previos

Antes de comenzar, necesitas tener instaladas las siguientes herramientas:

• Cosign: la herramienta que usarás para firmar y verificar imágenes de contenedores.

• Docker: una herramienta para crear, ejecutar y administrar contenedores Docker.

Cuando tengas instaladas ambas herramientas, ¡ya puedes comenzar!

Configurar un registro

Para almacenar tus imágenes, debes crear una instancia del registro de la imagen de referencia de Docker registry:2.

docker run -d -p 15000:5000 --name registry registry:2

Nota: Aquí vinculamos el puerto local 15000 para evitar conflictos, especialmente en equipos Mac OS, donde versiones recientes usaron el puerto 5000 para los servicios de AirDrop. Si quieres, puedes cambiarlo por cualquier puerto disponible en tu estación de trabajo, pero asegúrate de usar el mismo puerto en los comandos siguientes.

Enviar una imagen al registro

Para firmar una imagen de Docker y enviarla al registro, sigue estos pasos:

Descarga cualquier imagen de un registro público (en este ejemplo, usamos BusyBox):

docker pull busybox

Este comando obtiene la imagen de BusyBox del registro público de Docker.

A continuación, etiqueta la imagen con la dirección IP de tu registro local:

docker tag busybox localhost:15000/library/busybox:latest

Luego, para subir la imagen, envíala firmada a tu registro de Harbor:

docker push localhost:15000/library/busybox:latest

Este comando envía la imagen etiquetada a tu registro de Harbor mediante el comando docker push. En la respuesta, deberías ver un resumen sha256 similar al siguiente:

The push refers to repository [localhost:15000/busybox]
3694737149b1: Pushed
latest: digest: sha256:1fa89c01cd0473cedbd1a470abb8c139eeb80920edf1bc55de87851bfb63ea11 size: 528

Copia el valor del resumen, desde la parte sha256: hasta el final de la cadena (no incluyas el espacio ni el valor de “size” que aparece después). Este es el hash criptográfico de la imagen, que usaremos en el siguiente paso para asegurarnos de que firmamos exactamente la imagen que acabamos de enviar.

Una vez que completes estos pasos, habrás enviado correctamente una imagen de Docker a tu registro, donde estará disponible para su implementación y distribución en tu entorno. Sin embargo, aún debes firmarla.

Firmar la imagen enviada

Antes de firmar una imagen de contenedor enviada mediante Cosign, debes generar claves públicas y privadas. Ejecuta el siguiente comando para generar el par de claves para la firma:

cosign generate-key-pair

Después de ejecutar el comando anterior, se te pedirá que ingreses una contraseña para la clave privada. Ingresa una contraseña y confírmala. La clave privada se guarda en un archivo llamado cosign.key, y la clave pública, en cosign.pub. Asegúrate de guardar de forma segura la clave privada y la contraseña que configuraste.

A continuación, usa el comando cosign sign para firmar la imagen de esta manera:

cosign sign --key cosign.key localhost:15000/library/busybox@[sha256 digest]

Si cambiaste de directorio, reemplaza cosign.key por la ruta al archivo de tu clave privada y [sha256 digest] por el valor hash completo que copiaste en el paso anterior. Se te pedirá que ingreses la contraseña de la clave privada; ingrésala para continuar.

Al firmar la imagen con Cosign, garantizas que esté actualizada, sea auténtica y mantenga su integridad. Esto agrega una capa adicional de seguridad a tus imágenes de contenedores y ayuda a mantener la confianza en tu cadena de suministro de software.

Verificar la imagen firmada

Para verificar la imagen firmada, usa el comando integrado cosign verify de esta manera:

cosign verify --key cosign.pub localhost:15000/library/busybox@[sha256 digest]

Lo más probable es que se te hagan un par de preguntas de Sí/No sobre el uso de un registro privado y la aceptación de los términos de uso del proyecto Sigstore. Léelas y responde según corresponda.

WARNING: "localhost:15000/library/busybox" appears to be a private repository, please confirm uploading to the transparency log at "https://rekor.sigstore.dev"
Are you sure you would like to continue? [y/N] y

	The sigstore service, hosted by sigstore a Series of LF Projects, LLC, is provided pursuant to the Hosted Project Tools Terms of Use, available at https://lfprojects.org/policies/hosted-project-tools-terms-of-use/.
…
By typing 'y', you attest that (1) you are not submitting the personal data of any other person; and (2) you understand and agree to the statement and the Agreement terms at the URLs listed above.
Are you sure you would like to continue? [y/N] y

Cuando la firma se valide correctamente, verás un mensaje de confirmación que te asegura que la imagen está firmada y verificada de forma segura. El mensaje de confirmación se ve así:

Verification for localhost:15000/library/busybox@sha256:1fa89c01cd0473cedbd1a470abb8c139eeb80920edf1bc55de87851bfb63ea11 --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The signatures were verified against the specified public key

[{"critical":{"identity":{"docker-reference":"localhost:15000/library/busybox"},"image":{"docker-manifest-digest":"sha256:1fa89c01cd0473cedbd1a470abb8c139eeb80920edf1bc55de87851bfb63ea11"},"type":"cosign container image signature"},"optional":{"Bundle":{"SignedEntryTimestamp":"MEUCIQC9yxeo0hGggaWFwBKe4ERHz62emuyqIKNqa1kbPMvNqgIgVea7Fu1zFMqXGYWbacV+gJrVLDUTbchiDdKqcUpEgRk=","Payload":{"body":"eyJhcGlWZXJzaW9uIjoiMC4wLjEi
…

Este mensaje de confirmación es fundamental para mantener una postura de seguridad sólida en tu organización.

Firmar otros artefactos

Aunque las imágenes de contenedores son un componente fundamental de las cadenas de suministro de software, firmar otros artefactos de software es igual de importante para garantizar la seguridad de extremo a extremo. Además de las imágenes de contenedores, distintos tipos de artefactos de software, como ejecutables, archivos Java Archive (JAR), paquetes y listas de materiales de software (SBOM), también pueden beneficiarse del proceso de firma. Por ejemplo, aquí tienes un tutorial sobre cómo Cosign permite firmar SBOM.

La firma de otros artefactos ofrece los mismos beneficios que ya conociste, como integridad, vigencia y procedencia, y te ayuda a cumplir con requisitos de cumplimiento, auditoría o referencia. Sin embargo, es importante tener en cuenta que el proceso quizá no sea tan sencillo como firmar un contenedor. Por ejemplo, las SBOM se firman con Cosign después de adjuntarlas a la imagen del contenedor alojada en un registro.

Para otros artefactos, como los archivos JAR, puedes usar herramientas como Jarsigner. Esto hace que el proceso sea un poco más complejo que la firma tradicional de imágenes, ya que debes administrar esa complejidad mediante algunos pasos adicionales, como generar, almacenar, trasladar y usar claves y firmas de forma segura.

Conclusión

Aunque el proceso de firma de distintos artefactos puede agregar complejidad, es fundamental entender que esta complejidad se introduce para mejorar la seguridad, la integridad y el cumplimiento de los artefactos de software. Al incorporar firmas digitales y seguir las prácticas recomendadas para administrar claves, las organizaciones pueden establecer confianza, cumplir los requisitos normativos y facilitar las auditorías y las consultas de referencia para protegerse de los principales riesgos de seguridad.

Para empezar a reducir los riesgos de seguridad de tus imágenes y protegerlas contra manipulaciones, firmar contenedores es un buen punto de partida. Las distintas herramientas que se analizan en este artículo se adaptan a diferentes grupos de usuarios, y tu elección debe depender del nivel de eficacia y flexibilidad que exijan tus estándares de seguridad y cumplimiento. Una vez implementada la firma de imágenes, puedes usar soluciones que te ayuden a analizar y auditar la seguridad de las capas de las imágenes.

Por ejemplo, Snyk es una plataforma de seguridad para desarrolladores que prioriza una experiencia fluida para ellos. Ofrece capacidades de análisis de imágenes de contenedores que permiten identificar vulnerabilidades conocidas en los paquetes incluidos en una imagen de Docker. Esto permite detectar y corregir vulnerabilidades de forma proactiva antes de enviar la imagen a Docker Hub o a cualquier otro registro, lo que refuerza la postura de seguridad general.