Schützen von AKS-Workloads: Überprüfen von Containerimagesignaturen mit Ratify und Azure Policy

Einleitung

Containersicherheit ist in der cloudeigenen Landschaft entscheidend, um Workloads zu schützen. Um dies zu beheben, hat Microsoft das Containers Secure Supply Chain (CSSC)-Frameworkeingeführt, wodurch die Sicherheit während des gesamten Lebenszyklus von Containerimages verbessert wird. Eine der Phasen, die im CSSC-Framework definiert sind, ist die Deploy Phase, in der Containerimages in Produktionsumgebungen bereitgestellt werden, z. B. Azure Kubernetes Service (AKS)-Cluster. Die Sicherstellung einer sicheren Produktionsumgebung umfasst die Aufrechterhaltung der Integrität und Authentizität von Containerimages. Dies wird erreicht, indem Containerimages in der Buildphase signiert und dann in der Bereitstellungsphase überprüft werden, um sicherzustellen, dass nur vertrauenswürdige und unveränderte Images bereitgestellt werden.

Ratify, ein CNCF Sandkastenprojekt, das von Microsoft unterstützt wird, ist ein robustes Überprüfungsmodul, das Containerimage-Sicherheitsmetadaten wie Signaturen überprüft und nur die Bereitstellung von Images zulässt, die Ihren angegebenen Richtlinien entsprechen.

Szenario

Ein Image-Produzent erstellt und überträgt Containerimages in CI/CD-Pipelines zu der Azure Container Registry (ACR). Diese Images sind für die Bereitstellung und Ausführung von cloudeigenen Workloads auf AKS-Clustern durch Image-Consumer vorgesehen. Der Bild-Ersteller signiert die Containerimages in ACR unter Verwendung des Notarprojekt Tools, speziell Notation, innerhalb der CI/CD-Pipelines. Die Schlüssel und Zertifikate für die Signatur werden sicher im Azure Key Vault (AKV) gespeichert. Nach dem Signieren werden Notary-Projekt-Signaturen erstellt und in ACR gespeichert, wobei auf die entsprechenden Bilder verwiesen wird. Ein Image-Nutzer richtet Ratify und Richtlinien für den AKS-Cluster ein, um die Signaturen des Notary-Projekts von Images während der Bereitstellung zu validieren. Images, die die Signaturüberprüfung nicht bestehen, werden von der Bereitstellung ausgeschlossen, wenn der Richtlinieneffekt auf 'verweigern' festgelegt ist. Dadurch wird sichergestellt, dass nur vertrauenswürdige und unveränderte Images im AKS-Cluster bereitgestellt werden.

Folgen Sie als Image-Produzent den folgenden Dokumenten, um Containerimages in ACR zu signieren:

• Informationen zum Signieren mit selbstsignierten Zertifikaten finden Sie unter Signieren von Containerimages mit Notation CLI und AKV mithilfe von selbstsignierten Zertifikaten
• Informationen zum Signieren mithilfe von zertifizierungsstellen ausgestellten Zertifikaten finden Sie unter Signieren von Containerimages mit Notation CLI und AKV mithilfe von zertifizierungsstellen ausgestellten Zertifikaten
• Um Containerimages in Azure DevOps (ADO)-Pipelines zu signieren, siehe Signieren von Containerimages in Azure DevOps (ADO)-Pipelines.
• Informationen zum Anmelden in GitHub-Workflows finden Sie unter Signieren von Containerimages in GitHub-Workflows

Dieses Dokument führt Sie als Bildkonsument durch den Prozess der Überprüfung von Container-Imagesignaturen mit Ratify und den Azure-Richtlinien 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: Konfigurieren Sie die von Ratify verwendete Identität für den Zugriff auf ACR und AKV mit den erforderlichen Rollen.

2. : Einrichtung von Ratify auf Ihrem AKS-Cluster: Einrichtung von Ratify mithilfe der Helm Chart-Installation als Standard-Kubernetes-Dienst.

3. 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. Mit der richtlinie Deny Effekt sind nur Bilder, die die Signaturüberprüfung bestanden haben, für die Bereitstellung zulässig, während Bilder, die nicht signiert oder von nicht vertrauenswürdigen Identitäten signiert sind, verweigert werden. Mit der Audit Effektrichtlinie können Bilder bereitgestellt werden, Ihre Komponente wird jedoch zu Überwachungszwecken als nicht konform gekennzeichnet.

Voraussetzungen

