# Confianza de contenido en Docker Al transferir datos entre sistemas conectados en red, la confianza es una preocupación central. En particular, cuando se comunica a través de un medio no confiable como Internet, es fundamental garantizar la integridad y el emisor de todos los datos con los que opera un sistema. Utilizas Docker Engine para subir (push) y bajar (pull) imágenes (datos) hacia y desde un registro público o privado. La confianza de contenido te brinda la capacidad de verificar tanto la integridad como el emisor de todos los datos recibidos de un registro a través de cualquier canal. ## Acerca de Docker Content Trust (DCT) Docker Content Trust (DCT) proporciona la capacidad de utilizar firmas digitales para los datos enviados y recibidos desde registros remotos de Docker. Estas firmas permiten la verificación en el lado del cliente o en tiempo de ejecución de la integridad y el emisor de etiquetas de imagen específicas. A través de DCT, los creadores de imágenes pueden firmar sus imágenes y los consumidores de imágenes pueden asegurarse de que las imágenes que descargan estén firmadas. Los creadores pueden ser personas u organizaciones que firman manualmente su contenido, o cadenas de suministro de software automatizadas que firman el contenido como parte de su proceso de lanzamiento. > [!NOTE] > > Docker va a retirar DCT para las imágenes oficiales de Docker (DOI). Deberías comenzar a planificar la transición hacia una solución diferente de firma y verificación de imágenes (como [Sigstore](https://www.sigstore.dev/) o [Notation](https://github.com/notaryproject/notation#readme)). Los plazos para la depreciación completa de DCT se están finalizando y se publicarán pronto. Para obtener más información, consulta [Retiro de Docker Content Trust](https://www.docker.com/blog/retiring-docker-content-trust/). ### Etiquetas de imagen y DCT Un registro de imagen individual tiene el siguiente identificador: ```text [REGISTRY_HOST[:REGISTRY_PORT]/]REPOSITORY[:TAG] ``` Un repositorio de imágenes (`REPOSITORY`) particular puede tener varias etiquetas. Por ejemplo, `latest` y `3.1.2` son etiquetas de la imagen `mongo`. Un creador de imágenes puede compilar una combinación de imagen y etiqueta muchas veces, cambiando la imagen con cada compilación. DCT está asociado con la parte `TAG` de una imagen. Cada repositorio de imágenes tiene un conjunto de claves que los creadores de imágenes utilizan para firmar una etiqueta de imagen. Los creadores de imágenes tienen discreción sobre qué etiquetas firman. Un repositorio de imágenes puede contener una imagen con una etiqueta firmada y otra etiqueta que no lo está. Por ejemplo, considera [el repositorio de imágenes de Mongo](https://hub.docker.com/_/mongo/tags/). La etiqueta `latest` podría no estar firmada, mientras que la etiqueta `3.1.6` podría estarlo. Es responsabilidad del creador de la imagen decidir si una etiqueta de imagen está firmada o no. En esta representación, algunas etiquetas de imagen están firmadas y otras no: ![Signed tags](/engine/security/trust/images/tag_signing.png) Los creadores pueden elegir firmar una etiqueta específica o no. Como resultado, el contenido de una etiqueta no firmada y el de una etiqueta firmada con el mismo nombre pueden no coincidir. Por ejemplo, un creador puede subir una imagen etiquetada `someimage:latest` y firmarla. Más tarde, el mismo creador puede subir una imagen `someimage:latest` no firmada. Esta segunda subida reemplaza la última etiqueta `latest` no firmada, pero no afecta a la versión firmada de `latest`. La capacidad de elegir qué etiquetas pueden firmar les permite a los creadores iterar sobre la versión no firmada de una imagen antes de firmarla oficialmente. Los consumidores de imágenes pueden habilitar DCT para asegurarse de que las imágenes que utilizan estén firmadas. Si un consumidor habilita DCT, solo podrá descargar, ejecutar o compilar con imágenes de confianza. Habilitar DCT es un poco como aplicar un "filtro" a su registro. Los consumidores "ven" solo las etiquetas de imágenes firmadas, y las etiquetas de imágenes no firmadas, menos deseables, son "invisibles" para ellos. ![Trust view](/engine/security/trust/images/trust_view.png) Para el consumidor que no ha habilitado DCT, nada cambia en la forma en que trabaja con las imágenes de Docker. Cada imagen es visible independientemente de si está firmada o no. ### Claves de Docker Content Trust La confianza para una etiqueta de imagen se gestiona mediante el uso de claves de firma. Se crea un conjunto de claves cuando se invoca por primera vez una operación que utiliza DCT. Un conjunto de claves consta de los siguientes tipos de claves: - Una clave fuera de línea (offline) que es la raíz de DCT para una etiqueta de imagen - Claves de repositorio o de etiquetado que firman etiquetas - Claves gestionadas por el servidor, como la clave de marca de tiempo (timestamp), que proporciona garantías de seguridad de frescura para tu repositorio La siguiente imagen representa las diversas claves de firma y sus relaciones: ![Content Trust components](/engine/security/trust/images/trust_components.png) > [!WARNING] > > La clave raíz, una vez perdida, no es recuperable. Si pierdes cualquier otra clave, envía un correo electrónico al [soporte de Docker Hub](mailto:hub-support@docker.com). Esta pérdida también requiere la intervención manual de cada consumidor que haya utilizado una etiqueta firmada de este repositorio antes de la pérdida. Debes hacer una copia de seguridad de la clave raíz en un lugar seguro. Dado que solo se requiere para crear nuevos repositorios, es una buena idea almacenarla fuera de línea en hardware. Para obtener detalles sobre cómo asegurar y hacer copias de seguridad de tus claves, asegúrate de leer cómo [gestionar claves para DCT](/engine/security/trust/trust_key_mng/). ## Firmar imágenes con Docker Content Trust Dentro de la CLI de Docker, puedes firmar y subir una imagen de contenedor con la sintaxis del comando `docker trust`. Esto está construido sobre el conjunto de características de Notary. Para obtener más información, consulta el [repositorio de GitHub de Notary](https://github.com/theupdateframework/notary). Un requisito previo para firmar una imagen es tener un registro de Docker con un servidor Notary asociado (como Docker Hub). Consulta [Desplegar Notary](/engine/security/trust/deploying_notary/) para obtener instrucciones. > [!NOTE] > > Docker va a retirar DCT para las imágenes oficiales de Docker (DOI). Deberías comenzar a planificar la transición hacia una solución diferente de firma y verificación de imágenes (como [Sigstore](https://www.sigstore.dev/) o [Notation](https://github.com/notaryproject/notation#readme)). Los plazos para la depreciación completa de DCT se están finalizando y se publicarán pronto. Para obtener más información, consulta [Retiro de Docker Content Trust](https://www.docker.com/blog/retiring-docker-content-trust/). Para firmar una imagen de Docker, necesitarás un par de claves de delegación. Estas claves se pueden generar localmente utilizando `docker trust key generate` o ser generadas por una autoridad de certificación. Primero, añadiremos la clave privada de delegación al repositorio local de confianza de Docker (por defecto se almacena en `~/.docker/trust/`). Si estás generando claves de delegación con `docker trust key generate`, la clave privada se añade automáticamente al almacén de confianza local. Si estás importando una clave independiente, deberás utilizar el comando `docker trust key load`. ```console $ docker trust key generate jeff Generating key for jeff... Enter passphrase for new jeff key with ID 9deed25: Repeat passphrase for new jeff key with ID 9deed25: Successfully generated and loaded private key. Corresponding public key available: /home/ubuntu/Documents/mytrustdir/jeff.pub ``` O si tienes una clave existente: ```console $ docker trust key load key.pem --name jeff Loading key from "key.pem"... Enter passphrase for new jeff key with ID 8ae710e: Repeat passphrase for new jeff key with ID 8ae710e: Successfully imported key from key.pem ``` A continuación, necesitaremos añadir la clave pública de delegación al servidor Notary; esto es específico de un repositorio de imágenes particular en Notary conocido como Nombre Único Global (GUN, por sus siglas en inglés). Si es la primera vez que añades una delegación a ese repositorio, este comando también iniciará el repositorio, utilizando una clave raíz canónica local de Notary. Para comprender mejor la iniciación de un repositorio y el papel de las delegaciones, dirígete a [delegaciones para la confianza de contenido](/engine/security/trust/trust_delegation/). ```console $ docker trust signer add --key cert.pem jeff registry.example.com/admin/demo Adding signer "jeff" to registry.example.com/admin/demo... Enter passphrase for new repository key with ID 10b5e94: ``` Finalmente, utilizaremos la clave privada de delegación para firmar una etiqueta en particular y subirla al registro. ```console $ docker trust sign registry.example.com/admin/demo:1 Signing and pushing trust data for local image registry.example.com/admin/demo:1, may overwrite remote trust data The push refers to repository [registry.example.com/admin/demo] 7bff100f35cb: Pushed 1: digest: sha256:3d2e482b82608d153a374df3357c0291589a61cc194ec4a9ca2381073a17f58e size: 528 Signing and pushing trust metadata Enter passphrase for signer key with ID 8ae710e: Successfully signed registry.example.com/admin/demo:1 ``` Alternativamente, una vez importadas las claves, se puede subir una imagen con el comando `docker push`, exportando la variable de entorno de DCT. ```console $ export DOCKER_CONTENT_TRUST=1 $ docker push registry.example.com/admin/demo:1 The push refers to repository [registry.example.com/admin/demo:1] 7bff100f35cb: Pushed 1: digest: sha256:3d2e482b82608d153a374df3357c0291589a61cc194ec4a9ca2381073a17f58e size: 528 Signing and pushing trust metadata Enter passphrase for signer key with ID 8ae710e: Successfully signed registry.example.com/admin/demo:1 ``` Los datos de confianza remotos para una etiqueta o un repositorio se pueden ver mediante el comando `docker trust inspect`: ```console $ docker trust inspect --pretty registry.example.com/admin/demo:1 Signatures for registry.example.com/admin/demo:1 SIGNED TAG DIGEST SIGNERS 1 3d2e482b82608d153a374df3357c0291589a61cc194ec4a9ca2381073a17f58e jeff List of signers and their keys for registry.example.com/admin/demo:1 SIGNER KEYS jeff 8ae710e3ba82 Administrative keys for registry.example.com/admin/demo:1 Repository Key: 10b5e94c916a0977471cc08fa56c1a5679819b2005ba6a257aa78ce76d3a1e27 Root Key: 84ca6e4416416d78c4597e754f38517bea95ab427e5f95871f90d460573071fc ``` Los datos de confianza remotos para una etiqueta se pueden eliminar con el comando `docker trust revoke`: ```console $ docker trust revoke registry.example.com/admin/demo:1 Enter passphrase for signer key with ID 8ae710e: Successfully deleted signature for registry.example.com/admin/demo:1 ``` ## Cumplimiento del cliente con Docker Content Trust La confianza de contenido está deshabilitada por defecto en el cliente de Docker. Para habilitarla, establece la variable de entorno `DOCKER_CONTENT_TRUST` en `1`. Esto evita que los usuarios trabajen con imágenes etiquetadas a menos que contengan una firma. Cuando DCT está habilitado en el cliente de Docker, los comandos de la CLI de `docker` que operan con imágenes etiquetadas deben tener firmas de contenido o hashes de contenido explícitos. Los comandos que operan con DCT son: * `push` * `build` * `create` * `pull` * `run` Por ejemplo, con DCT habilitado, un `docker pull someimage:latest` solo tiene éxito si `someimage:latest` está firmado. Sin embargo, una operación con un hash de contenido explícito siempre tiene éxito siempre que el hash exista: ```console $ docker pull registry.example.com/user/image:1 Error: remote trust data does not exist for registry.example.com/user/image: registry.example.com does not have trust data for registry.example.com/user/image $ docker pull registry.example.com/user/image@sha256:d149ab53f8718e987c3a3024bb8aa0e2caadf6c0328f1d9d850b2a2a67f2819a sha256:ee7491c9c31db1ffb7673d91e9fac5d6354a89d0e97408567e09df069a1687c1: Pulling from user/image ff3a5c916c92: Pull complete a59a168caba3: Pull complete Digest: sha256:ee7491c9c31db1ffb7673d91e9fac5d6354a89d0e97408567e09df069a1687c1 Status: Downloaded newer image for registry.example.com/user/image@sha256:ee7491c9c31db1ffb7673d91e9fac5d6354a89d0e97408567e09df069a1687c1 ``` ## Información relacionada * [Delegaciones para la confianza de contenido](/engine/security/trust/trust_delegation/) * [Automatización con confianza de contenido](/engine/security/trust/trust_automation/) * [Gestionar claves para la confianza de contenido](/engine/security/trust/trust_key_mng/) * [Jugar en un entorno de pruebas (sandbox) de confianza de contenido](/engine/security/trust/trust_sandbox/)