Verificare le firme dell'immagine del contenitore usando Ratify e Azure Policy

La sicurezza dei contenitori è fondamentale nel panorama nativo del cloud per proteggere i carichi di lavoro. Per migliorare la sicurezza durante tutto il ciclo di vita delle immagini dei contenitori, Microsoft ha introdotto il framework CSSC (Containers Secure Supply Chain). Nella fase Di distribuzione del framework le immagini del contenitore vengono distribuite negli ambienti di produzione, ad esempio i cluster del servizio Azure Kubernetes.

Garantire un ambiente di produzione sicuro comporta la gestione dell'integrità e dell'autenticità delle immagini del contenitore. Firmare le immagini del contenitore nella fase di compilazione e quindi verificarle nella fase di distribuzione consente di garantire che vengano distribuite solo immagini attendibili e non modificate.

Ratify è un progetto sandbox della Cloud Native Computing Foundation (CNCF) supportato da Microsoft. Si tratta di un motore di verifica affidabile che verifica i metadati di sicurezza delle immagini del contenitore, ad esempio le firme. Consente solo la distribuzione di immagini che soddisfano i criteri specificati.

Scenari

Questo articolo illustra due scenari principali per l'implementazione della verifica della firma delle immagini dei container usando Ratify su AKS. Gli scenari differiscono in base alla modalità di gestione dei certificati per la firma e la verifica: l'uso di Azure Key Vault per la gestione tradizionale dei certificati o l'uso del servizio firma attendibile Microsoft per la gestione del ciclo di vita dei certificati zero-touch. Scegliere lo scenario in linea con l'approccio di gestione dei certificati e i requisiti di sicurezza correnti.

Usare Key Vault per la gestione dei certificati

Un produttore di immagini crea e invia immagini di container all'Azure Container Registry all'interno di pipeline di integrazione continua e distribuzione continua (CI/CD). Queste immagini sono destinate ai consumatori di immagini per distribuire ed eseguire carichi di lavoro nativi del cloud nei cluster AKS.

Il produttore di immagini firma le immagini del contenitore in Registro Container usando gli strumenti Notary Project, in particolare Notation, all'interno delle pipeline CI/CD. Le chiavi e i certificati per la firma vengono archiviati in modo sicuro in Key Vault.

Le firme di "Notary Project" vengono create e archiviate nel Container Registry, dove fanno riferimento alle immagini corrispondenti. Un consumatore di immagini configura Ratify e i criteri nel cluster AKS per verificare le firme di Notary Project delle immagini durante la distribuzione. Le immagini che non superano la verifica della firma non vengono distribuite se l'effetto del criterio è impostato su Deny. Questa configurazione consente di garantire che nel cluster del servizio Azure Kubernetes vengano distribuite solo immagini attendibili e non modificate.

In qualità di produttore di immagini, è possibile seguire questi articoli per firmare le immagini del contenitore nel Registro Container usando Key Vault:

• Per la firma tramite certificati autofirmati, vedere Firmare immagini di contenitori usando Notation, Azure Key Vault e un certificato autofirmato.
• Per la firma tramite certificati emessi da un'autorità di certificazione (CA), vedere Firmare immagini del contenitore usando Notation, Azure Key Vault e un certificato rilasciato dall'autorità di certificazione.
• Per l'accesso alle pipeline di Azure DevOps, vedere Firmare e verificare un'immagine del contenitore usando Notation in una pipeline di Azure.
• Per l'accesso ai flussi di lavoro di GitHub, vedere Firmare un'immagine del contenitore usando Notation in GitHub Actions.

Usare la firma attendibile per la gestione dei certificati

In questo scenario, un produttore di immagini firma le immagini del container nel Container Registry utilizzando certificati gestiti dalla firma affidabile anziché da Key Vault. Poiché la firma attendibile offre la gestione del ciclo di vita dei certificati zero-touch, i produttori non devono più gestire il rilascio, la rotazione o la scadenza dei certificati.

