Signaturen von Containerimages mithilfe von Ratify und Azure Policy überprüfen

Containersicherheit ist in der cloudeigenen Landschaft von entscheidender Bedeutung, um Workloads zu schützen. Um die Sicherheit während des gesamten Lebenszyklus von Containerimages zu verbessern, hat Microsoft das Container Secure Supply Chain (CSSC)-Framework eingeführt. In der Bereitstellungsphase des Frameworks werden Containerimages in Produktionsumgebungen bereitgestellt, z. B. in Azure Kubernetes Service (AKS)-Clustern.

Die Sicherstellung einer sicheren Produktionsumgebung umfasst die Aufrechterhaltung der Integrität und Authentizität von Containerimages. Durch das Signieren von Containerimages in der Buildphase und anschließendes Überprüfen der Containerimages in der Bereitstellungsphase wird sichergestellt, dass nur vertrauenswürdige und unveränderte Images bereitgestellt werden.

Ratify ist ein CLOUD Native Computing Foundation (CNCF)- Sandkastenprojekt, das Microsoft unterstützt. Es ist ein robustes Überprüfungsmodul, das die Sicherheitsmetadaten von Containerimages wie Signaturen überprüft. Sie ermöglicht nur die Bereitstellung von Images, die Ihren angegebenen Richtlinien entsprechen.

Szenarien

In diesem Artikel werden zwei primäre Szenarien für die Implementierung der Signaturüberprüfung von Containerimages mithilfe von Ratify auf AKS behandelt. Die Szenarien unterscheiden sich basierend auf der Verwaltung von Zertifikaten für die Signatur und Überprüfung: Verwenden von Azure Key Vault für die herkömmliche Zertifikatverwaltung oder die Verwendung des Microsoft Trusted Signing-Diensts für die Lebenszyklusverwaltung von Zero-Touch-Zertifikaten. Wählen Sie das Szenario aus, das mit Ihrem aktuellen Zertifikatverwaltungsansatz und den Sicherheitsanforderungen übereinstimmt.

Verwenden von Key Vault für die Zertifikatverwaltung

Ein Image-Produzent erstellt Containerimages und überträgt sie innerhalb von CI/CD-Pipelines (Continuous Integration/Continuous Delivery) in die Azure Container Registry. Diese Images sind für Image-Consumer vorgesehen, um cloudeigene Workloads auf AKS-Clustern bereitzustellen und auszuführen.

Der Image-Produzent signiert Containerimages in der Container Registry mithilfe der Notary Project-Tools (insbesondere Notation) innerhalb der CI/CD-Pipelines. Die Schlüssel und Zertifikate für die Signatur werden sicher im Key Vault gespeichert.

Notary Project-Signaturen werden erstellt und in der Container Registry gespeichert, wo sie auf die entsprechenden Images verweisen. Ein Image-Konsument richtet Ratify und Richtlinien auf dem AKS-Cluster ein, um die Notary Project-Signaturen von Images während der Bereitstellung zu überprüfen. Bilder, die die Signaturprüfung nicht bestehen, werden von der Bereitstellung ausgeschlossen, wenn der Richtlinieneffekt auf Deny eingestellt ist. Mit dieser Konfiguration wird sichergestellt, dass nur vertrauenswürdige und unveränderte Images im AKS-Cluster bereitgestellt werden.

Als Bildproduzent können Sie die folgenden Artikel befolgen, um Containerimages im Container-Register mithilfe von Key Vault zu signieren.

• Informationen zum Signieren über selbstsignierte Zertifikate finden Sie unter Signieren von Containerimages mithilfe von Notation, Azure Key Vault und einem selbstsignierten Zertifikat.
• Informationen zum Signieren über von einer Zertifizierungsstelle ausgestellte Zertifikate finden Sie unter Signieren von Containerimages mithilfe von Notation, Azure Key Vault und einem von einer Zertifizierungsstelle ausgestellten Zertifikat.
• Informationen zum Anmelden in Azure DevOps-Pipelines finden Sie unter Signieren und Überprüfen eines Containerimages mithilfe von Notation in einer Azure-Pipeline.
• Informationen zum Signieren von GitHub-Workflows finden Sie unter Signieren eines Container-Images mit Notation in GitHub-Actions.

