Approbation de 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 de notarié attaché (par exemple, Docker Hub ou Azure Container Registry)

Signature d’images dans Azure Pipelines

Conditions préalables sur l’ordinateur de développement

  1. Utilisez le générateur intégré de l’approbation Docker ou générez manuellement la 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, voir Génération manuelle des clés .
  2. À l’aide de la clé de délégation générée à partir de l’étape ci-dessus, chargez la première clé dans une délégation et lancez le référentiel.

Conseil

Pour afficher la liste des clés de délégation locale, utilisez l’interface CLI notariée 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 ordinateur de développement utilisé précédemment et 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 dans 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 référentiel). Nous avons uniquement besoin de la phrase secrète de la clé privée dans cet exemple, car le référentiel a déjà été lancé (prérequis).