Approbation du contenu Docker

Azure DevOps Services

Docker Content Trust (DCT) vous permet d’utiliser des signatures numériques pour les données envoyées et reçues à partir de registres Docker distants. Ces signatures permettent la vérification côté client ou runtime de l’intégrité et de l’éditeur de balises d’image spécifiques.

Notes

Une condition préalable à la signature d’une image est un registre Docker avec un serveur notarié attaché (par exemple, Docker Hub ou Azure Container Registry)

Signature d’images dans Azure Pipelines

Prérequis sur l’ordinateur de développement

1. Utilisez le générateur intégré de l’approbation Docker ou générez manuellement une paire de clés de délégation. Si le générateur intégré est utilisé, la clé privée de délégation est importée dans le magasin d’approbation Docker local. Sinon, la clé privée doit être importée manuellement dans le magasin d’approbation Docker local. Pour plus d’informations, consultez Génération manuelle de clés .
2. À l’aide de la clé de délégation générée à l’étape ci-dessus, chargez la première clé dans une délégation et lancez le dépôt

Conseil

Pour afficher la liste des clés de délégation locales, utilisez l’interface CLI Notariat pour exécuter la commande suivante : $ notary key list.

Configurer le pipeline pour la signature d’images

1. Récupérez la clé privée de délégation, qui se trouve dans le magasin d’approbation Docker local de votre machine de développement utilisée précédemment, puis ajoutez la même chose qu’un fichier sécurisé dans Pipelines.

2. Autorisez ce fichier sécurisé à utiliser dans tous les pipelines.

3. Le principal de service associé containerRegistryServiceConnection à doit avoir le rôle AcrImageSigner dans le registre de conteneurs cible.

4. Créez un pipeline basé sur l’extrait de code YAML suivant :

   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)
   

   Dans l’exemple précédent, la DOCKER_CONFIG variable est définie par la login commande de la tâche Docker. Nous vous recommandons de configurer DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASE en tant que variable secrète pour votre pipeline. L’autre approche de l’utilisation d’une variable de pipeline dans YAML expose la phrase secrète en texte brut. DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASE dans cet exemple, fait référence à la phrase secrète de la clé privée (et non à la phrase secrète du dépôt). Nous avons uniquement besoin de la phrase secrète de la clé privée dans cet exemple, car le dépôt a déjà été lancé (prérequis).