Verwenden der vertrauenswürdigen Signatur für die Zertifikatverwaltung

In diesem Szenario signiert ein Image-Produzent Container-Images in der Containerregistrierung mithilfe von Zertifikaten, die von Trusted Signing verwaltet werden, anstatt Key Vault. Da Trusted Signing die automatisierte Lebenszyklusverwaltung von Zertifikaten ohne manuelle Eingriffe bereitstellt, müssen Produzenten keine Zertifikatausstellung, -erneuerung oder -ablauf mehr managen.

Auf der Verbraucherseite erzeugt Trusted Signing kurzlebige Zertifikate. Bildkonsumenten konfigurieren die Zeitstempelung während der Überprüfung, um das Vertrauen nach dem Ablauf der Zertifikate aufrechtzuerhalten.

Darüber hinaus werden auf AKS Ratify- und Clusterrichtlinien konfiguriert, um Signaturen zum Zeitpunkt der Bereitstellung zu überprüfen. Jedes Bild, bei dem die Überprüfung fehlschlägt, wird blockiert, wenn der Richtlinieneffekt auf Deny gesetzt ist. Durch die Blockierung wird sichergestellt, dass nur vertrauenswürdige und unveränderte Images bereitgestellt werden.

Als Ersteller von Images können Sie die folgenden Artikel nutzen, um Container-Images mit Trusted Signing zu signieren.

• Signieren von Containerimages mithilfe von Notation und Trusted Signing (Vorschau)
• Signieren von Containerimages in GitHub-Workflows mithilfe von Notation und vertrauenswürdiger Signatur

Dieser Artikel führt Sie als Image-Consumer durch den Prozess der Überprüfung von Containerimagesignaturen mithilfe von Ratify und Azure Policy auf AKS-Clustern.

Übersicht über die Signaturüberprüfung

Hier sind die allgemeinen Schritte für die Signaturüberprüfung:

1. Einrichten von Identitäts- und Zugriffssteuerungen für die Containerregistrierung: Konfigurieren Sie die Identität, die Ratify für den Zugriff auf die Containerregistrierung mit den erforderlichen Rollen verwendet.

2. Einrichten von Identitäts- und Zugriffssteuerungen für Key Vault: Konfigurieren Sie die Identität, die Ratify für den Zugriff auf key Vault mit den erforderlichen Rollen verwendet. Überspringen Sie diesen Schritt, wenn Bilder über die vertrauenswürdige Signatur signiert werden.

3. Einrichten von Ratify auf Ihrem AKS-Cluster: Richten Sie Ratify mithilfe einer Helm-Chart-Installation als Standard-Kubernetes-Dienst ein.

4. Einrichten einer benutzerdefinierten Azure-Richtlinie: Erstellen und Zuweisen einer benutzerdefinierten Azure-Richtlinie mit dem gewünschten Richtlinieneffekt: Deny oder Audit.

Nachdem Sie diese Schritte ausgeführt haben, können Sie mit der Bereitstellung Ihrer Workloads beginnen, um die Ergebnisse zu beobachten:

• Durch den Deny Richtlinieneffekt können nur Bilder bereitgestellt werden, die die Signaturüberprüfung bestehen. Bilder, die nicht signiert oder von nicht vertrauenswürdigen Identitäten signiert sind, werden verweigert.
• Mit dem Audit Richtlinieneffekt können Bilder bereitgestellt werden, Ihre Komponenten werden jedoch zu Überwachungszwecken als nicht konform gekennzeichnet.

Voraussetzungen

• Installieren und konfigurieren Sie die neueste Azure CLI-Version , oder führen Sie Befehle in Azure Cloud Shell aus.
• Installieren Sie Helm für Ratify-Installation, und installieren Sie Kubectl zur Problembehandlung und Statusüberprüfung.
• Erstellen oder verwenden Sie einen AKS-Cluster, der mit einem OpenID Connect (OIDC)-Aussteller aktiviert ist, indem Sie die Schritte unter Erstellen eines OpenID Connect-Anbieters auf Azure Kubernetes Service ausführen. Dieser AKS-Cluster ist der Ort, an dem Ihre Containerimages bereitgestellt werden, Ratify installiert ist und benutzerdefinierte Azure-Richtlinien angewendet werden.
• Verbinden Sie die Containerregistrierung mit dem AKS-Cluster (sofern sie noch nicht verbunden ist), indem Sie die Schritte in der Authentifizierung mit azure Container Registry von Azure Kubernetes Service ausführen. In der Containerregistrierung werden Ihre Containerimages für die Bereitstellung in Ihrem AKS-Cluster gespeichert.
• Aktivieren Sie das Azure-Richtlinien-Add-On. Führen Sie die Schritte im Azure-Richtlinien-Add-On für AKS aus, um zu überprüfen, ob das Add-On installiert ist, oder installieren Sie es, falls es noch nicht installiert ist.

