Weryfikowanie podpisów obrazów kontenera przy użyciu rozwiązania Ratify i usługi Azure Policy

Zabezpieczenia kontenerów mają kluczowe znaczenie w środowisku natywnym dla chmury, aby ułatwić ochronę obciążeń. Aby zwiększyć bezpieczeństwo w całym cyklu życia obrazów kontenerów, firma Microsoft wprowadziła platformę Secure Supply Chain (CSSC). Na etapie wdrażania platformy obrazy kontenerów są wdrażane w środowiskach produkcyjnych, takich jak klastry usługi Azure Kubernetes Service (AKS).

Zapewnienie bezpiecznego środowiska produkcyjnego obejmuje zachowanie integralności i autentyczności obrazów kontenerów. Podpisywanie obrazów kontenerów na etapie kompilacji, a następnie weryfikowanie ich na etapie Wdrażania pomaga zapewnić wdrożenie tylko zaufanych i niezachwianych obrazów.

Ratify to projekt piaskownicy Cloud Native Computing Foundation (CNCF), który obsługuje firma Microsoft. Jest to niezawodny aparat weryfikacji, który weryfikuje metadane zabezpieczeń obrazów kontenerów, takie jak podpisy. Umożliwia tylko wdrażanie obrazów spełniających twoje określone zasady.

Scenariusze

W tym artykule opisano dwa główne scenariusze implementacji weryfikacji podpisów obrazów kontenerów z wykorzystaniem Ratify w AKS. Scenariusze różnią się w zależności od sposobu zarządzania certyfikatami na potrzeby podpisywania i weryfikacji: przy użyciu usługi Azure Key Vault do tradycyjnego zarządzania certyfikatami lub przy użyciu usługi Zaufane podpisywanie firmy Microsoft na potrzeby zarządzania cyklem życia certyfikatów bezobsługowych. Wybierz scenariusz zgodny z bieżącym podejściem do zarządzania certyfikatami i wymaganiami dotyczącymi zabezpieczeń.

Zarządzanie certyfikatami przy użyciu usługi Key Vault

Twórca obrazów kompiluje i wypycha obrazy kontenerów do usługi Azure Container Registry w ramach potoków ciągłej integracji i ciągłego dostarczania (CI/CD). Te obrazy są przeznaczone dla użytkowników obrazów do wdrażania i uruchamiania obciążeń natywnych dla chmury w klastrach usługi AKS.

Producent podpisuje obrazy kontenerów w Container Registry, używając narzędzi Notary Project (przede wszystkim Notation) w ramach potoków CI/CD. Klucze i certyfikaty do podpisywania są bezpiecznie przechowywane w usłudze Key Vault.

Podpisy Notary Project są tworzone i przechowywane w usłudze Container Registry, gdzie odwołują się do odpowiadających im obrazów. Konsument obrazów konfiguruje Ratify oraz zasady w klastrze AKS, aby zweryfikować podpisy Notary Project podczas wdrażania. Obrazy, które nie przeszły weryfikacji podpisu, są blokowane przed wdrożeniem, jeśli efekt zasad jest ustawiony na Deny. Ta konfiguracja pomaga zagwarantować, że w klastrze usługi AKS są wdrażane tylko zaufane i nienaruszone obrazy.

Jako producent obrazu możesz postępować zgodnie z następującymi artykułami, aby podpisać obrazy kontenerów w usłudze Container Registry przy użyciu usługi Key Vault:

• Aby uzyskać informacje na temat podpisywania za pomocą certyfikatów z podpisem własnym, zobacz Podpisywanie obrazów kontenerów przy użyciu notacji, usługi Azure Key Vault i certyfikatu z podpisem własnym.
• Aby uzyskać informacje na temat podpisywania za pośrednictwem certyfikatów wystawionych przez urząd certyfikacji, zobacz Podpisywanie obrazów kontenerów przy użyciu notacji, usługi Azure Key Vault i certyfikatu wystawionego przez urząd certyfikacji.
• Aby uzyskać informacje na temat podpisywania w potokach Azure DevOps, zobacz Podpisywanie i weryfikowanie obrazu kontenera przy użyciu notacji w potoku Azure.
• Aby uzyskać więcej informacji na temat podpisywania w przepływach pracy usługi GitHub, zobacz Podpisywanie obrazu kontenera przy użyciu notacji w funkcji GitHub Actions.