Dal lato del consumatore, Trusted Signing produce certificati di breve durata. I consumatori di immagini configurano il timestamp nella verifica per mantenere l'attendibilità dopo la scadenza dei certificati.

Inoltre, i criteri di ratifica e cluster sono configurati su AKS per verificare le firme in fase di distribuzione. Qualsiasi immagine che non supera la verifica viene bloccata se l'effetto della policy è impostato su Deny. Il blocco garantisce che vengano distribuite solo immagini attendibili e non modificate.

In qualità di produttore di immagini, è possibile seguire questi articoli per firmare le immagini di container usando Trusted Signing.

• Firmare le immagini del container usando Notation e Firma fidata (anteprima)
• Firmare le immagini del contenitore nei flussi di lavoro di GitHub usando notazione e firma attendibile

Questo articolo guiderà l'utente nel processo di verifica delle firme delle immagini dei contenitori con Ratify e Criteri di Azure sui cluster del servizio Azure Kubernetes.

Panoramica della verifica della firma

Ecco i passaggi generali per la verifica della firma:

1. Configurare i controlli di identità e accesso per Container Registry: Configurare l'identità utilizzata da Ratify per accedere a Container Registry con i ruoli necessari.

2. Configurare i controlli di identità e accesso per Key Vault: Configurare l'identità che Ratify utilizza per accedere a Key Vault con i ruoli necessari. Ignorare questo passaggio se le immagini sono firmate tramite firma attendibile.

3. Configura Ratify nel tuo cluster AKS: configura Ratify usando un'installazione del chart di Helm come servizio Kubernetes standard.

4. Configurare criteri di Azure personalizzati: creare e assegnare criteri di Azure personalizzati con l'effetto dei criteri desiderato: Deny o Audit.

Dopo aver seguito questi passaggi, è possibile iniziare a distribuire i carichi di lavoro per osservare i risultati:

• Con l'effetto del criterio Deny, solo le immagini che superano la verifica della firma sono consentite per la distribuzione. Le immagini non firmate o firmate da identità non attendibili vengono negate.
• Con l'effetto della Audit policy, le immagini possono essere distribuite, ma i tuoi componenti vengono contrassegnati come non conformi ai fini dell'audit.

Prerequisiti

• Installare e configurare la versione più recente dell'interfaccia della riga di comando di Azure oppure eseguire i comandi in Azure Cloud Shell.
• Installare Helm per l'installazione di Ratify e installare kubectl per la risoluzione dei problemi e il controllo dello stato.
• Creare o usare un cluster AKS abilitato con un emittente OpenID Connect (OIDC) seguendo la procedura descritta in Creare un provider OpenID Connect su Azure Kubernetes Service. Questo cluster AKS è la posizione nel quale vengono distribuite le immagini del contenitore, Ratify è installato, e politiche personalizzate di Azure sono applicate.
• Connettere Registro Container al cluster del servizio Azure Kubernetes (se non è già connesso) seguendo la procedura descritta in Eseguire l'autenticazione con Registro Azure Container dal servizio Azure Kubernetes. Il Registro dei Contenitori è il luogo dove sono archiviate le immagini dei container per la distribuzione al cluster AKS.
• Abilitare il componente aggiuntivo Criteri di Azure. Per verificare che il componente aggiuntivo sia installato, o per installarlo se non è già installato, seguire i passaggi nel componente aggiuntivo Azure Policy per AKS.

Configurare i controlli di identità e accesso

Prima di installare Ratify nel cluster AKS (Azure Kubernetes Service), è necessario stabilire i controlli d'identità e di accesso appropriati. Ratify richiede l'accesso al registro dei contenitori per eseguire il pull delle immagini e delle firme dei contenitori. Quando si usa Key Vault per la gestione dei certificati, anche Ratify deve avere accesso per recuperare i certificati per la verifica della firma.

La configurazione dell'identità prevede:

• Creare un'identità gestita assegnata all'utente o utilizzare un'identità gestita già esistente.
• Configurazione delle credenziali di identità federate per abilitare l'autenticazione dell'identità del carico di lavoro.
• Concessione di assegnazioni di ruolo appropriate per l'accesso al Registro Container.
• Configurazione delle autorizzazioni di accesso di Key Vault, se si usa Key Vault per la gestione dei certificati.

Creare o usare un'identità gestita assegnata dall'utente

Se non si ha già un'identità gestita assegnata dall'utente, vedere Creare un'identità gestita assegnata dall'utente per crearne una. Ratify usa questa identità per accedere alle risorse di Azure, ad esempio Registro Container e (se applicabile) Key Vault per la gestione dei certificati.

Creare una credenziale di identità federata per la tua identità

Configurare le variabili di ambiente usando il codice seguente. Aggiornare i valori delle variabili RATIFY_NAMESPACE e RATIFY_SA_NAME , se non si usano i valori predefiniti. Assicurarsi di usare gli stessi valori durante l'installazione del Helm chart Ratify.

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"

Il comando seguente crea una credenziale federata per l'identità gestita. La credenziale consente all'identità gestita di eseguire l'autenticazione usando i token emessi da un emittente OIDC, in particolare per l'account RATIFY_SA_NAME del servizio Kubernetes nello spazio dei nomi 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"

Configurare l'accesso al Registro dei Container

Il ruolo AcrPull è necessario per permettere all'identità di eseguire il pull delle firme e altri metadati delle immagini del contenitore. Usare il codice seguente per assegnare il ruolo:

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}

Configurare l'accesso a Key Vault

Ignorare questo passaggio se si usa firma attendibile per la gestione dei certificati.

Il ruolo Key Vault Secrets User è necessario affinché l'identità possa recuperare tutta la catena di certificati dall'insieme di credenziali delle chiavi. Usare il codice seguente per assegnare il ruolo:

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

Configurare Ratify nel cluster del servizio Azure Container con i Criteri di Azure abilitati

Con i controlli di identità e di accesso configurati correttamente, è ora possibile installare *Ratify* nel cluster AKS. Ratify si integra con Azure Policy per applicare le politiche di verifica della firma. Il processo di installazione prevede la distribuzione di Ratify tramite grafici Helm con parametri di configurazione specifici che definiscono come verificare le firme delle immagini dei container.

Le sezioni seguenti illustrano due aspetti chiave della configurazione di ratifica:

• Informazioni sui parametri del grafico Helm necessari per l'approccio di gestione dei certificati (Key Vault o Firma attendibile)
• Installazione della ratifica con la configurazione appropriata per abilitare la verifica della firma

I parametri di configurazione variano a seconda che si usi Key Vault o Firma attendibile per la gestione dei certificati. Assicurarsi di seguire le istruzioni corrispondenti allo scenario scelto.

Conoscere i parametri del grafico Helm

Quando si installa il grafico Helm per La ratifica, è necessario passare valori ai parametri usando il --set flag o specificando un file di valori personalizzato. Tali valori vengono usati per configurare La ratifica per la verifica della firma. Per un elenco completo dei parametri, fare riferimento alla Ratify Helm chart documentation.

Installare un grafico Helm Ratify con parametri e valori desiderati

Assicurarsi che la versione del chart Helm sia almeno 1.15.0, il che installa la versione 1.4.0 di Ratify o una versione successiva. Nell'esempio seguente viene usata la versione 1.15.0del grafico Helm.

Configurare variabili di ambiente aggiuntive per l'installazione:

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"

Configurare criteri di Azure personalizzati

Dopo aver installato e configurato correttamente Ratify nel cluster del servizio Azure Kubernetes, il passaggio finale consiste nel creare e assegnare una Azure Policy che imponga la verifica della firma durante le distribuzioni dei contenitori. Questo criterio funge da meccanismo di enforcement che indica al cluster di usare Ratify per la verifica delle firme delle immagini dei container prima di consentire le distribuzioni.

I criteri di Azure offrono due modalità di imposizione.