Einrichten von Identitäts- und Zugriffssteuerungen

Bevor Sie Ratify auf Ihrem AKS-Cluster installieren, müssen Sie die richtigen Identitäts- und Zugriffssteuerungen einrichten. Ratify erfordert Zugriff auf Ihre Containerregistrierung, um Containerimages und Signaturen abzurufen. Wenn Sie Key Vault für die Zertifikatverwaltung verwenden, benötigt Ratify auch Zugriff, um Zertifikate für die Signaturüberprüfung abzurufen.

Die Identitätskonfiguration umfasst Folgendes:

• Erstellen einer vom Benutzer zugewiesenen verwalteten Identität oder Verwenden einer vorhandenen Identität.
• Einrichten von Verbundidentitätsanmeldedaten zur Aktivierung der Arbeitslastidentitätsauthentifizierung.
• Gewähren geeigneter Rollenzuweisungen für den Containerregistrierungszugriff.
• Konfigurieren der Zugriffsberechtigungen für Key Vault, wenn Sie Key Vault zur Zertifikatverwaltung verwenden.

Erstellen oder Verwenden einer vom Benutzer zugewiesenen verwalteten Identität

Wenn Sie noch nicht über eine vom Benutzer zugewiesene verwaltete Identität verfügen, lesen Sie Erstellen einer vom Benutzer zugewiesenen verwalteten Identität, um eine Identität zu erstellen. Ratify verwendet diese Identität für den Zugriff auf Azure-Ressourcen, z. B. Containerregistrierung und (falls zutreffend) Key Vault für die Zertifikatverwaltung.

Erstellen Sie Anmeldeinformationen für eine Verbundidentität für Ihre Identität

Richten Sie Umgebungsvariablen mithilfe des folgenden Codes ein. Aktualisieren Sie die Werte der Variablen RATIFY_NAMESPACE , und RATIFY_SA_NAME wenn Sie die Standardwerte nicht verwenden. Achten Sie darauf, während der Installation des Ratify Helm-Diagramms dieselben Werte zu verwenden.

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"

Mit dem folgenden Befehl wird ein verbundenes Anmeldezertifikat für Ihre verwaltete Identität erstellt. Die Berechtigungsnachweise ermöglichen der verwalteten Identität die Authentifizierung mithilfe von Tokens, die ein OIDC-Aussteller ausstellt, ausdrücklich für das Kubernetes-Dienstkonto RATIFY_SA_NAME im Namespace 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"

Konfigurieren des Zugriffs auf die Containerregistrierung

Die AcrPull-Rolle ist erforderlich, damit Ihre Identität Signaturen und andere Metadaten für Containerimages pullen kann. Verwenden Sie den folgenden Code, um die Rolle zuzuweisen:

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}

Konfigurieren des Zugriffs auf Key Vault

Überspringen Sie diesen Schritt, wenn Sie die vertrauenswürdige Signatur für die Zertifikatverwaltung verwenden.

Die Key Vault Secrets User-Rolle ist erforderlich, damit Ihre Identität die gesamte Zertifikatkette aus Ihrem Schlüsseltresor abruft. Verwenden Sie den folgenden Code, um die Rolle zuzuweisen:

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}"

Einrichten von Ratify auf Ihrem AKS-Cluster mit aktivierter Azure-Richtlinie

Nachdem die Identitäts- und Zugriffssteuerungen ordnungsgemäß konfiguriert wurden, können Sie ratify jetzt auf Ihrem AKS-Cluster installieren. Ratify integriert sich mit Azure-Richtlinien, um Signaturprüfungsrichtlinien zu erzwingen. Der Installationsprozess umfasst die Bereitstellung von Ratify mithilfe von Helm-Charts mit bestimmten Konfigurationsparametern, die definieren, wie Container-Image-Signaturen überprüft werden sollen.

