Udostępnij za pośrednictwem


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).