Zaufanie do zawartości platformy Docker

Usługa Azure DevOps Services

Platforma Docker Content Trust (DCT) umożliwia używanie podpisów cyfrowych do danych wysyłanych do i odbieranych z zdalnych rejestrów platformy Docker. Te podpisy umożliwiają weryfikację integralności i wydawcy określonych tagów obrazów po stronie klienta lub w czasie wykonywania.

Uwaga

Wymagania wstępne dotyczące podpisywania obrazu to rejestr platformy Docker z dołączonym serwerem notary (na przykład Docker Hub lub Azure Container Registry)

Podpisywanie obrazów w usłudze Azure Pipelines

Wymagania wstępne dotyczące maszyny deweloperów

1. Użyj wbudowanego generatora zaufania platformy Docker lub ręcznie wygeneruj parę kluczy delegowania. Jeśli jest używany wbudowany generator , klucz prywatny delegowania jest importowany do lokalnego magazynu zaufania platformy Docker. W przeciwnym razie klucz prywatny musi zostać ręcznie zaimportowany do lokalnego magazynu zaufania platformy Docker. Aby uzyskać szczegółowe informacje, zobacz Ręczne generowanie kluczy .
2. Korzystając z klucza delegowania wygenerowanego w powyższym kroku, przekaż pierwszy klucz do delegowania i zainicjuj repozytorium

Porada

Aby wyświetlić listę lokalnych kluczy delegowania, użyj interfejsu wiersza polecenia notary, aby uruchomić następujące polecenie: $ notary key list.

Konfigurowanie potoku na potrzeby podpisywania obrazów

1. Pobierz klucz prywatny delegowania, który znajduje się w lokalnym magazynie zaufania platformy Docker używanej wcześniej maszyny dewelopera i dodaj ten sam plik co bezpieczny plik w usłudze Pipelines.

2. Autoryzuj ten bezpieczny plik do użycia we wszystkich potokach.

3. Jednostka usługi skojarzona z elementem containerRegistryServiceConnection musi mieć rolę AcrImageSigner w docelowym rejestrze kontenerów.

4. Utwórz potok na podstawie następującego fragmentu kodu YAML:

   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)
   

   W poprzednim przykładzie zmienna DOCKER_CONFIG jest ustawiana przez login polecenie w zadaniu platformy Docker. Zalecamy skonfigurowanie jako DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASEzmiennej tajnej dla potoku. Alternatywne podejście do używania zmiennej potoku w języku YAML uwidacznia hasło w postaci zwykłego tekstu. DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASE w tym przykładzie odwołuje się do hasła klucza prywatnego (a nie hasła repozytorium). W tym przykładzie potrzebujemy tylko hasła klucza prywatnego, ponieważ repozytorium zostało już zainicjowane (wymagania wstępne).