In den folgenden Abschnitten werden zwei wichtige Aspekte der Ratify-Einrichtung behandelt:

• Grundlegendes zu den Helm-Diagrammparametern, die für Ihren Zertifikatverwaltungsansatz erforderlich sind (Key Vault oder vertrauenswürdige Signatur)
• Installieren von Ratify mit der entsprechenden Konfiguration zum Aktivieren der Signaturüberprüfung

Die Konfigurationsparameter variieren je nachdem, ob Sie Key Vault oder vertrauenswürdige Signatur für die Zertifikatverwaltung verwenden. Befolgen Sie unbedingt die Anweisungen, die Ihrem ausgewählten Szenario entsprechen.

Kennen Sie Ihre Helm-Chart-Parameter

Wenn Sie das Helm-Chart für Ratify installieren, müssen Sie Werte an Parameter übergeben, indem Sie das --set-Flag verwenden oder eine benutzerdefinierte Wertedatei bereitstellen. Diese Werte werden verwendet, um ratify für die Signaturüberprüfung zu konfigurieren. Eine umfassende Liste der Parameter finden Sie in der Dokumentation zu Ratify Helm-Diagrammen.

Installieren eines Ratify Helm-Diagramms mit den gewünschten Parametern und Werten

Stellen Sie sicher, dass die Ratify Helm-Chart-Version mindestens 1.15.0 ist, wodurch Ratify Version 1.4.0 oder höher installiert wird. Im folgenden Beispiel wird die Helm-Diagrammversion 1.15.0verwendet.

Richten Sie zusätzliche Umgebungsvariablen für die Installation ein:

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"

Einrichten einer benutzerdefinierten Azure-Richtlinie

Nachdem Ratify erfolgreich auf Ihrem AKS-Cluster installiert und konfiguriert wurde, besteht der letzte Schritt darin, eine Azure-Richtlinie zu erstellen und zuzuweisen, die die Signaturüberprüfung während containerbereitstellungen erzwingt. Diese Richtlinie fungiert als Erzwingungsmechanismus, der den Cluster anweist, Ratify zum Überprüfen von Containerimagesignaturen zu verwenden, bevor Bereitstellungen zugelassen werden.

Azure-Richtlinie bietet zwei Erzwingungsmodi:

• Deny: Blockiert die Bereitstellung von Images, bei denen die Signaturüberprüfung fehlschlägt, sodass nur vertrauenswürdige Images in Ihrem Cluster ausgeführt werden.
• Audit: Ermöglicht alle Bereitstellungen, kennzeichnet jedoch kompatible Ressourcen für Überwachungs- und Berichterstellungszwecke.

Der Audit Effekt ist während der anfänglichen Einrichtungs- oder Testphasen nützlich. Sie können sie verwenden, um Ihre Konfiguration zu überprüfen, ohne Dienstunterbrechungen (aufgrund falscher Einstellungen) in Produktionsumgebungen zu riskieren.

Weisen Sie Ihrem AKS-Cluster eine neue Richtlinie zu.

Erstellen Sie eine benutzerdefinierte Azure-Richtlinie für die Signaturüberprüfung:

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)

Standardmäßig ist der Richtlinieneffekt auf Deny gesetzt. Bei diesem Richtlinieneffekt werden Images, bei denen die Signaturüberprüfung fehlschlägt, die Bereitstellung verweigert.

Alternativ können Sie den Richtlinieneffekt auf Audit. Dieser Richtlinieneffekt ermöglicht die Bereitstellung von Images, bei denen die Signaturüberprüfung fehlschlägt, während der AKS-Cluster und zugehörige Workloads als kompatibel gekennzeichnet werden.

Weisen Sie die Richtlinie Ihrem AKS-Cluster mit der Standardwirkung zu 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"

Um den Richtlinieneffekt zu Auditändern, können Sie einen anderen Parameter an den az policy assignment create Befehl übergeben. Beispiel:

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

Verwenden Sie den folgenden Befehl, um den benutzerdefinierten Richtlinienstatus zu überprüfen:

kubectl get constraintTemplate ratifyverification

Hier ist ein Beispiel für die Ausgabe für eine erfolgreiche Richtlinienzuweisung:

NAME                 AGE
ratifyverification   11m

Um eine Änderung an einer vorhandenen Aufgabe vorzunehmen, müssen Sie zuerst die vorhandene Aufgabe löschen, Änderungen vornehmen und schließlich eine neue Aufgabe erstellen.

Bereitstellen von Images und Überprüfen der Richtlinieneffekte

Nachdem Sie die Azure-Richtlinie nun erfolgreich konfiguriert und Ihrem AKS-Cluster zugewiesen haben, ist es an der Zeit, die Signaturüberprüfungsfunktion zu testen. In den folgenden Abschnitten wird gezeigt, wie die Richtlinienerzwingung in der Praxis funktioniert, indem verschiedene Typen von Containerimages bereitgestellt und die Ergebnisse beobachtet werden.

Sie testen drei Szenarien, um Ihr Setup zu überprüfen:

• Signierte Images mit vertrauenswürdigen Zertifikaten: Sollte erfolgreich bereitgestellt werden.
• Nicht signierte Bilder: Sollte blockiert (mit dem Deny Effekt) oder als konform (mit dem Audit Effekt) gekennzeichnet werden.
• Mit nicht vertrauenswürdigen Zertifikaten signierte Bilder: Sollte blockiert (mit dem Deny Effekt) oder als konform (mit dem Audit Effekt) gekennzeichnet werden.

Das Verhalten, das Sie beachten, hängt von dem Richtlinieneffekt ab, den Sie beim Zuweisen einer Azure-Richtlinie ausgewählt haben. Mit diesem Testprozess wird sichergestellt, dass die Signaturüberprüfung ordnungsgemäß funktioniert und dass nur vertrauenswürdige Bilder in Ihrer Produktionsumgebung zulässig sind.

Verwenden Sie den Richtlinieneffekt "Verweigern"

Mit dem Deny-Richtlinieneffekt sind nur Images, die mit vertrauenswürdigen Identitäten signiert sind, für die Bereitstellung zulässig. Sie können mit der Bereitstellung Ihrer Workloads beginnen, um die Auswirkungen zu überwachen. In diesem Artikel wird die Verwendung des kubectl Befehls zum Bereitstellen eines Pods beschrieben. Ebenso können Sie Ihre Workloads mithilfe eines Helmdiagramms oder beliebiger Vorlagen bereitstellen, die die Helm-Installation auslösen.

Einrichten von Umgebungsvariablen:

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

Führen Sie den folgenden Befehl aus. Da $IMAGE_SIGNED auf ein Image verwiesen wird, das von einer vertrauenswürdigen Identität signiert und in Ratify konfiguriert ist, ist es für die Bereitstellung zulässig.

kubectl run demo-signed --image=$IMAGE_SIGNED

Hier ist ein Beispiel für die Ausgabe für eine erfolgreiche Bereitstellung:

pod/demo-signed created

Die $IMAGE_UNSIGNED Variable verweist auf ein Bild, das nicht signiert ist. Die $IMAGE_SIGNED_UNTRUSTED Variable verweist auf ein Bild, das über ein anderes Zertifikat signiert ist, dem Sie nicht vertrauen. Daher werden diese beiden Images für die Bereitstellung abgelehnt. Führen Sie beispielsweise den folgenden Befehl aus:

kubectl run demo-unsigned --image=$IMAGE_UNSIGNED

Hier ist ein Beispiel für die Ausgabe für eine Bereitstellung, die abgelehnt wird:

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

Sie können den folgenden Befehl verwenden, um Ratify-Protokolle anzuzeigen. Anschließend können Sie die Protokolle mithilfe des Texts verification response for subject $IMAGE_UNSIGNEDdurchsuchen. Überprüfen Sie das errorReason Feld, um den Grund für eine verweigerte Bereitstellung zu verstehen.

kubectl logs <ratify-pod> -n $RATIFY_NAMESPACE

Verwenden der Auswirkung „Überwachungsrichtlinie“

Mit dem Audit Richtlinieneffekt sind nicht signierte Bilder oder Bilder, die mit nicht vertrauenswürdigen Identitäten signiert sind, für die Bereitstellung zulässig. Der AKS-Cluster und die zugehörigen Komponenten werden jedoch als noncompliantgekennzeichnet. Weitere Informationen dazu, wie Sie nicht kompatible Ressourcen anzeigen und die Gründe verstehen, finden Sie unter Abrufen von Compliancedaten von Azure-Ressourcen.

