Usar a verificação da SLSA

Nesta página, mostramos como usar a Verificação SLSA da validação contínua (CV, na sigla em inglês) da autorização binária, que verifica a procedência compatível com SLSA das imagens de contêiner associadas a pods em execução nos clusters do GKE em que a CV está ativada.

Para usar essa verificação, você precisa criar imagens com o Cloud Build, que produz procedência compatível com SLSA.

O exemplo neste guia usa o Cloud Source Repositories para o repositório de código-fonte, o Artifact Registry para o registro de imagem e o Cloud Build para criar a imagem e produzir a procedência.

O único builder confiável compatível com a verificação da SLSA é o Cloud Build.

Custos

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

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

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. Make sure that billing is enabled for your Google Cloud project.

  6. Enable the Artifact Registry, Binary Authorization, Cloud Build, GKE, Cloud Source Repositories APIs: 

    gcloud services enable artifactregistry.googleapis.com binaryauthorization.googleapis.com cloudbuild.googleapis.com container.googleapis.com sourcerepo.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. Make sure that billing is enabled for your Google Cloud project.

  11. Enable the Artifact Registry, Binary Authorization, Cloud Build, GKE, Cloud Source Repositories APIs: 

    gcloud services enable artifactregistry.googleapis.com binaryauthorization.googleapis.com cloudbuild.googleapis.com container.googleapis.com sourcerepo.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.

Funções exigidas

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

Informações gerais

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 SLSA de CV, peça ao administrador para conceder ao agente de serviço de autorização binária os seguintes papéis do IAM:

  • Leitor do Artifact Registry (roles/artifactregistry.reader) na conta de serviço do Compute Engine do projeto de cluster
  • Se o projeto de cluster for diferente do projeto de política: Avaliador de política de autorização binária (roles/binaryauthorization.policyEvaluator) no Agente de serviço de autorização binária do projeto de cluster, para acessar o projeto de política
  • Se o projeto de atestado for diferente do projeto de política: Visualizador de ocorrências do Container Analysis (roles/containeranalysis.occurrences.viewer) no Agente de serviço de autorização binária do projeto de política, para acessar o projeto de atestado

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

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 as contas de serviço em cada projeto tenham as permissões necessárias para avaliar essa verificação, conceda às contas de serviço em cada projeto os seguintes papéis do IAM:

  1. Se o projeto em que você executa o cluster for diferente do projeto em que a política está localizada, será necessário conceder permissão para que o agente de serviço da autorização binária do projeto de cluster acesse 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 do projeto de política acesse os atestados:

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

      PROJECT_NUMBER=$(gcloud projects list \
  --filter="projectId:POLICY_PROJECT_ID" \
  --format="value(PROJECT_NUMBER)")
POLICY_PROJECT_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 ATTESTATION_PROJECT_ID \
    --member="serviceAccount:$POLICY_PROJECT_SERVICE_ACCOUNT" \
    --role='roles/containeranalysis.occurrences.viewer'

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

  3. Permita que a permissão padrão da conta de serviço do Compute Engine extraia a imagem do repositório:

    1. Consiga a conta de serviço do Compute Engine associada ao projeto do cluster:

      PROJECT_NUMBER=$(gcloud projects list \
  --filter="projectId:CLUSTER_PROJECT_ID" \
  --format="value(PROJECT_NUMBER)")
COMPUTE_ENGINE_SERVICE_ACCOUNT="$PROJECT_NUMBER-compute@developer.gserviceaccount.com"

      Substitua CLUSTER_PROJECT_ID pelo ID do projeto de cluster que contém a política.

    2. Conceda o papel:

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

      Substitua ARTIFACT_PROJECT_ID pelo ID do projeto do Artifact Registry que armazena as imagens que serão implantadas.

Opcional: criar e fazer upload de uma imagem de amostra

Esta seção está incluída para fins ilustrativos, para mostrar como criar uma imagem de exemplo com procedência em conformidade com a SLSA. A procedência será usada posteriormente no guia para demonstrar a verificação. Saiba mais sobre a procedência do Cloud Build.

Criar o repositório de amostra

Para criar um repositório no Cloud Source Repositories, siga estas etapas:

  1. Crie o repositório e clone-o localmente:

    gcloud source repos create SOURCE_REPO_NAME \
    --project=SOURCE_REPO_PROJECT_ID && \
gcloud source repos clone SOURCE_REPO_NAME \
    --project=SOURCE_REPO_PROJECT_ID && \
cd SOURCE_REPO_NAME

    Substitua:

    • SOURCE_REPO_NAME: o nome do repositório do código-fonte, por exemplo: slsa-check-test-repo
    • SOURCE_REPO_PROJECT_ID: o ID do projeto do repositório

  2. Para criar os arquivos de origem, de configuração e de criação, faça o seguinte:

    1. Crie a origem da imagem:

      cat > quickstart.sh <<EOF
