Verificar assinaturas de imagem de contêiner usando o Ratify e o Azure Policy

A segurança do contêiner é crucial no cenário nativo de nuvem para ajudar a proteger cargas de trabalho. Para aprimorar a segurança em todo o ciclo de vida das imagens de contêiner, a Microsoft introduziu a estrutura CSSC (Containers Secure Supply Chain). Na fase de Implantação da estrutura, as imagens de contêiner são implantadas em ambientes de produção, como clusters do Serviço de Kubernetes do Azure (AKS).

Garantir um ambiente de produção seguro envolve manter a integridade e a autenticidade das imagens de contêiner. Assinar imagens de contêiner no estágio de Build e verificá-las no estágio de Deploy ajuda a garantir que apenas imagens confiáveis e inalteradas sejam implantadas.

O Ratify é um projeto sandbox da Cloud Native Computing Foundation (CNCF) que a Microsoft apoia. É um mecanismo de verificação robusto que verifica os metadados de segurança de imagens de contêiner, como assinaturas. Ele permite apenas a implantação de imagens que atendem às políticas especificadas.

Cenários

Este artigo aborda dois cenários principais para implementar a verificação de assinatura de imagens de contêiner usando o Ratify no AKS. Os cenários diferem com base em como você gerencia certificados para assinatura e verificação: usando o Azure Key Vault para gerenciamento de certificados tradicional ou usando o serviço de Assinatura de Artefatos da Microsoft para gerenciamento de ciclo de vida de certificado de toque zero. Escolha o cenário que se alinha com sua abordagem atual de gerenciamento de certificados e requisitos de segurança.

Usar o Key Vault para gerenciamento de certificados

Um produtor de imagens cria e faz o push de imagens de contêiner para o Registro de Contêineres do Azure nos pipelines de integração contínua e entrega contínua (CI/CD). Essas imagens são destinadas aos consumidores de imagem para implantarem e executarem cargas de trabalho nativas de nuvem nos clusters do AKS.

O produtor de imagens assina imagens de contêiner no Registro de Contêineres usando as ferramentas do Projeto Notário (especificamente, Notation) nos pipelines de CI/CD. As chaves e certificados para assinatura são armazenados com segurança no Key Vault.

As assinaturas do Projeto Notary são criadas e armazenadas no Registro de Contêiner, em que fazem referência às imagens correspondentes. Um consumidor de imagem configura o Ratify e as políticas no cluster do AKS para verificar as assinaturas do Projeto Notário de imagens durante a implantação. As imagens que falham na verificação de assinatura serão impedidas de serem implantadas se o efeito da política for definido como Deny. Essa configuração ajuda a garantir que apenas imagens confiáveis e nãoteradas sejam implantadas no cluster do AKS.

Como produtor de imagens, você pode seguir estes artigos para assinar imagens de contêiner no Registro de Contêiner usando o Key Vault:

• Para assinar por meio de certificados autoassinados, consulte Assinar imagens de contêiner usando Notation, Azure Key Vault e um certificado autoassinado.
• Para assinar por meio de certificados emitidos por uma AC (autoridade de certificação), consulte Assinar imagens de contêiner usando Notation, Azure Key Vault e um certificado emitido pela AC.
• Para entrar em Azure Pipelines, consulte Assinar e verificar uma imagem de contêiner usando Notação em um Azure Pipeline.
• Para entrar em fluxos de trabalho do GitHub, consulte Assinar uma imagem de contêiner usando Notação no GitHub Actions.

Use a assinatura de artefatos para gerenciamento de certificados

Nesse cenário, um produtor de imagens assina imagens de contêiner no Registro de Contêiner usando certificados gerenciados pela Assinatura de Artefatos em vez do Key Vault. Como a Assinatura de Artefato fornece gerenciamento automático (sem intervenção manual) do ciclo de vida dos certificados, os produtores não precisam mais lidar com a emissão, rotação ou expiração de certificados.

No lado do consumidor, a Assinatura de Artefato produz certificados de curta duração. Os consumidores de imagem configuram o carimbo de data/hora durante a verificação para manterem a confiança após o vencimento dos certificados.

Além disso, as políticas do Ratify e do cluster são configuradas no AKS para verificar assinaturas no momento da implantação. Qualquer imagem que falhar na verificação será bloqueada se o efeito da política for definido como Deny. O bloqueio ajuda a garantir que apenas imagens confiáveis e inalteradas sejam implantadas.

Como gerador de imagens, você pode seguir estes artigos para assinar imagens de contêiner usando a Assinatura de Artefatos.

• Assinar imagens de contêiner usando Notação e Assinatura de Artefatos
• Assinar imagens de contêiner em fluxos de trabalho do GitHub usando Notação e Assinatura de Artefato

