Docker Content Trust

Azure DevOps Services

La confianza de contenido de Docker (DCT) permite usar firmas digitales para los datos enviados y recibidos de registros remotos de Docker. Estas firmas permiten la comprobación en tiempo de ejecución o del lado cliente de la integridad y el publicador de etiquetas de imagen específicas.

Nota:

Un requisito previo para firmar una imagen es un registro de Docker con un servidor notario asociado (por ejemplo, Docker Hub o Azure Container Registry)

Firma de imágenes en Azure Pipelines

Requisitos previos en la máquina de desarrollo

1. Use el generador integrado de la confianza de Docker o genere manualmente el par de claves de delegación. Si se usa el generador integrado, la clave privada de delegación se importa en el almacén de confianza local de Docker. De lo contrario, la clave privada deberá importarse manualmente en el almacén de confianza local de Docker. Consulte Generación manual de claves para obtener más información.
2. Con la clave de delegación generada a partir del paso anterior, cargue la primera clave en una delegación e inicie el repositorio.

Sugerencia

Para ver la lista de claves de delegación local, use la CLI de Notary para ejecutar el siguiente comando: $ notary key list.

Configuración de la canalización para la firma de imágenes

1. Tome la clave privada de delegación, que se encuentra en el almacén de confianza local de Docker de la máquina de desarrollo usada anteriormente y agregue lo mismo que un archivo seguro en Canalizaciones.

2. Autorice este archivo seguro para su uso en todas las canalizaciones.

3. La entidad de servicio asociada a containerRegistryServiceConnection debe tener el rol AcrImageSigner en el registro de contenedor de destino.

4. Cree una canalización basada en el siguiente fragmento de código YAML:

   pool:
     vmImage: 'Ubuntu 16.04'
   
   variables:
     system.debug: true
     containerRegistryServiceConnection: serviceConnectionName
     imageRepository: foobar/content-trust
     tag: test
   
   steps:
   - task: Docker@2
     inputs:
       command: login
       containerRegistry: $(containerRegistryServiceConnection)
   
   - task: DownloadSecureFile@1
     name: privateKey
     inputs:
       secureFile: cc8f3c6f998bee63fefaaabc5a2202eab06867b83f491813326481f56a95466f.key
   - script: |
       mkdir -p $(DOCKER_CONFIG)/trust/private
       cp $(privateKey.secureFilePath) $(DOCKER_CONFIG)/trust/private
   
   - task: Docker@2
     inputs:
       command: build
       Dockerfile: '**/Dockerfile'
       containerRegistry: $(containerRegistryServiceConnection)
       repository: $(imageRepository)
       tags: |
         $(tag)
       arguments: '--disable-content-trust=false'
   
   - task: Docker@2
     inputs: 
       command: push
       containerRegistry: $(containerRegistryServiceConnection)
       repository: $(imageRepository)
       tags: |
         $(tag)
       arguments: '--disable-content-trust=false'
     env:
       DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASE: $(DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASE)
   

   En el ejemplo anterior, el comando DOCKER_CONFIG establece la variable login en la tarea Docker. Se recomienda configurar DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASE como una variable secreta para la canalización. El enfoque alternativo de usar una variable de canalización en YAML expone la frase de contraseña en texto sin formato. DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASE en este ejemplo se hace referencia a la frase de contraseña de la clave privada (no a la frase de contraseña del repositorio). Solo necesitamos la frase de contraseña de la clave privada en este ejemplo porque el repositorio ya se ha iniciado (requisitos previos).