#!/bin/sh
echo "Hello, world! The time is $(date)."
sleep infinity
EOF

    2. Torne o arquivo executável:

      chmod +x quickstart.sh

    3. Crie o arquivo de configuração do Dockerfile:

      cat > Dockerfile <<EOF
FROM alpine
COPY quickstart.sh /
CMD ["/quickstart.sh"]
EOF

    4. Crie o arquivo cloudbuild.yaml do Cloud Build, que envia a imagem para o Artifact Registry:

      cat > cloudbuild.yaml <<EOF
steps:
- name: 'gcr.io/cloud-builders/docker'
  args: [ 'build', '-t', 'LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE', '.' ]
options:
  requestedVerifyOption: VERIFIED
images:
- 'LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE'
EOF

      Substitua:

      • LOCATION: o local do Artifact Registry, por exemplo: us-west2, europe-central2 ou asia-east1
      • ARTIFACT_PROJECT_ID: o ID do projeto que armazena os artefatos do Artifact Registry
      • ARTIFACT_REPO_NAME: o nome do repositório do Artifact Registry, por exemplo: slsa-check-test-repo
      • DIRECTORY: o diretório, por exemplo: slsa-check
      • IMAGE: o caminho para a imagem (por exemplo: slsa-check-image)

    5. Confirme os arquivos no Cloud Source Repositories:

      git add .
git commit -a

Criar e fazer upload da imagem de amostra

Para simplificar o uso deste guia, recomendamos que você use o mesmo projeto para SOURCE_REPO_PROJECT_ID e ARTIFACT_PROJECT_ID. Se você usa projetos diferentes, talvez seja necessário configurar outras permissões do IAM. Saiba mais sobre o controle de acesso do Container Registry Para saber mais sobre o Cloud Build, consulte Visão geral do Cloud Build.

Para criar o repositório, faça o seguinte:

  1. Criar o repositório do Artifact Registry:

    gcloud artifacts repositories create ARTIFACT_REPO_NAME \
    --project=ARTIFACT_PROJECT_ID \
    --repository-format=docker \
    --location=LOCATION \
    --description="Docker repository"

    Substitua:

    • ARTIFACT_REPO_NAME: o nome do seu repositório
    • ARTIFACT_PROJECT_ID: o ID do projeto do artefato
    • LOCATION: o local do Artifact Registry, por exemplo: us-west2, europe-central2 ou asia-east1

  2. Crie o gatilho de build do Cloud Build:

    gcloud beta builds triggers create cloud-source-repositories \
    --project=SOURCE_REPO_PROJECT_ID \
    --repo=SOURCE_REPO_NAME \
    --region=LOCATION \
    --branch-pattern=.* \
    --build-config=cloudbuild.yaml

    Substitua:

    • SOURCE_REPO_NAME: o nome do repositório do código-fonte
    • SOURCE_REPO_PROJECT_ID: o ID do projeto do Cloud Build
    • LOCATION: o local

  3. Para acionar uma versão, envie os arquivos criados anteriormente neste guia.

    git push

    Quando a imagem é criada com sucesso, o Cloud Build gera procedência e faz upload da imagem para o repositório do Artifact Registry.

  4. Para verificar a imagem mais recente e receber o resumo dela, faça o seguinte:

    1. Verifique se o Cloud Build criou a imagem:

      gcloud artifacts docker images list LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/REPO_NAME/DIRECTORY \
    --project=ARTIFACT_PROJECT_ID \
    --sort-by=create_time

      Substitua:

      • LOCATION: o local do Artifact Registry
      • ARTIFACT_PROJECT_ID: o ID do projeto para artefatos
      • ARTIFACT_REPO_NAME: o nome do repositório
      • DIRECTORY: o diretório

    2. Copie o resumo da imagem mais recente. A saída será assim: sha256:9432f747bd058b33de33bb5314d6eec1ac357d664e04c76824bb7072a9218d59

  5. Opcional: veja a procedência da sua imagem:

    gcloud artifacts docker images describe \
  LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE@DIGEST \
    --project=ARTIFACT_PROJECT_ID \
    --show-provenance

    Substitua:

    • ARTIFACT_PROJECT_ID: o ID do projeto para artefatos
    • LOCATION: o local do Artifact Registry
    • ARTIFACT_REPO_NAME: o nome do repositório de artefatos
    • DIRECTORY: o diretório
    • IMAGE: o caminho para a imagem
    • DIGEST: o resumo associado à imagem

    A resposta ao comando será assim:

    image_summary:
  digest: sha256:9432f747bd058b33de33bb5314d6eec1ac357d664e04c76824bb7072a9218d59
  fully_qualified_digest: us-west2-docker.pkg.dev/my-project/slsa-check-repo/slsa-check-image@sha256:9432f747bd058b33de33bb5314d6eec1ac357d664e04c76824bb7072a9218d59
  registry: us-west2-docker.pkg.dev
  repository: slsa-check-repo
  slsa_build_level: 3