Este artigo orienta você, como consumidor de imagem, por meio do processo de verificação de assinaturas de imagem de contêiner usando o Ratify e o Azure Policy em clusters do AKS.

Visão geral da verificação de assinatura

Estas são as etapas de alto nível para verificação de assinatura:

1. Configurar controles de identidade e acesso para o Registro de Contêiner: configure a identidade que o Ratify usa para acessar o Registro de Contêiner com as funções necessárias.

2. Configurar controles de identidade e acesso para o Key Vault: configure a identidade que o Ratify usa para acessar o Key Vault com as funções necessárias. Ignore esta etapa se as imagens forem assinadas via Assinatura de Artifacto.

3. Configure o Ratify no cluster do seu AKS: configure o Ratify usando a instalação do gráfico do Helm como um serviço padrão do Kubernetes.

4. Configurar uma política personalizada do Azure: criar e atribuir uma política personalizada do Azure com o efeito de política desejado: Deny ou Audit.

Depois de seguir estas etapas, você pode começar a implantar suas cargas de trabalho para observar os resultados:

• Com o efeito da política Deny, somente as imagens que passam pela verificação de assinatura são permitidas na implantação. Imagens não assinadas ou assinadas por identidades não confiáveis são negadas.
• Com o efeito da política Audit, as imagens podem ser implantadas, mas seu componente será marcado como não compatível para fins de auditoria.

Pré-requisitos

• Instale e configure a versão mais recente da CLI do Azure ou execute comandos no Azure Cloud Shell.
• Instale o Helm para a instalação do Ratify e instale kubectl para solução de problemas e verificação de status.
• Crie ou use um cluster do AKS habilitado com um emissor do OpenID Connect (OIDC) seguindo as etapas em Criar um provedor do OpenID Connect no Serviço de Kubernetes do Azure. Esse cluster do AKS é onde suas imagens de contêiner são implantadas, o Ratify está instalado e as políticas personalizadas do Azure são aplicadas.
• Conecte o Registro de Contêiner ao cluster do AKS (se ele ainda não estiver conectado) seguindo as etapas em Autenticar com o Registro de Contêiner do Azure do Serviço de Kubernetes do Azure. O Registro de Contêiner é onde suas imagens de contêiner são armazenadas para implantação no cluster do AKS.
• Habilite o complemento do Azure Policy. Para verificar se o complemento está instalado ou instalá-lo se ainda não estiver, siga as etapas no complemento do Azure Policy para AKS.

Configurar controles de identidade e acesso

Antes de instalar o Ratify no cluster do AKS, você precisa estabelecer os controles de identidade e acesso adequados. O Ratify requer acesso ao registro do contêiner para baixar imagens de contêiner e assinaturas. Quando você usa o Key Vault para gerenciamento de certificados, o Ratify também precisa de acesso para recuperar certificados para verificação de assinatura.

A configuração de identidade envolve:

• Criando uma identidade gerenciada atribuída pelo usuário ou usando uma existente.
• Configurando credenciais de identidade federadas para habilitar a autenticação de identidade de carga de trabalho.
• Concedendo atribuições de função apropriadas para acesso ao Registro de Contêiner.
• Configurando permissões de acesso do Key Vault, se você estiver usando o Key Vault para gerenciamento de certificados.

Criar ou usar uma identidade gerenciada atribuída pelo usuário

Se você ainda não tiver uma identidade gerenciada atribuída pelo usuário, consulte Criar uma identidade gerenciada atribuída pelo usuário para criar uma. O Ratify usa essa identidade para acessar recursos do Azure, como Registro de Contêiner e (quando aplicável) Key Vault para gerenciamento de certificados.

Criar uma credencial de identidade federada para sua identidade

Configure variáveis de ambiente usando o código a seguir. Atualize os valores das variáveis RATIFY_NAMESPACE e RATIFY_SA_NAME se você não estiver usando os valores padrão. Certifique-se de usar os mesmos valores na instalação do Helm chart do 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"

O comando a seguir cria uma credencial federada para sua identidade gerenciada. A credencial permite que a identidade gerenciada se autentique usando tokens emitidos por um emissor do OIDC, especificamente para a conta RATIFY_SA_NAME de serviço do Kubernetes no 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"

Configurar o acesso ao Registro de Contêiner

A função AcrPull é necessária para que sua identidade efetue o pull das assinaturas e de outros metadados nas imagens de contêiner. Use o seguinte código para atribuir a função:

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}

Configurar o acesso ao Key Vault

Ignore esta etapa se você usar a Assinatura de Artefato para o gerenciamento de certificados.

A função Key Vault Secrets User é necessária para que sua identidade busque a cadeia integral dos certificados do seu cofre de chaves. Use o seguinte código para atribuir a função:

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

Configurar o Ratify no cluster do AKS com o Azure Policy habilitado