Używanie zaufanego podpisywania do zarządzania certyfikatami

W tym scenariuszu producent obrazu podpisuje obrazy kontenerów w usłudze Container Registry, używając certyfikatów zarządzanych przez Zaufane Podpisywanie zamiast Key Vault. Ponieważ Trusted Signing zapewnia bezdotykowe zarządzanie cyklem życia certyfikatów, producenci nie muszą już obsługiwać wystawiania, rotacji ani wygasania certyfikatów.

Po stronie konsumenta proces Zaufanego Podpisywania tworzy certyfikaty o krótkiej żywotności. Użytkownicy obrazów konfigurują znaczniki czasu podczas weryfikacji, aby zachować zaufanie po wygaśnięciu certyfikatów.

Ponadto zasady Ratify i klastra są konfigurowane w usłudze AKS w celu weryfikowania podpisów w czasie wdrażania. Każdy obraz, który nie przechodzi weryfikacji, jest zablokowany, gdy efekt zasad jest ustawiony na wartość Deny. Blokowanie pomaga zagwarantować, że wdrażane są tylko zaufane i niezmienione obrazy.

Jako producent obrazów możesz skorzystać z następujących artykułów na temat podpisywania obrazów kontenerów przy użyciu Zaufanego Podpisywania:

• Podpisywanie kontenerowych obrazów przy użyciu Notation i Trusted Signing (wersja zapoznawcza)
• Podpisywanie obrazów kontenerów w przepływach pracy usługi GitHub przy użyciu notacji i zaufanego podpisywania

W tym artykule przedstawiono, jako użytkownik obrazów, proces weryfikacji podpisów obrazów kontenerów z użyciem rozwiązania Ratify i usługi Azure Policy w klastrach AKS.

Przegląd weryfikacji podpisu

Poniżej przedstawiono ogólne kroki weryfikacji podpisu:

1. Konfigurowanie mechanizmów kontroli tożsamości i dostępu dla usługi Container Registry: skonfiguruj tożsamość używaną przez usługę Ratify do uzyskiwania dostępu do usługi Container Registry przy użyciu niezbędnych ról.

2. Konfigurowanie mechanizmów kontroli tożsamości i dostępu dla usługi Key Vault: skonfiguruj tożsamość używaną przez usługę Ratify do uzyskiwania dostępu do usługi Key Vault przy użyciu niezbędnych ról. Pomiń ten krok, jeśli obrazy są podpisane za pośrednictwem zaufanego podpisywania.

3. Konfigurowanie Ratify w klastrze AKS: Konfigurowanie Ratify przy użyciu zainstalowania pakietu Helm jako standardowej usługi w Kubernetes.

4. Konfigurowanie niestandardowych zasad platformy Azure: tworzenie i przypisywanie niestandardowych zasad platformy Azure z pożądanym efektem zasad: Deny lub Audit.

Po wykonaniu tych kroków możesz rozpocząć wdrażanie obciążeń, aby obserwować wyniki:

• Deny W przypadku efektu zasad tylko obrazy, które przechodzą weryfikację podpisu, mogą być wdrożone. Obrazy, które są niepodpisane lub podpisane przez niezaufane podmioty, są odrzucane.
• Dzięki efektowi Audit zasad można wdrażać obrazy, ale składniki są oznaczone jako niezgodne w celach inspekcji.

Wymagania wstępne

