Docker inhoud vertrouwen

Azure DevOps Services

Met Docker Content Trust (DCT) kunt u digitale handtekeningen gebruiken voor gegevens die worden verzonden naar en ontvangen van externe Docker-registers. Deze handtekeningen maken verificatie aan de clientzijde of runtime mogelijk van de integriteit en uitgever van specifieke installatiekopietags.

Notitie

Een vereiste voor het ondertekenen van een installatiekopieën is een Docker-register waaraan een notarisserver is gekoppeld (voorbeelden zijn Docker Hub of Azure Container Registry)

Installatiekopieën ondertekenen in Azure Pipelines

Vereisten op ontwikkelcomputer

1. Gebruik de ingebouwde generator van Docker-vertrouwensrelatie of genereer handmatig een delegatiesleutelpaar. Als de ingebouwde generator wordt gebruikt, wordt de persoonlijke sleutel voor delegatie geïmporteerd in het lokale Docker-vertrouwensarchief. Anders moet de persoonlijke sleutel handmatig worden geïmporteerd in het lokale Docker-vertrouwensarchief. Zie Sleutels handmatig genereren voor meer informatie.
2. Upload met behulp van de delegatiesleutel die is gegenereerd op basis van de bovenstaande stap de eerste sleutel naar een delegatie en initieer de opslagplaats

Tip

Als u de lijst met lokale delegatiesleutels wilt weergeven, gebruikt u de NOTARIS-CLI om de volgende opdracht uit te voeren: $ notary key list.

Pijplijn instellen voor het ondertekenen van installatiekopieën

1. Pak de persoonlijke overdrachtssleutel, die zich in het lokale Docker-vertrouwensarchief van uw eerder gebruikte ontwikkelcomputer bevindt, en voeg dezelfde toe als een beveiligd bestand in Pijplijnen.

2. Autoriseer dit beveiligde bestand voor gebruik in alle pijplijnen.

3. De service-principal die is gekoppeld aan containerRegistryServiceConnection , moet de rol AcrImageSigner hebben in het doelcontainerregister.

4. Maak een pijplijn op basis van het volgende YAML-fragment:

   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)
   

   In het vorige voorbeeld wordt de DOCKER_CONFIG variabele ingesteld met de login opdracht in de Docker-taak. We raden u aan om in te stellen DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASE als een geheime variabele voor uw pijplijn. De alternatieve benadering van het gebruik van een pijplijnvariabele in YAML geeft de wachtwoordzin weer in tekst zonder opmaak. DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASE in dit voorbeeld verwijst naar de wachtwoordzin van de persoonlijke sleutel (niet de wachtwoordzin van de opslagplaats). In dit voorbeeld hebben we alleen de wachtwoordzin van de persoonlijke sleutel nodig omdat de opslagplaats al is gestart (vereisten).