Usar a verificação de assinatura do Sigstore

Nesta página, mostramos como usar a Verificação de assinatura do Sigstore de validação contínua (CV, na sigla em inglês) da autorização binária. A verificação confere as assinaturas de imagens de contêiner geradas pelo Sigstore associado a pods executados em clusters do GKE em que CV ativado. A principal diferença entre essa verificação e a verificação de atestado de assinatura simples é que o fluxo de trabalho de assinatura do Sigstore não usa observações do Artifact Analysis para vincular assinaturas a imagens. Todas as assinaturas são armazenadas junto com a imagem que elas assinam.

Essa verificação só é compatível com repositórios do Artifact Registry.

Custos

Neste guia, usamos os seguintes serviços do Google Cloud:

  • Autorização binária, mas a CV está disponível gratuitamente durante o estágio de Visualização
  • GKE
  • Cloud Key Management Service
  • Artifact Registry

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços.

Antes de começar

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
  2. Install the Google Cloud CLI.
  3. To initialize the gcloud CLI, run the following command:

    gcloud init
  4. Create or select a Google Cloud project.

    • Create a Google Cloud project:

      gcloud projects create PROJECT_ID

      Replace PROJECT_ID with a name for the Google Cloud project you are creating.

    • Select the Google Cloud project that you created:

      gcloud config set project PROJECT_ID

      Replace PROJECT_ID with your Google Cloud project name.

  5. Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

  6. Enable the Binary Authorization, Cloud Key Management Service, Google Kubernetes Engine, Artifact Registry APIs:

    gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com artifactregistry.googleapis.com
  7. Install the Google Cloud CLI.
  8. To initialize the gcloud CLI, run the following command:

    gcloud init
  9. Create or select a Google Cloud project.

    • Create a Google Cloud project:

      gcloud projects create PROJECT_ID

      Replace PROJECT_ID with a name for the Google Cloud project you are creating.

    • Select the Google Cloud project that you created:

      gcloud config set project PROJECT_ID

      Replace PROJECT_ID with your Google Cloud project name.

  10. Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

  11. Enable the Binary Authorization, Cloud Key Management Service, Google Kubernetes Engine, Artifact Registry APIs:

    gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com artifactregistry.googleapis.com
  12. Verifique se a CLI gcloud está atualizada para a versão mais recente.
  13. Instale a ferramenta de linha de comando kubectl.
  14. Se as políticas de autorização binária e os clusters do GKE estiverem em projetos diferentes, verifique se a autorização binária está ativada nos dois projetos.
  15. Instale a ferramenta de linha de comando cosign.

Funções exigidas

Esta seção mostra como definir papéis para essa verificação.

Visão geral

Se você executar todos os produtos mencionados neste guia no mesmo projeto, não será necessário definir permissões. A autorização binária configura os papéis corretamente quando ativada. Se você executar os produtos em projetos diferentes, será necessário definir os papéis conforme descrito nesta seção.

Para garantir que o agente de serviço de autorização binária em cada projeto tenha as permissões necessárias para avaliar a verificação de atualização da CV, peça ao administrador para conceder ao agente de serviço de autorização binária os seguintes papéis do IAM:

  • Se o projeto de cluster for diferente do projeto de política: Avaliador de políticas de autorização binária (roles/binaryauthorization.policyEvaluator) no projeto de cluster do Agente de serviço de autorização binária
  • Se o projeto do repositório de imagens for diferente do projeto de política: Leitor do Artifact Registry (roles/artifactregistry.reader) no projeto de política Agente de serviço de autorização binária

Para mais informações sobre como conceder papéis, consulte Gerenciar acesso.

O administrador também pode conceder as permissões necessárias ao agente de serviço de autorização binária em cada projeto por meio de papéis personalizados ou outros papéis predefinidos.

Conceder papéis usando a CLI gcloud