Com os controles de identidade e acesso configurados corretamente, agora você pode instalar o Ratify no cluster do AKS. O Ratify integra-se ao Azure Policy para impor políticas de verificação de assinatura. O processo de instalação envolve a implantação do Ratify usando gráficos do Helm com parâmetros de configuração específicos que definem como ele deve verificar assinaturas de imagem de contêiner.

As seções a seguir abrangem dois aspectos principais da configuração do Ratify:

• Noções básicas sobre os parâmetros do gráfico do Helm necessários para sua abordagem de gerenciamento de certificados (Key Vault ou Assinatura de Artefato)
• Instalando o Ratify com a configuração apropriada para habilitar a verificação de assinatura

Os parâmetros de configuração variam dependendo se você está usando o Key Vault ou a Assinatura de Artefato para gerenciamento de certificados. Siga as instruções que correspondem ao cenário escolhido.

Conheça seus parâmetros do gráfico do Helm

Ao instalar o gráfico do Helm para o Ratify, você precisa passar valores para parâmetros usando o --set sinalizador ou fornecendo um arquivo de valores personalizados. Esses valores são usados para configurar o Ratify para verificação de assinatura. Para obter uma lista abrangente de parâmetros, consulte a documentação do gráfico do Ratify Helm.

Instalar um gráfico do Helm do Ratify com os parâmetros e valores desejados

Certifique-se de que a versão do gráfico do Helm seja pelo menos 1.15.0, que instala o 1.4.0 ou posterior. O exemplo a seguir usa a versão 1.15.0do gráfico do Helm.

Configurar variáveis de ambiente adicionais para instalação:

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

Configurar uma política personalizada do Azure

Com o Ratify instalado e configurado com êxito no cluster do AKS, a etapa final é criar e atribuir uma política do Azure que imporá a verificação de assinatura durante implantações de contêiner. Essa política atua como o mecanismo de imposição que instrui o cluster a usar o Ratify para verificar assinaturas de imagem de contêiner antes de permitir implantações.

O Azure Policy oferece dois modos de imposição:

• Deny: bloqueia a implantação de imagens que falham na verificação de assinatura, de modo que somente imagens confiáveis são executadas em seu cluster.
• Audit: permite todas as implantações, mas marca os recursos em conformidade para fins de monitoramento e de relatório.

O Audit efeito é útil durante as fases iniciais de instalação ou teste. Você pode usá-la para validar sua configuração sem arriscar interrupções de serviço (devido a configurações incorretas) em ambientes de produção.

Atribuir uma nova política ao cluster do AKS

Crie uma política personalizada do Azure para verificação de assinatura:

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)

Por padrão, o efeito da política é definido como Deny. Com essa política em vigor, as imagens que não passarem na verificação de assinatura terão sua implantação negada.

Como alternativa, você pode definir o efeito da política como Audit. Esse efeito da política permite que as imagens que falham na verificação de assinatura sejam implantadas, enquanto marca o cluster AKS e as cargas de trabalho relacionadas como em conformidade.

Atribua a política ao cluster do AKS com o efeito padrão de 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"

Para alterar o efeito da política para Audit, você pode passar outro parâmetro para o comando az policy assignment create. Por exemplo:

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

Use o seguinte comando para verificar o status da política personalizada:

kubectl get constraintTemplate ratifyverification

Aqui está um exemplo da saída de uma atribuição de política bem-sucedida:

NAME                 AGE
ratifyverification   11m

Para fazer uma alteração em uma atribuição existente, você precisa excluir a atribuição existente primeiro, fazer alterações e, finalmente, criar uma nova atribuição.

Implante suas imagens e verifique os efeitos das políticas

Agora que você configurou o Ratify com êxito e atribuiu a política do Azure ao cluster do AKS, é hora de testar a funcionalidade de verificação de assinatura. As seções a seguir demonstram como a imposição da política funciona na prática implantando diferentes tipos de imagens de contêiner e observando os resultados.

Você testa três cenários para validar sua configuração:

• Imagens assinadas com certificados confiáveis: devem ser implantadas com êxito.
• Imagens não atribuídas: devem ser bloqueadas (com o Deny efeito) ou marcadas como compatíveis (com o Audit efeito).
• Imagens assinadas com certificados não confiáveis: devem ser bloqueadas (com o Deny efeito) ou marcadas como compatíveis (com o Audit efeito).

O comportamento observado depende do efeito de política que você escolheu quando atribuiu uma política do Azure. Esse processo de teste ajuda a garantir que sua verificação de assinatura esteja funcionando corretamente e fornece confiança de que apenas imagens confiáveis são permitidas em seu ambiente de produção.

Usar o efeito da política de negação