Aufräumen

Verwenden Sie die folgenden Befehle, um Ratify zu deinstallieren und benutzerdefinierte Ressourcendefinitionen (Ratify) zu bereinigen:Use the following commands to uninstall Ratify and clean up Ratify custom resource definitions (CRDs):

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

Löschen Sie die Richtlinienzuweisung und -definition mithilfe der folgenden Befehle:

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

Häufig gestellte Fragen

Wie kann ich Zertifikate für die Signaturüberprüfung einrichten, wenn ich keinen Zugriff auf Key Vault habe?

In einigen Fällen haben Bildanwender möglicherweise keinen Zugriff auf die Zertifikate, die für die Signaturüberprüfung verwendet werden. Um Signaturen zu überprüfen, müssen Sie die Zertifikatdatei der Stammzertifizierungsstelle im PEM-Format herunterladen und die zugehörigen Parameter für die Installation des Ratify Helm-Diagramms angeben.

Der folgende Beispielbefehl ähnelt dem vorherigen Installationsbefehl, aber ohne Parameter im Zusammenhang mit Key Vault-Zertifikaten. Der Vertrauensspeicher des Notarprojekts bezieht sich auf die Zertifikatdatei, die im Parameter notationCerts[0]übergeben wurde.

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"

Da notationCerts[0] für das Zertifikat der Stammzertifizierungsstelle verwendet wird, müssen Sie, wenn Sie über eine zusätzliche Zertifikatdatei für Zeitstempel verfügen, den richtigen Index verwenden. Wenn notationCerts[1] für die TSA-Stammzertifikatdatei verwendet wird, nutzen Sie den Vertrauensspeicherort notation.trustPolicies[0].trustStores[1]" mit dem Wert "tsa:notationCerts[1]".

Welche Schritte sollte ich ausführen, wenn Azure Policy in meinem AKS-Cluster deaktiviert ist?

Wenn Azure Policy in Ihrem AKS-Cluster deaktiviert ist, müssen Sie OPA Gatekeeper als Richtliniencontroller installieren, bevor Sie Ratify installieren.

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

Installieren Sie dann Ratify, wie in den vorherigen Schritten beschrieben. Erzwingen Sie nach der Installation Richtlinien mithilfe der folgenden Befehle. Standardmäßig ist der Richtlinieneffekt auf Deny gesetzt. Sie können auf die Dokumentation zu Gatekeeper-Verstößen verweisen, um die constraint.yaml Datei für verschiedene Richtlinieneffekte zu aktualisieren.

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

Wie kann ich Ratify-Konfigurationen aktualisieren, nachdem Ratify installiert wurde?

Ratify-Konfigurationen sind benutzerdefinierte Kubernetes-Ressourcen. Sie können diese Ressourcen aktualisieren, ohne Ratify erneut zu installieren:

• Um Key Vault-bezogene Konfigurationen zu aktualisieren, verwenden Sie die benutzerdefinierte Ressource „Ratify KeyManagementProvider“ mit dem Typ „azurekeyvault“. Um Konfigurationen im Bezug auf die vertrauensvolle Signatur zu aktualisieren, verwenden Sie die benutzerdefinierte Ressource „Ratify KeyManagementProvider“ mit dem Typ „inline“. Folgen Sie der Dokumentation.
• Um die Vertrauensrichtlinien und Speicherorte des Notary Project zu aktualisieren, verwenden Sie die benutzerdefinierte Ressource Ratify Verifier. Folgen Sie der Dokumentation.
• Zur Authentifizierung und Interaktion mit Container Registry (oder anderen OCI-kompatiblen Registries) verwenden Sie die benutzerdefinierte Ressource „Ratify Store“. Folgen Sie der Dokumentation.

Was sollte ich tun, wenn meine Containerimages nicht über das Notation-Tool signiert sind?

Dieser Artikel gilt für die unabhängige Überprüfung von Notarprojektsignaturen auf allen Tools, die notarisch projektkonforme Signaturen erzeugen können. Ratify unterstützt auch die Überprüfung anderer Signaturtypen. Weitere Informationen finden Sie im Ratify-Handbuch.