Docker-Inhaltsvertrauensstellung

Azure DevOps Services

Mit Docker Content Trust (DCT) können Sie digitale Signaturen für Daten verwenden, die an Docker-Remoteregistrierungen gesendet und von diesen empfangen werden. Diese Signaturen ermöglichen eine clientseitige oder Laufzeitüberprüfung der Integrität und des Herausgebers bestimmter Imagetags.

Hinweis

Voraussetzung für das Signieren eines Images ist eine Docker-Registrierung mit angefügtem Notarserver (Beispiele sind Docker Hub oder Azure Container Registry).

Signieren von Images in Azure Pipelines

Voraussetzungen auf dem Entwicklungscomputer

1. Verwenden Sie den integrierten Generator der Docker-Vertrauensstellung, oder generieren Sie das Delegierungsschlüsselpaar manuell. Wenn der integrierte Generator verwendet wird, wird der private Delegierungsschlüssel in den lokalen Docker-Vertrauensspeicher importiert. Andernfalls muss der private Schlüssel manuell in den lokalen Docker-Vertrauensspeicher importiert werden. Weitere Informationen finden Sie unter Manuelles Generieren von Schlüsseln .
2. Laden Sie mithilfe des aus dem obigen Schritt generierten Delegierungsschlüssels den ersten Schlüssel in eine Delegierung hoch, und initiieren Sie das Repository.

Tipp

Um die Liste der lokalen Delegierungsschlüssel anzuzeigen, verwenden Sie die Notar CLI, um den folgenden Befehl auszuführen: $ notary key list.

Einrichten der Pipeline zum Signieren von Images

1. Greifen Sie den privaten Delegierungsschlüssel ab, der sich im lokalen Docker-Vertrauensspeicher Ihres Entwicklungscomputers befindet, und fügen Sie denselben wie eine sichere Datei in Pipelines hinzu.

2. Autorisieren Sie diese sichere Datei für die Verwendung in allen Pipelines.

3. Der zugeordnete containerRegistryServiceConnection Dienstprinzipal muss über die Rolle AcrImageSigner in der Zielcontainerregistrierung verfügen.

4. Erstellen Sie eine Pipeline basierend auf dem folgenden YAML-Codeausschnitt:

   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)
   

   Im vorherigen Beispiel wird die DOCKER_CONFIG Variable durch den login Befehl im Docker-Task festgelegt. Es wird empfohlen, als DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASEgeheime Variable für Ihre Pipeline einzurichten. Der alternative Ansatz der Verwendung einer Pipelinevariablen in YAML macht die Passphrase in Nur-Text verfügbar. DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASE in diesem Beispiel bezieht sich auf die Passphrase des privaten Schlüssels (nicht auf die Repositorypassphrase). In diesem Beispiel benötigen wir nur die Passphrase des privaten Schlüssels, da das Repository bereits initiiert wurde (Voraussetzungen).