Com o efeito da política Deny, somente imagens assinadas com identidades confiáveis são permitidas para implantação. Comece a implantar suas cargas de trabalho para observar os efeitos. Este artigo descreve como usar o kubectl comando para implantar um pod. Da mesma forma, você pode implantar suas cargas de trabalho usando um gráfico Helm ou qualquer modelo que acione a instalação do Helm.

Configurar variáveis de ambiente:

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

Execute o comando a seguir. Como $IMAGE_SIGNED faz referência a uma imagem assinada por uma identidade confiável e configurada no Ratify, ela é permitida para implantação.

kubectl run demo-signed --image=$IMAGE_SIGNED

Aqui está um exemplo da saída para uma implantação bem-sucedida:

pod/demo-signed created

A $IMAGE_UNSIGNED variável faz referência a uma imagem que não está assinada. A $IMAGE_SIGNED_UNTRUSTED variável faz referência a uma imagem assinada por meio de um certificado diferente em que você não confia. Portanto, essas duas imagens são recusadas para implementação. Por exemplo, execute o seguinte comando:

kubectl run demo-unsigned --image=$IMAGE_UNSIGNED

Aqui está um exemplo da saída para uma implantação negada:

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

Você pode usar o comando a seguir para exibir logs do Ratify. Em seguida, você pode pesquisar os logs usando o texto verification response for subject $IMAGE_UNSIGNED. Verifique o errorReason campo para entender o motivo de qualquer implantação negada.

kubectl logs <ratify-pod> -n $RATIFY_NAMESPACE

Utilize a ação da política de auditoria

Com o efeito da política Audit, imagens não assinadas ou imagens assinadas com identidades não confiáveis são permitidas na implantação. No entanto, o cluster do AKS e os componentes relacionados são marcados como noncompliant. Para obter mais informações sobre como exibir recursos não compatíveis e entender os motivos, consulte Obter dados de conformidade dos recursos do Azure.

Limpeza

Use os comandos a seguir para desinstalar o Ratify e limpar as CRDs (definições de recursos personalizados do 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

Exclua a atribuição e a definição da política usando os seguintes comandos:

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

perguntas frequentes

Como posso configurar certificados para verificação de assinatura se não tiver acesso ao Key Vault?

Em alguns casos, os consumidores de imagem podem não ter acesso aos certificados usados para verificação de assinatura. Para verificar as assinaturas, você precisa baixar o arquivo do certificado AC raiz no formato PEM e especificar os parâmetros relacionados à instalação do gráfico Helm do Ratify.

O comando de exemplo a seguir é semelhante ao comando de instalação anterior, mas sem parâmetros relacionados aos certificados do Key Vault. O repositório de confiança do Notary Project refere-se ao arquivo de certificado que foi fornecido no parâmetro 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"

Como notationCerts[0] é usado para o certificado de AC raiz, caso você possua um arquivo de certificado adicional para fins de timestamp, assegure-se de usar o índice correto. Por exemplo, se notationCerts[1] for usado para o arquivo de certificado raiz DA TSA, use o repositório notation.trustPolicies[0].trustStores[1]" de confiança com o valor "tsa:notationCerts[1]".

Quais etapas devo tomar se o Azure Policy estiver desabilitado no cluster do AKS?

Se o Azure Policy estiver desabilitado no cluster do AKS, você deverá instalar o OPA Gatekeeper como o controlador de política antes de instalar o 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

Em seguida, instale o Ratify conforme descrito nas etapas anteriores. Após a instalação, imponha políticas usando os comandos a seguir. Por padrão, o efeito da política é definido como Deny. Você pode consultar a Documentação de violações do Gatekeeper para atualizar o arquivo constraint.yaml para diferentes efeitos de política.

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

Como posso atualizar as configurações do Ratify após a instalação do Ratify?

As configurações do Ratify são recursos personalizados do Kubernetes. Você pode atualizar esses recursos sem reinstalar o Ratify:

• Para atualizar as configurações relacionadas ao Key Vault, utilize o recurso personalizado Ratify KeyManagementProvider especificando o tipo azurekeyvault. Para atualizar configurações relacionadas à Assinatura de Artefato, use o recurso personalizado Ratify KeyManagementProvider com o tipo inline. Siga a documentação.
• Para atualizar as políticas de confiança e armazenamentos do Notary Project, use o recurso personalizado Ratify Verifier. Siga a documentação.
• Para autenticar e interagir com o Registro de Contêiner (ou outros registros compatíveis com OCI), use o recurso personalizado do Ratify Store. Siga a documentação.

O que devo fazer se minhas imagens de contêiner não forem assinadas por meio da ferramenta Notação?

Este artigo é aplicável para verificar assinaturas do Notary Project de forma independente em qualquer ferramenta que possa produzir assinaturas compatíveis com o Notary Project. O Ratify também dá suporte à verificação de outros tipos de assinaturas. Para obter mais informações, consulte o guia do usuário do Ratify.