Para garantir que o agente de serviço de autorização binária em cada projeto tenha as permissões necessárias para avaliar a verificação de atestado de assinatura simples da CV, conceda ao agente de serviço de autorização binária os seguintes papéis de IAM:

  1. Conceda permissão ao Agente de serviço de autorização binária do projeto de cluster para acessar a política no projeto de política.

    1. Consiga o agente de serviço de autorização binária do projeto de cluster:

      PROJECT_NUMBER=$(gcloud projects list --filter="projectId:CLUSTER_PROJECT_ID" \
        --format="value(PROJECT_NUMBER)")
      CLUSTER_SERVICE_ACCOUNT="service-$PROJECT_NUMBER@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
      

      Substitua CLUSTER_PROJECT_ID pelo ID do projeto do cluster.

    2. Permita que a CV avalie a política no cluster:

      gcloud projects add-iam-policy-binding POLICY_PROJECT_ID \
          --member="serviceAccount:$CLUSTER_SERVICE_ACCOUNT" \
          --role='roles/binaryauthorization.policyEvaluator'
      

      Substitua POLICY_PROJECT_ID pelo ID do projeto que contém a política.

  2. Permita que o Agente de serviço de autorização binária do projeto de política acesse as assinaturas no seu repositório:

    1. Consiga o agente de serviço de autorização binária do projeto de política:

      PROJECT_NUMBER=$(gcloud projects list \
        --filter="projectId:POLICY_PROJECT_ID" \
        --format="value(PROJECT_NUMBER)")
      SERVICE_ACCOUNT="service-$PROJECT_NUMBER@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
      

      Substitua POLICY_PROJECT_ID pelo ID do projeto que contém a política.

    2. Conceda o papel:

      gcloud projects add-iam-policy-binding REPOSITORY_PROJECT_ID \
          --member="serviceAccount:$SERVICE_ACCOUNT" \
          --role='roles/artifactregistry.reader'
      

      Substitua REPOSITORY_PROJECT_ID pelo ID do projeto que contém seus atetados.

Criar um par de chaves.

Nesta seção, você cria um par de chaves assimétricas do Algoritmo de assinatura digital de curva elíptica (ECDSA, na sigla em inglês).

Você usa a chave privada para assinar a imagem, o que cria o atestado. Inclua a chave pública na política da plataforma. Quando a CV verifica o atestado, ela usa a chave pública para verificá-lo.

É possível usar o Cloud Key Management Service ou chaves locais, mas recomendamos o uso de chaves do Cloud KMS para produção.

Cosign do Cloud KMS PKIX

  1. Configure as variáveis de ambiente necessárias para criar o par de chaves. Para isso, preencha os marcadores no comando a seguir e execute-o.

    KMS_KEY_PROJECT_ID=KMS_KEY_PROJECT_ID
    KMS_KEYRING_NAME=KMS_KEYRING_NAME
    KMS_KEY_NAME=KMS_KEY_NAME
    KMS_KEY_LOCATION=global
    KMS_KEY_PURPOSE=asymmetric-signing
    KMS_KEY_ALGORITHM=ec-sign-p256-sha256
    KMS_PROTECTION_LEVEL=software
    KMS_KEY_VERSION=1
    

    Substitua:

    • KMS_KEY_PROJECT_ID: ID do projeto;
    • KMS_KEYRING_NAME: um nome para o keyring do Cloud KMS
    • KMS_KEY_NAME: um nome para a chave do Cloud KMS
  2. Gere a chave com a CLI do Cosign:

    cosign generate-key-pair \
      --kms gcpkms://projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME}
    
  3. Registre o local da chave pública:

    O Cosign salva automaticamente a chave pública gerada como cosign.pub no diretório em que o comando generate-key-pair foi executado. Salve o local desse arquivo em uma variável para comandos futuros.

    PUBLIC_KEY_FILE="$(pwd)/cosign.pub"
    

PKIX do Cloud KMS gcloud