• Deny: blocca la distribuzione di immagini che non superano la verifica della firma, in modo che solo le immagini attendibili vengano eseguite nel cluster.
• Audit: consente tutte le distribuzioni, ma contrassegna le risorse conformi per il monitoraggio e la generazione di report.

L'effetto Audit è utile durante le fasi iniziali di installazione o test. È possibile usarlo per convalidare la configurazione senza rischiare interruzioni del servizio (a causa di impostazioni non corrette) negli ambienti di produzione.

Assegnare una nuova policy al cluster del servizio Azure Container

Creare criteri di Azure personalizzati per la verifica della firma:

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)

Per impostazione predefinita, l'effetto dei criteri è impostato su Deny. Con questo effetto del criterio, le immagini che non superano la verifica della firma vedono impedita la distribuzione.

In alternativa, è possibile impostare l'effetto dei criteri su Audit. Questo effetto del criterio consente la distribuzione di immagini che non superano la verifica della firma, contrassegnando il cluster AKS e i carichi di lavoro correlati come conformi.

Assegnare i criteri al cluster del servizio Azure Container con l'effetto predefinito di 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"

Per modificare l'effetto dei criteri in Audit, è possibile passare un altro parametro al az policy assignment create comando . Per esempio:

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

Usare il comando seguente per controllare lo stato dei criteri personalizzati:

kubectl get constraintTemplate ratifyverification

Di seguito è riportato un esempio dell'output per un'assegnazione di criteri riuscita:

NAME                 AGE
ratifyverification   11m

Per apportare una modifica a un'assegnazione esistente, è prima necessario eliminare l'assegnazione esistente, apportare modifiche e infine creare una nuova assegnazione.

Distribuire le immagini e controllare gli effetti delle politiche

Dopo aver configurato correttamente Ratify e aver assegnato la policy di Azure al cluster AKS, è il momento di testare la funzionalità di verifica della firma. Le sezioni seguenti illustrano il funzionamento dell'applicazione dei criteri in pratica distribuendo diversi tipi di immagini del contenitore e osservando i risultati.

Si testano tre scenari per convalidare la configurazione:

• Immagini firmate con certificati attendibili: deve essere distribuita correttamente.
• Immagini senza segno: devono essere bloccate (con l'effetto Deny ) o contrassegnate come conformi (con l'effetto Audit ).
• Immagini firmate con certificati non attendibili: devono essere bloccate (con l'effetto Deny ) o contrassegnate come conformi (con l'effetto Audit ).

Il comportamento osservato dipende dagli effetti del criterio scelti quando assegni un criterio di Azure. Questo processo di test consente di garantire che la verifica della firma funzioni correttamente e garantisce che solo le immagini attendibili siano consentite nell'ambiente di produzione.

Usare l'effetto del criterio di negazione

Con l'effetto dei Deny criteri, solo le immagini firmate con identità attendibili sono consentite per la distribuzione. È possibile iniziare a distribuire i carichi di lavoro per osservare gli effetti. Questo articolo descrive l'uso del kubectl comando per distribuire un pod. Analogamente, è possibile distribuire i carichi di lavoro usando un grafico Helm o qualsiasi modello che attiva l'installazione di Helm.

Configurare le variabili di ambiente:

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

Esegui il comando seguente: Poiché $IMAGE_SIGNED fa riferimento a un'immagine firmata da un'identità attendibile e configurata in Ratifica, è consentita per la distribuzione.

kubectl run demo-signed --image=$IMAGE_SIGNED

Di seguito è riportato un esempio dell'output per una distribuzione riuscita:

pod/demo-signed created

La $IMAGE_UNSIGNED variabile fa riferimento a un'immagine non firmata. La $IMAGE_SIGNED_UNTRUSTED variabile fa riferimento a un'immagine firmata tramite un certificato diverso non attendibile. Quindi, queste due immagini vengono negate per la distribuzione. Ad esempio, eseguire il comando seguente:

kubectl run demo-unsigned --image=$IMAGE_UNSIGNED