• Zainstaluj i skonfiguruj najnowszą wersję interfejsu wiersza polecenia platformy Azure lub uruchom polecenia w usłudze Azure Cloud Shell.
• Zainstaluj program Helm for Ratify i zainstaluj narzędzie kubectl na potrzeby rozwiązywania problemów i sprawdzania stanu.
• Utwórz lub użyj klastra usługi AKS z włączonym wystawcą OpenID Connect (OIDC), wykonując kroki opisane w temacie Tworzenie dostawcy OpenID Connect w usłudze Azure Kubernetes Service. Ten klaster usługi AKS to miejsce, gdzie wdrażasz obrazy kontenerów, instalujesz Ratify i stosujesz niestandardowe zasady platformy Azure.
• Połącz usługę Container Registry z klastrem usługi AKS (jeśli jeszcze nie jest połączony), wykonując kroki opisane w artykule Uwierzytelnianie za pomocą usługi Azure Container Registry z usługi Azure Kubernetes Service. Usługa Container Registry to miejsce przechowywania obrazów kontenerów do wdrożenia w klastrze usługi AKS.
• Włącz dodatek usługi Azure Policy. Aby sprawdzić, czy dodatek jest zainstalowany, lub zainstalować go, jeśli jeszcze nie jest, wykonaj kroki opisane w artykule Dodatek usługi Azure Policy dla usługi AKS.

Konfigurowanie tożsamości i kontroli dostępu

Przed zainstalowaniem rozwiązania Ratify w klastrze usługi AKS należy ustanowić odpowiednią tożsamość i kontrolę dostępu. Ratify wymaga dostępu do rejestru kontenerów w celu ściągnięcia obrazów kontenerów i podpisów. W przypadku używania usługi Key Vault do zarządzania certyfikatami usługa Ratify potrzebuje również dostępu do pobierania certyfikatów na potrzeby weryfikacji podpisu.

Konfiguracja tożsamości obejmuje:

• Tworzenie tożsamości zarządzanej przypisanej przez użytkownika lub używanie istniejącej tożsamości.
• Konfigurowanie poświadczeń tożsamości federacyjnej w celu umożliwienia uwierzytelniania tożsamości pracy.
• Udzielanie odpowiednich przypisań ról na potrzeby dostępu do usługi Container Registry.
• Konfigurowanie uprawnień dostępu do usługi Key Vault, jeśli używasz usługi Key Vault do zarządzania certyfikatami.

Tworzenie lub używanie tożsamości zarządzanej przypisanej przez użytkownika

Jeśli nie masz jeszcze tożsamości zarządzanej przypisanej przez użytkownika, zobacz Tworzenie tożsamości zarządzanej przypisanej przez użytkownika, aby utworzyć tożsamość zarządzaną przypisaną przez użytkownika . Ratify używa tej tożsamości do uzyskiwania dostępu do zasobów platformy Azure, takich jak Usługa Container Registry i (jeśli dotyczy) usługa Key Vault na potrzeby zarządzania certyfikatami.

Tworzenie poświadczenia tożsamości federacyjnej dla twojej tożsamości

Skonfiguruj zmienne środowiskowe przy użyciu następującego kodu. Zaktualizuj wartości zmiennych RATIFY_NAMESPACE i RATIFY_SA_NAME jeśli nie używasz wartości domyślnych. Pamiętaj, aby używać tych samych wartości podczas instalacji wykresu Ratify Helm.

export AKS_RG=<aks-resource-group-name>
export AKS_NAME=<aks-name>
export AKS_OIDC_ISSUER=$(az aks show -n $AKS_NAME -g $AKS_RG --query "oidcIssuerProfile.issuerUrl" -otsv)

export IDENTITY_RG=<identity-resource-group-name>
export IDENTITY_NAME=<identity-name>
export IDENTITY_CLIENT_ID=$(az identity show --name  $IDENTITY_NAME --resource-group $IDENTITY_RG --query 'clientId' -o tsv)
export IDENTITY_OBJECT_ID=$(az identity show --name $IDENTITY_NAME --resource-group $IDENTITY_RG --query 'principalId' -otsv)

export RATIFY_NAMESPACE="gatekeeper-system"
export RATIFY_SA_NAME="ratify-admin"

Następujące polecenie tworzy poświadczenie federacyjne dla zarządzanej tożsamości. Poświadczenie umożliwia tożsamości zarządzanej uwierzytelnianie przy użyciu tokenów wystawionych przez wystawcę OIDC, w szczególności dla konta RATIFY_SA_NAME usługi Kubernetes w przestrzeni nazw RATIFY_NAMESPACE.