Para criar o par de chaves no Cloud KMS, faça o seguinte:

  1. Configure as variáveis de ambiente necessárias para criar o par de chaves. Para isso, preencha os marcadores no comando a seguir e execute-o.

    KMS_KEY_PROJECT_ID=KMS_KEY_PROJECT_ID
    KMS_KEYRING_NAME=KMS_KEYRING_NAME
    KMS_KEY_NAME=KMS_KEY_NAME
    KMS_KEY_LOCATION=global
    KMS_KEY_PURPOSE=asymmetric-signing
    KMS_KEY_ALGORITHM=ec-sign-p256-sha256
    KMS_PROTECTION_LEVEL=software
    KMS_KEY_VERSION=1
    

    Substitua:

    • KMS_KEY_PROJECT_ID: ID do projeto;
    • KMS_KEYRING_NAME: um nome para o keyring do Cloud KMS
    • KMS_KEY_NAME: um nome para a chave do Cloud KMS
  2. Crie o keyring:

    gcloud kms keyrings create ${KMS_KEYRING_NAME} \
        --location=${KMS_KEY_LOCATION} \
        --project=${KMS_KEY_PROJECT_ID}
    
  3. Crie a chave:

    gcloud kms keys create ${KMS_KEY_NAME} \
        --location=${KMS_KEY_LOCATION} \
        --keyring=${KMS_KEYRING_NAME}  \
        --purpose=${KMS_KEY_PURPOSE} \
        --default-algorithm=${KMS_KEY_ALGORITHM} \
        --protection-level=${KMS_PROTECTION_LEVEL} \
        --project=${KMS_KEY_PROJECT_ID}
    
  4. Exporte o material da chave pública para um arquivo:

    PUBLIC_KEY_FILE="$(pwd)/cosign.pub"
    gcloud kms keys versions get-public-key 1 \
        --key=${KMS_KEY_NAME} \
        --keyring=${KMS_KEYRING_NAME} \
        --location=${KMS_KEY_LOCATION} \
        --output-file=${PUBLIC_KEY_FILE} \
        --project=${KMS_KEY_PROJECT_ID}
    

Chave local

Para criar o par de chaves localmente, faça o seguinte:

  cosign generate-key-pair
  PUBLIC_KEY_FILE="$(pwd)/cosign.pub"
  PRIVATE_KEY_FILE="$(pwd)/cosign.key"

Criar a política da plataforma