provenance_summary:
  provenance:
  - build:
      intotoStatement:
        _type: https://in-toto.io/Statement/v0.1
        predicateType: https://slsa.dev/provenance/v0.1
        slsaProvenance:
          builder:
            id: https://cloudbuild.googleapis.com/GoogleHostedWorker
          materials:
          - digest:
              sha1: de4e4227fff1d00d6f7785a827608627e4a369ea
            uri: git+https://source.cloud.google.com/my-project/slsa-check-source-repo
          metadata:
            ...
envelope:
  payload: eyJfdHlwZSI6I ... taW1hZ2U6dGFnMSJ9XX0=
  payloadType: application/vnd.in-toto+json
  signatures:
  - keyid: projects/verified-builder/locations/global/keyRings/attestor/cryptoKeys/provenanceSigner/cryptoKeyVersions/1
    sig: MEQCIBCCkho_re4EfAT-NBSSmAXOZlv4lU_vWzEru97tU8KmAiAKcAa99umWngzNQADmPixqYjbKjLOKQEUvrI5chSrf7g==
  - keyid: projects/verified-builder/locations/global/keyRings/attestor/cryptoKeys/builtByGCB/cryptoKeyVersions/1
    sig: MEUCIFOEq_7RpiZAB4vUlit3hkZ2yI0n37-5Y87l0JbU-EZSAiEA9TNZZcv_MnzKffTnswHWZR2DSLmYiklr5twWfIec-zo=

    A saída precisa conter o bloco provenance_summary para que a verificação da SLSA funcione. Se a saída não contiver o bloco, verifique se o Cloud Build foi invocado por um gatilho de build. O Cloud Build não produz informações de procedência quando é acionado manualmente.

Criar uma política de plataforma

Para gerar procedência, é preciso usar um gatilho do Cloud Build para criar sua imagem, conforme descrito em Criar e fazer upload da imagem de amostra.

Para criar uma política da plataforma com uma verificação de SLSA, faça isto:

  1. Crie o arquivo YAML de política da plataforma:

    cat > POLICY_PATH <<EOF
gkePolicy:
  checkSets:
  - checks:
    - displayName: My SLSA check
      imageAllowlist:
        # This policy exempts images that are in the following artifact registry
        allowPattern:
        - ARTIFACT_LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/EXEMPT_IMAGE_PATH/**
      slsaCheck:
        rules:
        - attestationSource:
            containerAnalysisAttestationProjects:
            - projects/ATTESTATION_PROJECT_ID
          configBasedBuildRequired: true
          trustedBuilder: GOOGLE_CLOUD_BUILD
          trustedSourceRepoPatterns:
          - source.cloud.google.com/SOURCE_REPO_PROJECT_ID/SOURCE_REPO_NAME
          customConstraints:
          - CEL_EXPRESSION
    displayName: My check set
EOF

    Substitua:

    • POLICY_PATH: um caminho para o arquivo de política.
    • ARTIFACT_LOCATION: o local do repositório no Artifact Registry.
    • ARTIFACT_PROJECT_ID: o ID do projeto que contém seus artefatos.
    • ARTIFACT_REPO_NAME: o repositório que contém a imagem.
    • EXEMPT_IMAGE_PATH: um caminho opcional para uma ou mais imagens isentas, por exemplo: not-built-by-cloud-build. O bloco imageAllowlist está incluído nesta política da plataforma para que você possa isentar imagens que não têm procedência para que elas não violem a política da plataforma. Para registrar violações dessas imagens, omita esse bloco.
    • ATTESTATION_PROJECT_ID: o ID do projeto que armazena os atestados criados pelo Cloud Build.
    • SOURCE_REPO_PROJECT_ID: o ID do projeto que contém o código-fonte.
    • SOURCE_REPO_NAME: o repositório que contém a imagem. Para fins ilustrativos, para forçar uma violação dessa verificação, defina SOURCE_REPO_NAME como um repositório de código-fonte diferente do local em que a imagem reside.
    • POLICY_PROJECT_ID: o ID do projeto que contém a política de CV.
    • POLICY_ID: o ID desta política.

    • CEL_EXPRESSION: uma expressão CEL que fornece outras restrições à política da SLSA. Por exemplo, para adicionar uma restrição personalizada que exige ainda que as imagens venham de um caminho de diretório específico, substitua CEL_EXPRESSION pela seguinte expressão:

      payload.predicate.externalParameters.buildConfigSource.path != "" && payload.predicate.externalParameters.buildConfigSource.repository.contains("github.com/my-repo/my-production-repo")

  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

Implantar a imagem

  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 o pod:

    kubectl run hello-app \
    --image='LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE@DIGEST'

    O pod é implantado. Como a imagem foi criada com procedência e a partir de um repositório de código-fonte confiável, ela não violará a verificação SLSA do CV e nenhuma entrada de registro será gerada.

    Para forçar uma violação da verificação da SLSA, defina SOURCE_REPO_NAME como um repositório de código-fonte diferente do local em que a imagem reside. Também é possível acionar manualmente a versão, que pula a geração da procedência. Em seguida, verifique se há entradas de registro.

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