az identity federated-credential create \
--name ratify-federated-credential \
--identity-name "$IDENTITY_NAME" \
--resource-group "$IDENTITY_RG" \
--issuer "$AKS_OIDC_ISSUER" \
--subject system:serviceaccount:"$RATIFY_NAMESPACE":"$RATIFY_SA_NAME"

Konfigurowanie dostępu do usługi Container Registry

Rola AcrPull jest wymagana, aby pobierać podpisy i inne metadane dla obrazów kontenerów na podstawie tożsamości. Aby przypisać rolę, użyj następującego kodu:

export ACR_SUB=<acr-subscription-id>
export ACR_RG=<acr-resource-group>
export ACR_NAME=<acr-name>

az role assignment create \
--role acrpull \
--assignee-object-id ${IDENTITY_OBJECT_ID} \
--scope subscriptions/${ACR_SUB}/resourceGroups/${ACR_RG}/providers/Microsoft.ContainerRegistry/registries/${ACR_NAME}

Konfigurowanie dostępu do usługi Key Vault

Pomiń ten krok, jeśli używasz zaufanego podpisywania do zarządzania certyfikatami.

Rola Key Vault Secrets User jest wymagana, aby tożsamość mogła pobierać cały łańcuch certyfikatów z magazynu kluczy. Aby przypisać rolę, użyj następującego kodu:

export AKV_SUB=<acr-subscription-id>
export AKV_RG=<acr-resource-group>
export AKV_NAME=<acr-name>

az role assignment create \
--role "Key Vault Secrets User" \
--assignee ${IDENTITY_OBJECT_ID} \
--scope "/subscriptions/${AKV_SUB}/resourceGroups/${AKV_RG}/providers/Microsoft.KeyVault/vaults/${AKV_NAME}"

Konfigurowanie rozwiązania Ratify w klastrze usługi AKS z włączoną usługą Azure Policy

Dzięki prawidłowo skonfigurowanym mechanizmom kontroli tożsamości i dostępu można teraz zainstalować rozwiązanie Ratify w klastrze usługi AKS. Rozwiązanie Ratify integruje się z usługą Azure Policy w celu wymuszania zasad weryfikacji podpisu. Proces instalacji obejmuje wdrożenie rozwiązania Ratify przy użyciu wykresów Helm z określonymi parametrami konfiguracji, które definiują sposób weryfikowania podpisów obrazów kontenera.

W poniższych sekcjach omówiono dwa kluczowe aspekty konfiguracji ratify:

• Opis parametrów diagramu Helm wymaganych do podejścia do zarządzania certyfikatami (Key Vault lub Trusted Signing)
• Instalowanie rozwiązania Ratify z odpowiednią konfiguracją w celu włączenia weryfikacji podpisu

Parametry konfiguracji różnią się w zależności od tego, czy używasz usługi Key Vault, czy zaufanego podpisywania na potrzeby zarządzania certyfikatami. Pamiętaj, aby postępować zgodnie z instrukcjami zgodnymi z wybranym scenariuszem.

Znajomość parametrów karty Helm

Podczas instalowania pakietu Helm dla programu Ratify należy przekazać wartości parametrów za pomocą przełącznika --set lub podając niestandardowy plik wartości. Te wartości służą do konfigurowania rozwiązania Ratify na potrzeby weryfikacji podpisu. Aby uzyskać kompleksową listę parametrów, zapoznaj się z dokumentacją Ratify Helm chart.

Instalowanie wykresu Ratify Helm z żądanymi parametrami i wartościami

Upewnij się, że wersja pakietu Ratify programu Helm to co najmniej 1.15.0, która instaluje wersję 1.4.0 rozwiązania Ratify lub nowszą. W poniższym przykładzie użyto wersji chartu Helm 1.15.0.

Skonfiguruj dodatkowe zmienne środowiskowe na potrzeby instalacji:

export CHART_VER="1.15.0"
export REPO_URI="$ACR_NAME.azurecr.io/<namespace>/<repo>"
export SUBJECT="<Subject-of-signing-certificate>"
export AKV_TENANT_ID="$(az account show --query tenantId --output tsv)"

