Udostępnij przez

Weryfikowanie obrazów kontenerów w przepływach pracy usługi GitHub przy użyciu notacji i zaufanego podpisywania

Ten artykuł jest częścią serii dotyczącej zapewniania integralności i autentyczności obrazów kontenerów oraz innych artefaktów Open Container Initiative (OCI). Aby uzyskać pełny obraz, zacznij od omówienia, co wyjaśnia, dlaczego podpisywanie ma znaczenie i przedstawia różne scenariusze.

Ten przewodnik można użyć w dwóch scenariuszach:

  • Korzystanie z podpisanych obrazów: Zweryfikuj obrazy kontenerów, które inne zespoły lub organizacje już podpisały, używając Notacji i Zaufanego Podpisywania.
  • Weryfikowanie własnych obrazów: jeśli samodzielnie publikujesz obrazy, najpierw podpisz je przy użyciu przepływu pracy usługi GitHub lub interfejsu wiersza polecenia Notation (CLI). Następnie postępuj zgodnie z tym przewodnikiem, aby zweryfikować podpisy.

W tym artykule dowiesz się, jak:

  • Konfigurowanie przepływu pracy usługi GitHub.
  • Sprawdź, czy obrazy kontenerów zostały podpisane przy użyciu funkcji zaufanego podpisywania i funkcji GitHub Actions dla notacji.

Wymagania wstępne

  • Rejestr kontenerów zawierający podpisane obrazy.
  • Repozytorium GitHub do przechowywania pliku przepływu pracy, zasad zaufania i magazynu zaufania.

Uwierzytelnij się na platformie Azure do usługi GitHub

Zgodnie z Użyj funkcji GitHub Actions, aby połączyć się z Azure, należy najpierw uwierzytelnić się w Azure w przepływie pracy za pomocą akcji Azure Login, zanim uruchomisz polecenia Azure CLI lub Azure PowerShell. Akcja logowania platformy Azure obsługuje wiele metod uwierzytelniania.

W tym przewodniku zalogujesz się przy użyciu protokołu OpenID Connect (OIDC), użyjesz tożsamości zarządzanej przypisanej przez użytkownika, a następnie wykonaj kroki opisane w temacie Korzystanie z akcji Logowanie do platformy Azure w programie OpenID Connect.

  1. Utwórz tożsamość zarządzaną przypisaną przez użytkownika. Pomiń ten krok, jeśli masz istniejącą tożsamość zarządzaną.

    az login
az identity create -g <identity-resource-group> -n <identity-name>

  1. Pobierz identyfikator klienta tożsamości zarządzanej:

    CLIENT_ID=$(az identity show -g <identity-resource-group> -n <identity-name> --query clientId -o tsv)

  1. Przypisz role do tożsamości zarządzanej na potrzeby uzyskiwania dostępu do usługi Azure Container Registry.

    W przypadku rejestrów, które nie są włączone za pomocą kontroli dostępu opartej na atrybutach (ABAC), przypisz AcrPull rolę:

    ACR_SCOPE=/subscriptions/<subscription-id>/resourceGroups/<acr-resource-group>
az role assignment create --assignee $CLIENT_ID --scope $ACR_SCOPE --role "acrpush" --role "acrpull"

    W przypadku rejestrów z włączonym ABAC przypisz rolę Container Registry Repository Reader.

    ACR_SCOPE=/subscriptions/<subscription-id>/resourceGroups/<acr-resource-group>
az role assignment create --assignee $CLIENT_ID --scope $ACR_SCOPE --role "Container Registry Repository Reader" --role "Container Registry Repository Writer"

  1. Skonfiguruj usługę GitHub tak, aby ufała twojej tożsamości. Postępuj zgodnie z Konfigurowaniem tożsamości zarządzanej przypisanej przez użytkownika, aby zaufać zewnętrznemu dostawcy tożsamości.

  2. Utwórz wpisy tajne GitHub, postępując zgodnie z instrukcją Tworzenie wpisów tajnych dla repozytorium.

    Zamapuj wartości tożsamości zarządzanej z tymi sekretami.

    Wpis tajny usługi GitHub Wartość tożsamości zarządzanej
    AZURE_CLIENT_ID ID klienta
    AZURE_SUBSCRIPTION_ID Identyfikator subskrypcji
    AZURE_TENANT_ID Identyfikator katalogu (klienta)

Przygotuj magazyn zaufania i zasady zaufania

Weryfikacja wymaga posiadania w repozytorium magazynu zaufania i polityki zaufania Notary Project.

Utwórz zaufany magazyn

Magazyn zaufania (.github/truststore/) zawiera certyfikaty urzędu certyfikacji (CA) i certyfikaty główne urzędu sygnatury czasowej (TSA), które są wymagane do weryfikacji.

Pobierz certyfikat główny zaufanego podpisywania i zapisz go w ca katalogu:

curl -o .github/truststore/x509/ca/mycerts/msft-identity-verification-root-cert-2020.crt \
    "https://www.microsoft.com/pkiops/certs/Microsoft%20Enterprise%20Identity%20Verification%20Root%20Certificate%20Authority%202020.crt"

Pobierz certyfikat główny zaufanegotsa podpisywania TSA i zapisz go w katalogu:

curl -o .github/truststore/x509/tsa/mytsacerts/msft-identity-verification-tsa-root-cert-2020.crt \
  "http://www.microsoft.com/pkiops/certs/microsoft%20identity%20verification%20root%20certificate%20authority%202020.crt"

Tworzenie zasad zaufania

Zasady zaufania (.github/trustpolicy/trustpolicy.json) określają tożsamości i urzędy certyfikacyjne, które są uznane za zaufane.

Oto przykład trustpolicy.json. Zastąp identyfikatory URI repozytorium, nazwy magazynów zaufania i podmiot zaufanego profilu podpisywania swoimi wartościami.

{
 "version": "1.0",
 "trustPolicies": [
    {
         "name": "mypolicy",
         "registryScopes": [ "myregistry.azurecr.io/myrepo1","myregistry.azurecr.io/myrepo2" ],
         "signatureVerification": {
             "level" : "strict"
         },
         "trustStores": [ "ca:mycerts", "tsa:mytsacerts" ],
         "trustedIdentities": [
           "x509.subject: C=US, ST=WA, L=Seattle, O=MyCompany.io, OU=Tools"
         ]
     }
 ]
}

Potwierdzanie struktury katalogów

Repozytorium powinno wyglądać następująco:

.github/
├── trustpolicy/
│   └── trustpolicy.json
└── truststore/
    └── x509/
        ├── ca/
        │   └── mycerts/
        │       └── msft-identity-verification-root-cert-2020.crt
        └── tsa/
            └── mytsacerts/
                └── msft-identity-verification-tsa-root-cert-2020.crt

Tworzenie przepływu pracy funkcji GitHub Actions

Gdy konfiguracja uwierzytelniania i zaufania jest gotowa, utwórz przepływ pracy:

  1. .github/workflows Utwórz katalog w repozytorium, jeśli nie istnieje.

  2. Utwórz nowy plik przepływu pracy; na przykład verify-with-trusted-signing.yml.

  3. Skopiuj następujący szablon przepływu pracy do pliku.

    Rozwiń, aby wyświetlić szablon weryfikacji przepływu pracy. 
    name: notation-verify-with-trusted-signing

on:
  push:

env:
  ACR_LOGIN_SERVER: <registry-name>.azurecr.io                      # example: myRegistry.azurecr.io
  ACR_REPO_NAME: <repository-name>                                  # example: myRepo
  IMAGE_TAG: <image-tag>                                            # example: v1
  #IMAGE_DIGEST: <image-digest>                                     # example: sha256:xxx
jobs:
  notation-verify:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      # Log in to Azure with your service principal secret
      # - name: Azure login
      #  uses: Azure/login@v1
      #  with:
      #    creds: ${{ secrets.AZURE_CREDENTIALS }}
      # If you're using OIDC and federated credentials, make sure to replace the preceding step with the following:
      - name: Azure login
        uses: Azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      # Log in to your container registry
      - name: ACR login
        run: |
            az acr login --name ${{ env.ACR_LOGIN_SERVER }}

      # Set up the Notation CLI
      - name: setup notation
        uses: notaryproject/notation-action/setup@v1.2.2

      # Verify the OCI artifact, such as container images
      - name: verify OCI artifact
        uses: notaryproject/notation-action/verify@v1
        with:
          target_artifact_reference: ${{ env.ACR_LOGIN_SERVER }}/${{ env.ACR_REPO_NAME }}:${{ env.IMAGE_TAG }}
          # Alternatively, use the image digest
          # target_artifact_reference: ${{ env.ACR_LOGIN_SERVER }}/${{ env.ACR_REPO_NAME }}@${{ env.IMAGE_DIGEST }}
          trust_policy: .github/trustpolicy/trustpolicy.json
          trust_store: .github/truststore

  4. Zaktualizuj zmienne środowiskowe przy użyciu własnego rejestru, repozytorium i tagu/skrótu obrazu. Zapisz i zatwierdź plik.

Uruchom przepływ pracy GitHub Actions

Wykonanie polecenia push wyzwala przykładowy przepływ pracy. Aby uruchomić zadanie, zatwierdź plik przepływu pracy w swoim repozytorium.

Możesz wyświetlić dzienniki przepływu pracy, aby potwierdzić, że zadanie zostało ukończone pomyślnie. Na przykład sprawdź, czy zasady zaufania są importowane, certyfikaty z magazynu zaufania są ładowane, a podpis jest weryfikowany.

  • Last updated on