Para criar a política de CV da plataforma com uma verificação de assinatura do Sigstore, faça o seguinte:

  1. Crie o arquivo de política da plataforma de verificação de assinatura do Sigstore:

    cat > POLICY_PATH <<EOF
    gkePolicy:
      checkSets:
      - checks:
        - displayName: sigstore-signature-check
          sigstoreSignatureCheck:
            sigstoreAuthorities:
            - displayName: sigstore-authority
              publicKeySet:
                publicKeys:
                  publicKeyPem: |
    $(awk '{printf "                %s\n", $0}' ${PUBLIC_KEY_FILE})
    EOF
    

    Substitua POLICY_PATH pelo caminho para o arquivo de política.

  2. Crie a política da plataforma:

    Antes de usar os dados do comando abaixo, faça estas substituições:

    • POLICY_ID: um ID de política de plataforma de sua escolha Se a política estiver em outro projeto, use o nome completo do recurso: projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID.
    • POLICY_PATH: um caminho para o arquivo de política.
    • POLICY_PROJECT_ID: o ID do projeto de política.

    Execute o seguinte comando:

    Linux, macOS ou Cloud Shell

    gcloud beta container binauthz policy create POLICY_ID \
        --platform=gke \
        --policy-file=POLICY_PATH \
        --project=POLICY_PROJECT_ID
    

    Windows (PowerShell)

    gcloud beta container binauthz policy create POLICY_ID `
        --platform=gke `
        --policy-file=POLICY_PATH `
        --project=POLICY_PROJECT_ID
    

    Windows (cmd.exe)

    gcloud beta container binauthz policy create POLICY_ID ^
        --platform=gke ^
        --policy-file=POLICY_PATH ^
        --project=POLICY_PROJECT_ID
    

Ativar a CV

É possível criar um novo cluster ou atualizar um cluster para usar o monitoramento de CV com políticas de plataforma com base em verificação.

Criar um cluster que use o monitoramento de CV

Nesta seção, você cria um cluster que usa apenas o monitoramento de CV com políticas de plataforma com base em verificação.

Antes de usar os dados do comando abaixo, faça estas substituições:

  • CLUSTER_NAME: um nome de cluster.
  • LOCATION: o local, por exemplo, us-central1 ou asia-south1.
  • POLICY_PROJECT_ID: o ID do projeto em que a política está armazenada.
  • POLICY_ID: o ID da política.
  • CLUSTER_PROJECT_ID: o ID do projeto do cluster.

Execute o seguinte comando:

Linux, macOS ou Cloud Shell

gcloud beta container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

Windows (PowerShell)

gcloud beta container clusters create CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows (cmd.exe)

gcloud beta container clusters create CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

Criar um cluster que use aplicação e monitoramento de CV

Nesta seção, você cria um cluster que usa a aplicação de política project-singleton e o monitoramento de CV com políticas de plataforma com base em verificação:

Antes de usar os dados do comando abaixo, faça estas substituições:

  • CLUSTER_NAME: um nome de cluster.
  • LOCATION: o local, por exemplo, us-central1 ou asia-south1.
  • POLICY_PROJECT_ID: o ID do projeto em que a política está armazenada.
  • POLICY_ID: o ID da política.
  • CLUSTER_PROJECT_ID: o ID do projeto do cluster.

Execute o seguinte comando:

Linux, macOS ou Cloud Shell

gcloud beta container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

Windows (PowerShell)

gcloud beta container clusters create CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows (cmd.exe)

gcloud beta container clusters create CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

Atualizar um cluster para usar o monitoramento de CV

Nesta seção, você atualiza um cluster para usar o monitoramento de CV somente com políticas de plataforma com base em verificação. Se o cluster já tiver a aplicação da política de projeto singleton ativada, a execução desse comando a desativará. Em vez disso, atualize o cluster com a aplicação e o monitoramento de CV ativados.

Antes de usar os dados do comando abaixo, faça estas substituições:

  • CLUSTER_NAME: o nome do cluster
  • LOCATION: o local, por exemplo: us-central1 ou asia-south1
  • POLICY_PROJECT_ID: o ID do projeto em que a política está armazenada
  • POLICY_ID: o ID da política
  • CLUSTER_PROJECT_ID: o ID do projeto do cluster

Execute o seguinte comando:

Linux, macOS ou Cloud Shell

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

Windows (PowerShell)

gcloud beta container clusters update CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows (cmd.exe)

gcloud beta container clusters update CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

Atualizar um cluster para usar a aplicação e o monitoramento de CV

Nesta seção, você atualiza um cluster para usar a aplicação da política de projeto singleton e o monitoramento de CV com políticas de plataforma com base em verificação.

Antes de usar os dados do comando abaixo, faça estas substituições:

  • CLUSTER_NAME: um nome de cluster
  • LOCATION: o local, por exemplo: us-central1 ou asia-south1
  • POLICY_PROJECT_ID: o ID do projeto em que a política está armazenada
  • POLICY_ID: o ID da política
  • CLUSTER_PROJECT_ID: o ID do projeto do cluster

Execute o seguinte comando:

Linux, macOS ou Cloud Shell

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

Windows (PowerShell)

gcloud beta container clusters update CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows (cmd.exe)

gcloud beta container clusters update CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

Testar CV

Nesta seção, você vai testar o CV implantando uma imagem assinada. Nesse caso, a verificação de assinatura do CV Sigstore confere a assinatura e não produz entrada de registro.

Em seguida, você tenta implantar outra imagem não assinada. Nesse caso, a verificação de CV não consegue encontrar uma assinatura válida e registra a violação no Cloud Logging.

Assinar uma imagem

Para satisfazer a verificação, a imagem precisa de um atestado válido. Para criar a assinatura, faça o seguinte:

  1. Crie as variáveis usadas para assinar a imagem:

    IMAGE_PATH=IMAGE_PATH
    IMAGE_DIGEST=sha256:IMAGE_DIGEST_SHA
    IMAGE_TO_SIGN="${IMAGE_PATH}@${IMAGE_DIGEST}"
    

    Substitua:

    • IMAGE_PATH: o caminho para a imagem.
    • IMAGE_DIGEST_SHA: o hash SHA do resumo da sua imagem
  2. Assine a imagem e envie a assinatura por push para o Artifact Registry:

    PKIX (Cloud KMS)

    Assine a imagem com uma chave hospedada no Cloud KMS e envie a assinatura para o Artifact Registry:

    cosign sign \
        --key gcpkms://projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME} \
        ${IMAGE_TO_SIGN}
    

    Chave local

    Assine a imagem com uma chave privada local e envie a assinatura por push para o Artifact Registry.

    cosign sign --key ${PRIVATE_KEY_FILE} ${IMAGE_TO_SIGN}
    
  3. Responda à solicitação do Cosign:

    Depois de executar o comando cosign sign, o Cosign pergunta se você quer fazer upload da assinatura para o registro de transparência Rekor. Responda y ou n às solicitações. Para saber mais, consulte a documentação do Rekor (link em inglês).

Verificar a assinatura manualmente

Para verificar a assinatura manualmente, faça o seguinte:

  1. Verifique se a assinatura existe no Artifact Registry:

    Console do Google Cloud

    1. Acesse a página do Artifact Registry no console do Google Cloud.

      Acessar o Artifact Registry

    2. Na lista de repositórios, clique no nome do repositório que contém a imagem.

    3. Clique no nome da imagem que você assinou.

    4. Localize o item que contém a assinatura. Este item tem a tag: sha256-[image digest].sig. Deve haver apenas um item com a tag.

    5. Clique em Manifesto.

    6. Vai aparecer um arquivo no formato JSON com vários campos. Cada assinatura fica em um elemento da lista layers, no mapa annotations. As assinaturas estão localizadas na chave dev.cosignproject.cosign/signature.

      Confira a seguir um exemplo de manifesto:

      {
            "schemaVersion": 2,
            "mediaType": "application/vnd.oci.image.manifest.v1+json",
            "config": {
                "mediaType": "application/vnd.oci.image.config.v1+json",
                "size": SIZE_OF_LAYERS,
                "digest": "DIGEST_OF_LAYERS"
            },
            "layers": [
                {
                    "mediaType": "application/vnd.dev.cosign.simplesigning.v1+json",
                    "size": SIZE_OF_ANNOTATIONS,
                    "digest": "DIGEST_OF_ANNOTATIONS",
                    "annotations": {
                        "dev.cosignproject.cosign/signature": "BASE64_SIGNATURE",
                        "dev.sigstore.cosign/bundle": "BUNDLE"
                    }
                }
            ]
      }
    

    O manifesto de exemplo inclui o seguinte:

    • SIZE_OF_LAYERS: tamanho da matriz layers em bytes
    • DIGEST_OF_LAYERS: o resumo da matriz layers.
    • SIZE_OF_ANNOTATIONS: tamanho do dicionário annotations em bytes.
    • DIGEST_OF_ANNOTATIONS: resumo do dicionário annotations
    • BASE64_SIGNATURE: a assinatura bruta de codificada no formato base64. Esta é a assinatura que será usada para verificação
    • BUNDLE: metadados específicos do Sigstore

    Mais detalhes sobre o formato do manifesto podem ser encontrados na especificação de assinatura de assinatura do Sigstore.

    Linha de comando

    1. Encontre o artefato correto:

      Liste os itens armazenados com a imagem:

      gcloud artifacts docker tags list ${IMAGE_PATH}
      

      Veja abaixo um exemplo de saída:

      Listing items under project PROJECT_ID, location REPOSITORY_LOCATION, repository REPOSITORY_NAME.
      TAG                         IMAGE                                                         DIGEST
      latest                      us-east1-docker.pkg.dev/my-project/my-repo/my-image           sha256:abc123
      sha256-abc123.sig           us-east1-docker.pkg.dev/my-project/my-repo/my-image           sha256:def456
      

      Na saída, o artefato com a tag sha256-abc123.sig contém a assinatura no manifesto.

    2. Acessar o manifesto

      Para acessar o manifesto do artefato com a tag sha256-IMAGE_DIGEST_SHA.sig, execute o seguinte comando:

      curl -X GET -H "Content-Type: application/json" \
                  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
                  -H "X-Goog-User-Project: REPOSITORY_PROJECT_ID" \
                  "https://REPOSITORY_LOCATION-docker.pkg.dev/v2/REPOSITORY_PROJECT_ID/REPOSITORY_NAME/IMAGE_NAME/manifests/sha256-IMAGE_DIGEST_SHA.sig"
      

      Substitua:

      • REPOSITORY_PROJECT_ID: o ID do projeto que contém a instância.
      • REPOSITORY_LOCATION: o local do repositório.
      • REPOSITORY_NAME: o nome do repositório.
      • IMAGE_NAME: o nome da imagem.

      Vai aparecer um arquivo no formato JSON com vários campos. Cada assinatura fica em um elemento da lista layers, no mapa annotations. As assinaturas estão localizadas na chave dev.cosignproject.cosign/signature.

      Confira um exemplo de manifesto:

      {
          "schemaVersion": 2,
          "mediaType": "application/vnd.oci.image.manifest.v1+json",
          "config": {
              "mediaType": "application/vnd.oci.image.config.v1+json",
              "size": SIZE_OF_LAYERS,
              "digest": "DIGEST_OF_LAYERS"
          },
          "layers": [
              {
                  "mediaType": "application/vnd.dev.cosign.simplesigning.v1+json",
                  "size": SIZE_OF_ANNOTATIONS,
                  "digest": "DIGEST_OF_ANNOTATIONS",
                  "annotations": {
                      "dev.cosignproject.cosign/signature": "BASE64_SIGNATURE",
                      "dev.sigstore.cosign/bundle": "BUNDLE"
                  }
              }
          ]
      }
      

    O manifesto de exemplo inclui o seguinte:

    • SIZE_OF_LAYERS: tamanho da matriz layers em bytes
    • DIGEST_OF_LAYERS: o resumo da matriz layers.
    • SIZE_OF_ANNOTATIONS: tamanho do dicionário annotations em bytes.
    • DIGEST_OF_ANNOTATIONS: resumo do dicionário annotations
    • BASE64_SIGNATURE: a assinatura bruta de codificada no formato base64. Esta é a assinatura que será usada para verificação
    • BUNDLE: metadados específicos do Sigstore

    Mais detalhes sobre o formato do manifesto podem ser encontrados na especificação de assinatura de assinatura do Sigstore.

  2. Verifique a assinatura manualmente:

    Use cosign verify para verificar a assinatura enviada:

    PKIX (Cloud KMS)

    cosign verify --key gcpkms://projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME} \
          ${IMAGE_PATH}@${IMAGE_DIGEST}
    

    Chave local

    cosign verify --key {PUBLIC_KEY_FILE} ${IMAGE_PATH}@${IMAGE_DIGEST}
    

    A resposta ao comando vai informar The signatures were verified against the specified public key se a verificação for bem-sucedida.

Implantar a imagem assinada

Para implantar uma imagem assinada, faça o seguinte:

  1. Configurar kubectl:

    gcloud container clusters get-credentials CLUSTER_NAME \
        --location=LOCATION \
        --project=CLUSTER_PROJECT_ID
    

    Substitua:

    • CLUSTER_NAME: o nome do cluster.
    • LOCATION: o local do cluster
    • CLUSTER_PROJECT_ID: o ID do projeto do cluster
  2. Implante uma imagem e verifique a implantação em relação à política de autorização binária:

    kubectl run hello-app-signed --image=${IMAGE_PATH}@${IMAGE_DIGEST}
    

    O pod foi implantado. Como a imagem é assinada, o CV não produz entradas de registro relacionadas a esse pod.

Implantar uma imagem não assinada

Nesta seção, você vai implantar uma imagem não assinada.

Como a política requer atestados e essa imagem não tem um, a CV registra a violação regularmente enquanto o contêiner está em execução.

Para implantar a imagem, execute o seguinte comando:

  kubectl run hello-app-unsigned \
      --image=UNSIGNED_IMAGE_PATH@UNSIGNED_IMAGE_DIGEST

O pod foi implantado. Como a imagem não tem um atestado, a CV produz entradas de registro enquanto o pod está em execução.

Ver registros das entradas de CV

É possível pesquisar entradas do Cloud Logging para encontrar erros de configuração de CV e violações de validação da política da plataforma de CV.

A CV registra erros e violações no Cloud Logging em 24 horas. Geralmente, as entradas aparecem em algumas horas.

Acessar registros de erros de configuração do CV

Para ver os registros de erros de configuração do CV, execute o seguinte comando:

gcloud logging read \
     --order="desc" \
     --freshness=7d \
     --project=CLUSTER_PROJECT_ID \
    'logName:"binaryauthorization.googleapis.com%2Fcontinuous_validation" "configErrorEvent"'

A saída a seguir mostra um erro de configuração em que uma política de CV da plataforma não foi encontrada:

{
  "insertId": "141d4f10-72ea-4a43-b3ec-a03da623de42",
  "jsonPayload": {
    "@type": "type.googleapis.com/google.cloud.binaryauthorization.v1beta1.ContinuousValidationEvent",
    "configErrorEvent": {
      "description": "Cannot monitor cluster 'us-central1-c.my-cluster': Resource projects/123456789/platforms/gke/policies/my-policy does not exist."
    }
  },
  "resource": {
    "type": "k8s_cluster",
    "labels": {
      "cluster_name": "my-cluster",
      "location": "us-central1-c",
      "project_id": "my-project"
    }
  },
  "timestamp": "2024-05-28T15:31:03.999566Z",
  "severity": "WARNING",
  "logName": "projects/my-project/logs/binaryauthorization.googleapis.com%2Fcontinuous_validation",
  "receiveTimestamp": "2024-05-28T16:30:56.304108670Z"
}

Conferir violações de validação da política da plataforma de CVs

Se nenhuma imagem violar as políticas de plataforma que você ativou, nenhuma entrada aparecerá nos registros.

Para ver as entradas de registro da CV dos últimos sete dias, execute o seguinte comando:

gcloud logging read \
     --order="desc" \
     --freshness=7d \
     --project=CLUSTER_PROJECT_ID \
    'logName:"binaryauthorization.googleapis.com%2Fcontinuous_validation" "policyName"'

Substitua CLUSTER_PROJECT_ID pelo ID do projeto de cluster.

Tipos de verificação

Os registros da CV verificam as informações de violação para checkResults. Na entrada, o valor checkType indica a verificação. Os valores para cada verificação são os seguintes:

  • ImageFreshnessCheck
  • SigstoreSignatureCheck
  • SimpleSigningAttestationCheck
  • SlsaCheck
  • TrustedDirectoryCheck
  • VulnerabilityCheck

Exemplo de registro

A entrada de registro da CV de exemplo a seguir descreve uma imagem não compatível que viola a verificação de diretório confiável:

{
  "insertId": "637c2de7-0000-2b64-b671-24058876bb74",
  "jsonPayload": {
    "podEvent": {
      "endTime": "2022-11-22T01:14:30.430151Z",
      "policyName": "projects/123456789/platforms/gke/policies/my-policy",
      "images": [
        {
          "result": "DENY",
          "checkResults": [
            {
              "explanation": "TrustedDirectoryCheck at index 0 with display name \"My trusted directory check\" has verdict NOT_CONFORMANT. Image is not in a trusted directory",
              "checkSetName": "My check set",
              "checkSetIndex": "0",
              "checkName": "My trusted directory check",
              "verdict": "NON_CONFORMANT",
              "checkType": "TrustedDirectoryCheck",
              "checkIndex": "0"
            }
          ],
          "image": "gcr.io/my-project/hello-app:latest"
        }
      ],
      "verdict": "VIOLATES_POLICY",
      "podNamespace": "default",
      "deployTime": "2022-11-22T01:06:53Z",
      "pod": "hello-app"
    },
    "@type": "type.googleapis.com/google.cloud.binaryauthorization.v1beta1.ContinuousValidationEvent"
  },
  "resource": {
    "type": "k8s_cluster",
    "labels": {
      "project_id": "my-project",
      "location": "us-central1-a",
      "cluster_name": "my-test-cluster"
    }
  },
  "timestamp": "2022-11-22T01:44:28.729881832Z",
  "severity": "WARNING",
  "logName": "projects/my-project/logs/binaryauthorization.googleapis.com%2Fcontinuous_validation",
  "receiveTimestamp": "2022-11-22T03:35:47.171905337Z"
}

Limpar

Nesta seção, descrevemos como limpar o monitoramento de CV configurado anteriormente neste guia.

É possível desativar o monitoramento de CV ou a autorização binária e a CV no cluster.

Desativar a autorização binária em um cluster

Para desativar a aplicação do CV e da autorização binária no seu cluster, execute o seguinte comando:

gcloud beta container clusters update CLUSTER_NAME \
    --binauthz-evaluation-mode=DISABLED \
    --location=LOCATION \
    --project=CLUSTER_PROJECT_ID

Substitua:

  • CLUSTER_NAME: o nome do cluster.
  • LOCATION: o local do cluster
  • CLUSTER_PROJECT_ID: o ID do projeto do cluster

Desativar o monitoramento de políticas com base em verificações em um cluster

Para desativar o CV com políticas baseadas em verificação no cluster e reativar a aplicação usando a política de autorização binária, execute o seguinte comando:

gcloud beta container clusters update CLUSTER_NAME  \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
    --location=LOCATION \
    --project="CLUSTER_PROJECT_ID"

Substitua:

  • CLUSTER_NAME: o nome do cluster.
  • LOCATION: o local do cluster
  • CLUSTER_PROJECT_ID: o ID do projeto do cluster

Observe que --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE é equivalente à sinalização --enable-binauthz mais antiga.

Exclua a política:

Para excluir a política, execute o comando a seguir. Não é necessário excluir a política de plataforma com base em verificação para desativar esse tipo de auditoria.

gcloud beta container binauthz policy delete POLICY_ID \
    --platform=gke \
    --project="POLICY_PROJECT_ID"

Substitua:

  • POLICY_ID: o ID da política
  • POLICY_PROJECT_ID: o ID do projeto de política

A seguir