• Installieren und konfigurieren Sie die neuesten Azure CLI, oder führen Sie Befehle in der Azure Cloud Shellaus.
• Installieren Sie Helm- zur Ratify-Installation und kubectl- zur Problembehandlung und Statusüberprüfung.
• Erstellen oder verwenden Sie einen AKS-Cluster, der mit einem OIDC-Herausgeber aktiviert ist, indem Sie die Schritte in 'Konfigurieren eines AKS-Clusters mit einem OpenID Connect (OIDC)-Herausgeber' unter ausführen. Dieser AKS-Cluster ist der Ort, an dem Ihre Containerimages bereitgestellt werden, Ratify installiert wird und benutzerdefinierte Azure-Richtlinien angewendet werden.
• Verbinden Sie das ACR mit dem AKS-Cluster, wenn dies noch nicht verbunden ist, indem Sie die Schritte in Authentifizieren mit ACR von AKSausführen. Die ACR ist der Speicherort, an dem Ihre Containerimages für die Bereitstellung in Ihrem AKS-Cluster gespeichert werden.
• Aktivieren Sie das Azure-Richtlinien-Add-On. Um zu überprüfen, ob das Add-on installiert ist, oder es zu installieren, falls dies noch nicht der Fall ist, führen Sie die Schritte in Azure-Richtlinien-Add-on für AKSaus.

Einrichten von Identitäts- und Zugriffssteuerungen

Erstellen oder Verwenden einer vom Benutzer zugewiesenen verwalteten Identität

Wenn Sie noch nicht über eine vom Benutzer zugewiesene verwaltete Identität verfügen, folgen Sie diesem Dokument, um eine zu erstellen. Diese Identität wird von Ratify verwendet, um auf Azure-Ressourcen wie ACR und AKV zuzugreifen.

Erstellen Sie einen Verbundidentitätsnachweis für Ihr Konto.

Einrichten von Umgebungsvariablen:

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"

Der folgende Befehl erstellt eine Verbundanmeldeinformation für Ihre verwaltete Identität, sodass sie sich mithilfe von Token authentifizieren kann, die von einem OIDC-Aussteller ausgestellt wurden, insbesondere für ein 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 Sie den Zugriff für Ihre Identität

Konfigurieren des Zugriffs auf ACR

Die AcrPull Rolle ist erforderlich, damit Ihre Identität Signaturen und andere Containerimagemetadaten abruft. Verwenden Sie die folgenden Anweisungen, 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 AKV

Die Key Vault Secrets User Rolle ist erforderlich, damit Ihre Identität die gesamte Zertifikatkette aus Ihrem AKV abruft. Verwenden Sie die folgenden Anweisungen, um die Rolle zuzuweisen:

Richten Sie zusätzliche Umgebungsvariablen für die AKV-Ressource ein:

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

Verstehen Sie die Parameter Ihres Helm-Chart

Beim Installieren des Helm-Charts für Ratify müssen Sie Werte mithilfe des --set-Flags oder durch Bereitstellen einer benutzerdefinierten Wertedatei an die Parameter übergeben. Diese Werte werden verwendet, um ratify für die Signaturüberprüfung zu konfigurieren. Eine umfassende Liste der Parameter finden Sie in der Ratify Helm-Diagrammdokumentation.

Für dieses Szenario müssen Sie Folgendes konfigurieren:

• Die Identität, die wir zuvor für den Zugriff auf ACR und AKV eingerichtet haben
• Das in AKV gespeicherte Zertifikat zur Signaturüberprüfung
• Eine Notary Project-Vertrauensrichtlinie zur Signaturverifikation, einschließlich registryScopes, trustStores und trustedIdentities.

Ausführliche Informationen finden Sie in der folgenden Parametertabelle:

Durch die Verwendung des Zeitstempels für Ihre Bilder können Sie sicherstellen, dass bilder, die vor Ablauf des Zertifikats signiert wurden, weiterhin erfolgreich überprüft werden können, sodass vorhandene Bilder nicht erneut signiert werden müssen. Sie können zusätzliche Parameter wie folgt angeben:

Wenn Sie über mehrere Zertifikate für die Signaturüberprüfung verfügen, können Sie z. B. zusätzliche Parameter und Werte angeben.

Installieren Sie das Ratify Helm Chart mit den gewünschten Parametern und Werten.

Stellen Sie sicher, dass die Ratify Helm-Chart-Version mindestens 1.15.0ist, was die Installation von Ratify-Version 1.4.0 oder höher ermöglicht. In diesem Beispiel wird die Helm-Chart-Version 1.15.0 verwendet.

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://ratify-project.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"

Einrichten einer benutzerdefinierten Azure-Richtlinie

Zuweisen einer neuen Richtlinie zu Ihrem AKS-Cluster