helm repo add ratify https://notaryproject.github.io/ratify
helm repo update

helm install ratify ratify/ratify --atomic --namespace $RATIFY_NAMESPACE --create-namespace --version $CHART_VER --set provider.enableMutation=false --set featureFlags.RATIFY_CERT_ROTATION=true \
--set azureWorkloadIdentity.clientId=$IDENTITY_CLIENT_ID \
--set oras.authProviders.azureWorkloadIdentityEnabled=true \
--set azurekeyvault.enabled=true \
--set azurekeyvault.vaultURI="https://$AKV_NAME.vault.azure.net" \
--set azurekeyvault.certificates[0].name="$CERT_NAME" \
--set azurekeyvault.tenantId="$AKV_TENANT_ID" \  
--set notation.trustPolicies[0].registryScopes[0]="$REPO_URI" \
--set notation.trustPolicies[0].trustStores[0]="ca:azurekeyvault" \
--set notation.trustPolicies[0].trustedIdentities[0]="x509.subject: $SUBJECT"

export TS_ROOT_CERT_URL="https://www.microsoft.com/pkiops/certs/Microsoft%20Enterprise%20Identity%20Verification%20Root%20Certificate%20Authority%202020.crt"
export TSA_ROOT_CERT_URL="http://www.microsoft.com/pkiops/certs/microsoft%20identity%20verification%20root%20certificate%20authority%202020.crt"

# Download and convert the Trusted Signing root certificate
curl -o msft-identity-verification-root-cert-2020.crt $TS_ROOT_CERT_URL
openssl x509 -in msft-identity-verification-root-cert-2020.crt -out msft-identity-verification-root-cert-2020.pem -outform PEM
    
# Download and convert the TSA root certificate
curl -o msft-tsa-root-certificate-authority-2020.crt $TSA_ROOT_CERT_URL
openssl x509 -in msft-tsa-root-certificate-authority-2020.crt -out msft-tsa-root-certificate-authority-2020.pem -outform PEM

export TS_ROOT_CERT_FILEPATH="msft-identity-verification-root-cert-2020.pem"
export TSA_ROOT_CERT_FILEPATH="msft-tsa-root-certificate-authority-2020.pem"
export CHART_VER="1.15.0"
export REPO_URI="$ACR_NAME.azurecr.io/<namespace>/<repo>"
export SUBJECT="<Subject-of-certificate-profile>"

helm repo add ratify https://notaryproject.github.io/ratify
helm repo update

helm install ratify ratify/ratify --atomic --namespace $RATIFY_NAMESPACE --create-namespace --version $CHART_VER --set provider.enableMutation=false --set featureFlags.RATIFY_CERT_ROTATION=true \
--set azureWorkloadIdentity.clientId=$IDENTITY_CLIENT_ID \
--set oras.authProviders.azureWorkloadIdentityEnabled=true \
--set-file notationCerts[0]=$TS_ROOT_CERT_FILEPATH \
--set-file notationCerts[1]=$TSA_ROOT_CERT_FILEPATH \
--set notation.trustPolicies[0].registryScopes[0]="$REPO_URI" \
--set notation.trustPolicies[0].trustStores[0]="ca:notationCerts[0]" \
--set notation.trustPolicies[0].trustStores[1]="tsa:notationCerts[1]" \
--set notation.trustPolicies[0].trustedIdentities[0]="x509.subject: $SUBJECT"

Konfigurowanie niestandardowych zasad platformy Azure

Po pomyślnym zainstalowaniu i skonfigurowaniu rozwiązania Ratify w klastrze usługi AKS ostatnim krokiem jest utworzenie i przypisanie zasad platformy Azure, które wymusi weryfikację podpisu podczas wdrożeń kontenerów. Te zasady działają jako mechanizm wymuszania, który nakazuje klastrowi używanie rozwiązania Ratify do weryfikowania podpisów obrazów kontenera przed zezwoleniem na wdrożenia.

Usługa Azure Policy oferuje dwa tryby wymuszania:

• Deny: blokuje wdrażanie obrazów, które nie przechodzą weryfikacji podpisu, tak że tylko zaufane obrazy działają w klastrze.
• Audit: Umożliwia wszystkie wdrożenia, ale oznacza zgodne zasoby na potrzeby monitorowania i raportowania.

Audit Efekt jest przydatny podczas początkowej konfiguracji lub fazy testowania. Można go użyć do zweryfikowania konfiguracji bez ryzyka przerw w działaniu usługi (z powodu nieprawidłowych ustawień) w środowiskach produkcyjnych.

Przypisz nową politykę do twojego klastra AKS

Utwórz niestandardowe zasady platformy Azure na potrzeby weryfikacji podpisu:

export CUSTOM_POLICY=$(curl -L https://raw.githubusercontent.com/notaryproject/ratify/refs/tags/v1.4.0/library/default/customazurepolicy.json)
export DEFINITION_NAME="ratify-default-custom-policy"
export DEFINITION_ID=$(az policy definition create --name "$DEFINITION_NAME" --rules "$(echo "$CUSTOM_POLICY" | jq .policyRule)" --params "$(echo "$CUSTOM_POLICY" | jq .parameters)" --mode "Microsoft.Kubernetes.Data" --query id -o tsv)

Domyślnie efekt zasad jest ustawiony na wartość Deny. Dzięki skutkowi tej zasady obrazy, które nie przechodzą weryfikacji podpisu, są odrzucane do wdrożenia.

Alternatywnie można ustawić efekt zasad na Audit. Efekt tej polityki pozwala na wdrażanie obrazów, które nie przechodzą weryfikacji podpisu, jednocześnie oznaczając klaster AKS i powiązane obciążenia jako zgodne.

Przypisz zasady do klastra usługi AKS z domyślnym efektem Deny:

export POLICY_SCOPE=$(az aks show -g "$AKS_RG" -n "$AKS_NAME" --query id -o tsv)
az policy assignment create --policy "$DEFINITION_ID" --name "$DEFINITION_NAME" --scope "$POLICY_SCOPE"

Aby zmienić efekt zasad na Audit, możesz przekazać inny parametr do polecenia az policy assignment create. Przykład:

az policy assignment create --policy "$DEFINITION_ID" --name "$DEFINITION_NAME" --scope "$POLICY_SCOPE" -p "{\"effect\": {\"value\":\"Audit\"}}"

Aby sprawdzić status polityki niestandardowej, użyj następującego polecenia:

kubectl get constraintTemplate ratifyverification

Oto przykład danych wyjściowych pomyślnego przypisania zasad:

NAME                 AGE
ratifyverification   11m

Aby wprowadzić zmianę w istniejącym przypisaniu, musisz najpierw usunąć istniejące przypisanie, wprowadzić zmiany, a na koniec utworzyć nowe przypisanie.

Wdróż swoje obrazy i sprawdź efekty zasad

Po pomyślnym skonfigurowaniu rozwiązania Ratify i przypisaniu zasad platformy Azure do klastra usługi AKS nadszedł czas na przetestowanie funkcji weryfikacji podpisu. W poniższych sekcjach pokazano, jak działa wymuszanie zasad w praktyce, wdrażając różne typy obrazów kontenerów i obserwując wyniki.

Testujesz trzy scenariusze, aby zweryfikować konfigurację:

• Podpisane obrazy z zaufanymi certyfikatami: powinny wdrożyć się pomyślnie.
• Obrazy niepodpisane: powinny być zablokowane (z Deny efektem) lub oznaczone jako zgodne (z Audit efektem).
• Obrazy podpisane za pomocą niezaufanych certyfikatów: powinny być zablokowane (z Deny efektem) lub oznaczone jako zgodne (z Audit efektem).

Obserwowane zachowanie zależy od efektu polityki wybranego podczas przypisywania polityki Azure. Ten proces testowania pomaga upewnić się, że weryfikacja podpisu działa prawidłowo i zapewnia pewność, że tylko zaufane obrazy są dozwolone w środowisku produkcyjnym.

Stosowanie efektu polityki Odmowy

Z efektem zasad Deny, do wdrożenia dozwolone są tylko obrazy podpisane za pomocą zaufanych tożsamości. Możesz rozpocząć wdrażanie obciążeń w celu obserwacji efektów. W tym artykule opisano użycie polecenia kubectl w celu wdrożenia podu. Podobnie możesz wdrożyć obciążenia przy użyciu wykresu Helm lub szablonów, które wyzwalają instalację programu Helm.

Konfigurowanie zmiennych środowiskowych:

export IMAGE_SIGNED=<signed-image-reference>
export IMAGE_UNSIGNED=<unsigned-image-reference>
export IMAGE_SIGNED_UNTRUSTED=<signed-untrusted-image-reference>

Uruchom następujące polecenie. Ponieważ $IMAGE_SIGNED odwołuje się do obrazu podpisanego przez zaufaną tożsamość i skonfigurowanego w usłudze Ratify, jest zatwierdzony do wdrożenia.

kubectl run demo-signed --image=$IMAGE_SIGNED

Oto przykład danych wyjściowych pomyślnego wdrożenia:

pod/demo-signed created

Zmienna $IMAGE_UNSIGNED odwołuje się do obrazu, który nie jest podpisany. Zmienna $IMAGE_SIGNED_UNTRUSTED odwołuje się do obrazu podpisanego za pomocą innego certyfikatu, któremu nie ufasz. W związku z tym te dwa obrazy są odrzucone do wdrożenia. Na przykład uruchom następujące polecenie:

kubectl run demo-unsigned --image=$IMAGE_UNSIGNED

Oto przykład danych wyjściowych dla wdrożenia, które zostało odrzucone:

Error from server (Forbidden): admission webhook "validation.gatekeeper.sh" denied the request: [azurepolicy-ratifyverification-077bac5b63d37da0bc4a] Subject failed verification: $IMAGE_UNSIGNED

Aby wyświetlić dzienniki Ratify, możesz użyć następującego polecenia. Następnie możesz przeszukać dzienniki przy użyciu tekstu verification response for subject $IMAGE_UNSIGNED. Sprawdź pole errorReason, aby zrozumieć przyczynę odmowy wdrożenia.

kubectl logs <ratify-pod> -n $RATIFY_NAMESPACE

Użyj skutku polityki inspekcji

Audit W przypadku efektu zasad niepodpisane obrazy lub obrazy podpisane za pomocą niezaufanych tożsamości są dozwolone do wdrożenia. Jednak klaster AKS i powiązane składniki są oznaczone jako noncompliant. Aby uzyskać więcej informacji na temat wyświetlania niezgodnych zasobów i zrozumienia przyczyn, zobacz Pobieranie danych zgodności zasobów platformy Azure.

Czyszczenie

Użyj następujących poleceń, aby odinstalować rozwiązania Ratify i wyczyścić niestandardowe definicje zasobów Ratify (CRD):

helm delete ratify --namespace $RATIFY_NAMESPACE
kubectl delete crd stores.config.ratify.deislabs.io verifiers.config.ratify.deislabs.io certificatestores.config.ratify.deislabs.io policies.config.ratify.deislabs.io keymanagementproviders.config.ratify.deislabs.io namespacedkeymanagementproviders.config.ratify.deislabs.io namespacedpolicies.config.ratify.deislabs.io namespacedstores.config.ratify.deislabs.io namespacedverifiers.config.ratify.deislabs.io

Usuń przypisanie i definicję zasad przy użyciu następujących poleceń:

az policy assignment delete --name "$DEFINITION_NAME" --scope "$POLICY_SCOPE"
az policy definition delete --name "$DEFINITION_NAME"

Często zadawane pytania

Jak skonfigurować certyfikaty na potrzeby weryfikacji podpisu, jeśli nie mam dostępu do usługi Key Vault?

W niektórych przypadkach użytkownicy obrazów mogą nie mieć dostępu do certyfikatów używanych do weryfikacji podpisu. Aby zweryfikować podpisy, należy pobrać plik certyfikatu głównego urzędu certyfikacji w formacie PEM i określić odpowiednie parametry instalacji wykresu Helm Ratify.

Poniższe przykładowe polecenie jest podobne do poprzedniego polecenia instalacji, ale bez żadnych parametrów związanych z certyfikatami usługi Key Vault. Magazyn zaufania projektu Notary odnosi się do pliku certyfikatu przekazanego w parametrze notationCerts[0].

helm install ratify ratify/ratify --atomic --namespace $RATIFY_NAMESPACE --create-namespace --version $CHART_VER --set provider.enableMutation=false --set featureFlags.RATIFY_CERT_ROTATION=true \
--set azureWorkloadIdentity.clientId=$IDENTITY_CLIENT_ID \
--set oras.authProviders.azureWorkloadIdentityEnabled=true \
--set-file notationCerts[0]="<root-ca-certifice-filepath>"
--set notation.trustPolicies[0].registryScopes[0]="$REPO_URI" \
--set notation.trustPolicies[0].trustStores[0]="ca:notationCerts[0]" \
--set notation.trustPolicies[0].trustedIdentities[0]="x509.subject: $SUBJECT"

Ponieważ notationCerts[0] jest używany dla certyfikatu głównego urzędu certyfikacji, jeśli masz dodatkowy plik certyfikatu do celów sygnatury czasowej, pamiętaj, aby użyć poprawnego indeksu. Jeśli na przykład notationCerts[1] jest używany dla pliku certyfikatu głównego TSA, użyj magazynu zaufania notation.trustPolicies[0].trustStores[1]" z wartością "tsa:notationCerts[1]".

Jakie kroki należy wykonać, jeśli usługa Azure Policy jest wyłączona w klastrze usługi AKS?

Jeśli usługa Azure Policy jest wyłączona w klastrze usługi AKS, musisz zainstalować program OPA Gatekeeper jako kontroler zasad przed zainstalowaniem rozwiązania Ratify.

helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts

helm install gatekeeper/gatekeeper  \
--name-template=gatekeeper \
--namespace gatekeeper-system --create-namespace \
--set enableExternalData=true \
--set validatingWebhookTimeoutSeconds=5 \
--set mutatingWebhookTimeoutSeconds=2 \
--set externaldataProviderResponseCacheTTL=10s

Następnie zainstaluj aplikację Ratify zgodnie z opisem w poprzednich krokach. Po zakończeniu instalacji wymuś zasady przy użyciu następujących poleceń. Domyślnie efekt zasad jest ustawiony na wartość Deny. Aby zaktualizować plik pod kątem różnych efektów zasad, możesz zapoznać się z constraint.yaml.

kubectl apply -f https://notaryproject.github.io/ratify/library/default/template.yaml
kubectl apply -f https://notaryproject.github.io/ratify/library/default/samples/constraint.yaml

Jak zaktualizować konfiguracje ratify po zainstalowaniu rozwiązania Ratify?

Konfiguracje Ratify to niestandardowe zasoby Kubernetes. Możesz zaktualizować te zasoby bez ponownej instalacji rozwiązania Ratify:

• Aby zaktualizować konfiguracje związane z usługą Key Vault, użyj zasobu niestandardowego Ratify KeyManagementProvider z typem azurekeyvault. Aby zaktualizować konfiguracje związane z zaufanym podpisywaniem, użyj zasobu niestandardowego Ratify KeyManagementProvider z typem inline. Postępuj zgodnie z dokumentacją.
• Aby zaktualizować zasady zaufania i repozytoria Notary Project, użyj zasobu niestandardowego Ratify Verifier. Postępuj zgodnie z dokumentacją.
• Aby uwierzytelnić usługę Container Registry (lub inne rejestry zgodne z standardem OCI) i korzystać z nich, użyj zasobu niestandardowego usługi Ratify Store. Postępuj zgodnie z dokumentacją.

Co zrobić, jeśli moje obrazy kontenerów nie są podpisane za pośrednictwem narzędzia Notation?

Ten artykuł ma zastosowanie do weryfikowania podpisów Notary Project za pomocą dowolnych narzędzi, które mogą tworzyć sygnatury zgodne z projektem Notary Project. Ratify obsługuje również weryfikowanie innych typów podpisów. Aby uzyskać więcej informacji, zobacz Przewodnik użytkownika Ratify.