Usar a verificação da SLSA

Nesta página, mostramos como usar a verificação SLSA de validação contínua (CV, na sigla em inglês) da autorização binária, que verifica a procedência das imagens de contêiner associadas aos pods em execução nos clusters do Google Kubernetes Engine (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

Faça login na sua conta do Google Cloud. Se você começou a usar o Google Cloud agora, crie uma conta para avaliar o desempenho de nossos produtos em situações reais. Clientes novos também recebem US$ 300 em créditos para executar, testar e implantar cargas de trabalho.

Instale a CLI do Google Cloud.

Para inicializar a CLI gcloud, execute o seguinte comando:

gcloud init

Observação: se você instalou a CLI gcloud anteriormente, verifique se tem a versão mais recente executando

gcloud components
      update

Crie ou selecione um projeto do Google Cloud.

Crie um projeto do Google Cloud:
```
gcloud projects create PROJECT_ID
```
Substitua PROJECT_ID por um nome para o projeto do Google Cloud que você está criando.
Selecione o projeto do Google Cloud que você criou:
```
gcloud config set project PROJECT_ID
```
Substitua PROJECT_ID pelo nome do projeto do Google Cloud.

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

Ative as APIs Artifact Registry, Binary Authorization, Cloud Build, GKE, Cloud Source Repositories:

gcloud services enable artifactregistry.googleapis.com binaryauthorization.googleapis.com cloudbuild.googleapis.com container.googleapis.com sourcerepo.googleapis.com

Instale a CLI do Google Cloud.

Para inicializar a CLI gcloud, execute o seguinte comando:

gcloud init

Observação: se você instalou a CLI gcloud anteriormente, verifique se tem a versão mais recente executando

gcloud components
      update

Crie ou selecione um projeto do Google Cloud.

Crie um projeto do Google Cloud:
```
gcloud projects create PROJECT_ID
```
Substitua PROJECT_ID por um nome para o projeto do Google Cloud que você está criando.
Selecione o projeto do Google Cloud que você criou:
```
gcloud config set project PROJECT_ID
```
Substitua PROJECT_ID pelo nome do projeto do Google Cloud.

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

Ative as APIs Artifact Registry, Binary Authorization, Cloud Build, GKE, Cloud Source Repositories:

gcloud services enable artifactregistry.googleapis.com binaryauthorization.googleapis.com cloudbuild.googleapis.com container.googleapis.com sourcerepo.googleapis.com

Verifique se a CLI gcloud está atualizada para a versão mais recente.
Instale a ferramenta de linha de comando kubectl.
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 do 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 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 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:

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.

Permita que o agente de serviço do projeto de política acesse os atestados:

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.

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.

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 hospeda 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 simples 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:

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

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:

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

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

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.
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

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:

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
    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.
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 este comando:
Linux, macOS ou Cloud Shell

Observação: para inicializar a Google Cloud CLI com autenticação e um projeto, execute gcloud init. ou gcloud auth login e gcloud config set project.
```
gcloud beta container binauthz policy create POLICY_ID \
    --platform=gke \
    --policy-file=POLICY_PATH \
    --project=POLICY_PROJECT_ID
```
Windows (PowerShell)

Observação: para inicializar a Google Cloud CLI com autenticação e um projeto, execute gcloud init. ou gcloud auth login e gcloud config set project.
```
gcloud beta container binauthz policy create POLICY_ID `
    --platform=gke `
    --policy-file=POLICY_PATH `
    --project=POLICY_PROJECT_ID
```
Windows (cmd.exe)

Observação: para inicializar a Google Cloud CLI com autenticação e um projeto, execute gcloud init. ou gcloud auth login e gcloud config set project.
```
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 este 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 este 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 este 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 este 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

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

A CV registra as violações da política da plataforma no Cloud Logging em até 24 horas. Geralmente, você pode ver as entradas dentro de algumas horas.

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

Limpeza

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

Usar a verificação da SLSA

Custos

Antes de começar

Funções exigidas

Informações gerais

Conceder papéis usando a CLI gcloud

Opcional: criar e fazer upload de uma imagem de amostra

Criar o repositório de amostra

Criar e fazer upload da imagem de amostra

Criar uma política de plataforma

Linux, macOS ou Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

Ativar a CV

Criar um cluster que use o monitoramento de CV

Linux, macOS ou Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

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

Linux, macOS ou Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

Atualizar um cluster para usar o monitoramento de CV

Linux, macOS ou Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

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

Linux, macOS ou Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

Implantar a imagem

Ver registros das entradas de CV

Tipos de verificação

Exemplo de registro

Limpeza

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

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

Exclua a política:

A seguir