Erstellen Sie eine benutzerdefinierte Azure-Richtlinie für die Signaturüberprüfung. Standardmäßig ist der Richtlinieneffekt auf Denyfestgelegt, d. h. Images, bei denen die Signaturüberprüfung fehlschlägt, wird die Bereitstellung verweigert. Alternativ können Sie den Richtlinieneffekt auf Auditkonfigurieren, sodass Bilder, bei denen die Signaturüberprüfung fehlschlägt, bereitgestellt werden, während sie den AKS-Cluster und zugehörige Workloads als nicht kompatibel markieren. Der Audit Effekt ist nützlich, um ihre Signaturüberprüfungskonfiguration zu überprüfen, ohne Ausfälle aufgrund falscher Einstellungen für Ihre Produktionsumgebung zu riskieren.

export CUSTOM_POLICY=$(curl -L https://raw.githubusercontent.com/ratify-project/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)

Weisen Sie die Richtlinie Ihrem AKS-Cluster mit dem Standardeffekt Denyzu.

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 in Auditzu ändern, können Sie zusätzliche Parameter an az policy assignment create Befehl übergeben. Zum 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

Nachfolgend finden Sie ein Beispiel für die Ausgabe einer erfolgreichen 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.

Images bereitstellen und die Auswirkungen der Richtlinien überprüfen

Verwende die Richtlinienwirkung "Verweigern"

Mit der Deny Richtlinienauswirkung sind nur Bilder zur Bereitstellung zulässig, die mit vertrauenswürdigen Identitäten signiert sind. Sie können mit der Bereitstellung Ihrer Workloads beginnen, um die Auswirkungen zu beobachten. In diesem Dokument verwenden wir den Befehl kubectl, um einen einfachen Pod bereitzustellen. 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 verweist, 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

Nachfolgend finden Sie ein Beispiel für die Ausgabe für eine erfolgreiche Bereitstellung:

pod/demo-signed created

$IMAGE_UNSIGNED verweist auf ein nicht signiertes Bild. $IMAGE_SIGNED_UNTRUSTED verweist auf ein Bild, das mit einem anderen Zertifikat signiert ist, dem Sie nicht vertrauen. Daher werden diese beiden Images für die Bereitstellung verweigert. Führen Sie beispielsweise den folgenden Befehl aus:

kubectl run demo-unsigned --image=$IMAGE_UNSIGNED

Im Folgenden finden Sie ein Beispiel für die Ausgabe für eine Bereitstellung, die verweigert 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 auszugeben und das Protokoll mit Text verification response for subject $IMAGE_UNSIGNEDzu durchsuchen, überprüfen Sie das Feld errorReason, um den Grund für jede verweigerte Bereitstellung zu verstehen.

kubectl logs <ratify-pod> -n $RATIFY_NAMESPACE

Auditrichtlinien-Effekt verwenden

Mit der Überwachungsrichtlinie können unsignierte Bilder oder Bilder, die mit nicht vertrauenswürdigen Identitäten signiert sind, bereitgestellt werden. Der AKS-Cluster und die zugehörigen Komponenten werden jedoch als non-compliantgekennzeichnet. Weitere Informationen zum Anzeigen nicht konformer Ressourcen und zum Verständnis der Gründe finden Sie unter Abrufen der Azure-Richtlinien-Compliance-Daten.

Aufräumen

Verwenden Sie die folgenden Befehle zum Deinstallieren von Ratify und Bereinigen von Ratify 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 AKV habe?

In einigen Fällen haben Bildkonsumenten 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 Ratify Helm-Diagramminstallation angeben. Nachfolgend sehen Sie einen Beispielbefehl ähnlich dem vorherigen Installationsbefehl, aber ohne Parameter im Zusammenhang mit AKV-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"

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

Wenn Azure Policy auf 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 Denyfestgelegt. Sie können auf das Dokument zu Gatekeeper-Verstößen verweisen, um die constraint.yaml für verschiedene Auswirkungen der Richtlinie zu aktualisieren.

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

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

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

• Verwenden Sie zum Aktualisieren von AKV-bezogenen Konfigurationen die benutzerdefinierte Ressource Ratify KeyManagementProvider. Folgen Sie der Dokumentation.
• Um Notäre Project-Vertrauensrichtlinien und -speicher zu aktualisieren, verwenden Sie die Ratify-Verifier benutzerdefinierte Ressource. Folgen Sie der Dokumentation .
• Verwenden Sie die benutzerdefinierte Ressource Ratify Store, um ACR (oder andere OCI-kompatible Registrierungen) zu authentifizieren und zu interagieren. Folgen Sie den Anweisungen in der Dokumentation.

Was sollte ich tun, wenn meine Containerimages nicht mit dem Notation-Tool signiert sind?

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