Di seguito è riportato un esempio dell'output per una distribuzione negata:

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

È possibile usare il comando seguente per visualizzare i log di ratifica. È quindi possibile eseguire ricerche nei log usando il testo verification response for subject $IMAGE_UNSIGNED. Controllare il errorReason campo per comprendere il motivo di qualsiasi distribuzione negata.

kubectl logs <ratify-pod> -n $RATIFY_NAMESPACE

Usare l'effetto dei criteri di audit

Con l'effetto della Audit politica, sono consentite per la distribuzione immagini non firmate o immagini firmate con identità non attendibili. Tuttavia, il cluster AKS e i componenti correlati vengono contrassegnati come noncompliant. Per altre informazioni su come visualizzare le risorse non conformi e comprendere i motivi, vedere Ottenere i dati di conformità delle risorse di Azure.

Pulizia

Usare i comandi seguenti per disinstallare Ratify e pulire le definizioni di risorse personalizzate (CRD) di Ratify:

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

Eliminare l'assegnazione e la definizione dei criteri usando i comandi seguenti:

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

Domande frequenti

Come è possibile configurare i certificati per la verifica della firma se non si ha accesso a Key Vault?

In alcuni casi, gli utenti di immagini potrebbero non avere accesso ai certificati usati per la verifica delle firme. Per verificare le firme, è necessario scaricare il file del certificato CA radice in formato PEM e specificare i parametri correlati per l'installazione dell'Helm chart di Ratify.

Il comando di esempio seguente è simile al comando di installazione precedente, ma senza parametri correlati ai certificati di Key Vault. L'archivio attendibilità di Notary Project si riferisce al file di certificato passato nel parametro 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"

Poiché notationCerts[0] viene usato per il certificato CA radice, se si dispone di un file di certificato aggiuntivo a scopo di timestamp, assicurarsi di usare l'indice corretto. Ad esempio, se notationCerts[1] viene usato per il file del certificato radice TSA, usare l'archivio attendibilità notation.trustPolicies[0].trustStores[1]" con il valore "tsa:notationCerts[1]".

Quali passaggi è necessario intraprendere se Azure Policy è disabilitata nel cluster AKS?

Se il criterio di Azure è disabilitato nel cluster AKS, è necessario installare OPA Gatekeeper come controller dei criteri prima di installare 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

Installare quindi La ratifica come descritto nei passaggi precedenti. Dopo l'installazione, applicare i criteri usando i comandi seguenti. Per impostazione predefinita, l'effetto dei criteri è impostato su Deny. È possibile fare riferimento alla documentazione relativa alle violazioni di Gatekeeper per aggiornare il constraint.yaml file per diversi effetti sui criteri.

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

Come è possibile aggiornare le configurazioni di ratifica dopo l'installazione della ratifica?

Le configurazioni di ratifica sono risorse personalizzate Kubernetes. È possibile aggiornare queste risorse senza reinstallare la ratifica:

• Per aggiornare le configurazioni relative a Key Vault, usare la risorsa personalizzata KeyManagementProvider di Ratify con il tipo azurekeyvault. Per aggiornare le configurazioni correlate a Trusted Signing, usare la risorsa personalizzata Ratify KeyManagementProvider con il tipo inline. Segui la documentazione.
• Per aggiornare i criteri di attendibilità e gli archivi del Notary Project, usare la risorsa personalizzata Ratify.Verifier Segui la documentazione.
• Per eseguire l'autenticazione e l'interazione con Container Registry (o con altri registri conformi a OCI), usare la risorsa personalizzata Ratify Store. Segui la documentazione.

Cosa devo fare se le immagini del contenitore non sono firmate tramite lo strumento Notation?

Questo articolo è applicabile per verificare le firme del progetto notario in modo indipendente su qualsiasi strumento in grado di produrre firme conformi al progetto notario. La ratifica supporta anche la verifica di altri tipi di firme. Per altre informazioni, vedere la Guida utente di Ratify.