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
- 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 .
- À 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
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.
Autorisez ce fichier sécurisé à utiliser dans tous les pipelines.
Le principal de service associé
containerRegistryServiceConnection
à doit avoir le rôle AcrImageSigner dans le registre de conteneurs cible.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 lalogin
commande de la tâche Docker. Nous vous recommandons de configurerDOCKER_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).