Use a verificação SLSA

Esta página mostra como usar a validação contínua (CV) da Autorização binária verificação SLSA, que verifica a proveniência em conformidade com a SLSA de imagens de contentores associadas a pods em execução em clusters do GKE onde a CV está ativada.

Para usar esta verificação, tem de criar imagens com o Cloud Build, que produz uma proveniência em conformidade com a SLSA.

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

O único criador fidedigno que a verificação SLSA suporta é o Cloud Build.

Custos

Este guia usa os seguintes Google Cloud serviços:

  • Artifact Registry
  • Autorização binária, mas a CV está disponível sem custo financeiro durante a fase de pré-visualização
  • Cloud Build
  • Cloud Source Repositories
  • GKE

Para gerar uma estimativa de custos com base na sua utilização projetada, 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. Se estiver a usar um fornecedor de identidade (IdP) externo, tem primeiro de iniciar sessão na CLI gcloud com a sua identidade federada.

  4. Para inicializar a CLI gcloud, execute o seguinte comando:

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

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.
    • 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.

  6. Verify that billing is enabled for your Google Cloud project.

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

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    gcloud services enable artifactregistry.googleapis.com binaryauthorization.googleapis.com cloudbuild.googleapis.com container.googleapis.com sourcerepo.googleapis.com
  8. Install the Google Cloud CLI.

  9. Se estiver a usar um fornecedor de identidade (IdP) externo, tem primeiro de iniciar sessão na CLI gcloud com a sua identidade federada.

  10. Para inicializar a CLI gcloud, execute o seguinte comando:

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

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.
    • 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.

  12. Verify that billing is enabled for your Google Cloud project.

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

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    gcloud services enable artifactregistry.googleapis.com binaryauthorization.googleapis.com cloudbuild.googleapis.com container.googleapis.com sourcerepo.googleapis.com
  14. Certifique-se de que a CLI gcloud está atualizada para a versão mais recente.
  15. Instale a ferramenta de linha de comandos kubectl.
  16. Se as suas políticas de autorização binária e clusters do GKE estiverem em projetos diferentes, certifique-se de que a autorização binária está ativada em ambos os projetos.
  17. Funções necessárias

    Esta secção mostra como definir funções para esta verificação.

    Vista geral

    Se executar todos os produtos mencionados neste guia no mesmo projeto, não tem de definir autorizações. A autorização binária configura as funções corretamente quando a ativa. Se executar os produtos em projetos diferentes, tem de definir funções conforme descrito nesta secção.

    Para garantir que o agente de serviço da autorização binária em cada projeto tem as autorizações necessárias para avaliar a verificação da SLSA de CV, peça ao seu administrador para conceder ao agente de serviço da autorização binária em cada projeto as seguintes funções de IAM:

    • Leitor do Artifact Registry (roles/artifactregistry.reader) na conta de serviço do Compute Engine do projeto do cluster
    • Se o projeto do cluster for diferente do projeto da política: Binary Authorization Policy Evaluator (roles/binaryauthorization.policyEvaluator) no agente do serviço de autorização binária do projeto do cluster, para aceder ao projeto da política
    • Se o seu projeto de atestação for diferente do projeto de políticas: Leitor de ocorrências de análise de contentores (roles/containeranalysis.occurrences.viewer) no agente do serviço de autorização binária do projeto de políticas, para que possa aceder ao projeto de atestação

    Para mais informações sobre a atribuição de funções, consulte o artigo Faça a gestão do acesso a projetos, pastas e organizações.

    O administrador também pode conceder ao agente do serviço de autorização binária em cada projeto as autorizações necessárias através de funções personalizadas ou outras funções predefinidas.

    Conceda funções através da CLI gcloud

    Para garantir que as contas de serviço em cada projeto têm as autorizações necessárias para avaliar esta verificação, conceda às contas de serviço em cada projeto as seguintes funções do IAM:

    1. Se o projeto onde executa o cluster for diferente do projeto onde reside a política, tem de conceder autorização ao agente de serviço da Autorização binária do projeto do cluster para aceder à política no projeto da política.

      1. Obtenha o agente do serviço de Autorização binária do projeto do 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. Permitir que o 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 sua política.

    2. Permita que o agente do serviço do projeto de políticas aceda a atestações:

      1. Obtenha o agente de serviço da autorização binária associado ao projeto da 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 sua política.

      2. Conceda a função:

        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 as suas atestações.

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

      1. Obtenha 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 do cluster que contém a sua política.

      2. Conceda a função:

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

    Opcional: crie e carregue uma imagem de amostra

    Esta secção é incluída para fins ilustrativos, para lhe mostrar como criar uma imagem de exemplo com proveniência em conformidade com a SLSA. A proveniência é usada mais tarde no guia para demonstrar a verificação. Saiba mais sobre a proveniência do Cloud Build.

    Crie o repositório de exemplo

    Para criar um repositório nos Cloud Source Repositories, faça o seguinte:

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

      • 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 ficheiros de origem, de configuração e de compilaçã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 ficheiro executável:

        chmod +x quickstart.sh
        
      3. Crie o ficheiro de configuração Dockerfile:

        cat > Dockerfile <<EOF
        FROM alpine
        COPY quickstart.sh /
        CMD ["/quickstart.sh"]
        EOF
        
      4. Crie o ficheiro 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 o seguinte:

        • LOCATION: a localização do Artifact Registry, por exemplo: us-west2, europe-central2 ou asia-east1
        • ARTIFACT_PROJECT_ID: o ID do projeto que armazena artefactos 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 ficheiros nos Cloud Source Repositories:

        git add .
        git commit -a
        

    Crie e carregue a imagem de amostra

    Para simplificar a utilização deste guia, recomendamos que use o mesmo projeto para SOURCE_REPO_PROJECT_ID e ARTIFACT_PROJECT_ID. Se usar projetos diferentes, pode ter de configurar autorizações da IAM adicionais. Saiba mais sobre o controlo de acesso do Artifact Registry. Para saber mais sobre o Cloud Build, consulte o artigo Vista geral do Cloud Build.

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

    1. Crie 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 o seguinte:

      • ARTIFACT_REPO_NAME: o nome do seu repositório
      • ARTIFACT_PROJECT_ID: o ID do projeto do artefacto
      • LOCATION: a localização do Artifact Registry, por exemplo: us-west2, europe-central2 ou asia-east1
    2. Crie o acionador de versão 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 o seguinte:

      • SOURCE_REPO_NAME: o nome do repositório do código-fonte
      • SOURCE_REPO_PROJECT_ID: o ID do projeto do Cloud Build
      • LOCATION: a localização
    3. Acione uma compilação enviando os ficheiros que criou anteriormente neste guia.

      git push
      

      Quando a imagem é criada com êxito, o Cloud Build gera a proveniência e carrega a imagem para o repositório do Artifact Registry.

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

      1. Certifique-se de que o Cloud Build criou a sua 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 o seguinte:

        • LOCATION: a localização do Artifact Registry
        • ARTIFACT_PROJECT_ID: o ID do projeto para artefactos
        • ARTIFACT_REPO_NAME: o nome do repositório
        • DIRECTORY: o diretório
      2. Copie o resumo da imagem mais recente. O resumo tem um aspeto semelhante ao seguinte: sha256:9432f747bd058b33de33bb5314d6eec1ac357d664e04c76824bb7072a9218d59

    5. Opcional: veja a proveniê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 o seguinte:

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

      O resultado do comando tem um aspeto semelhante ao seguinte:

      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=
      

      O resultado tem de conter o bloco provenance_summary para que a verificação SLSA funcione. Se o resultado não contiver o bloco, verifique se o Cloud Build foi invocado por um acionador de compilação. O Cloud Build não produz informações de proveniência quando é acionado manualmente.

    Crie uma política de plataforma

    Para gerar a proveniência, tem de usar um acionador do Cloud Build para criar a imagem, conforme descrito no artigo Crie e carregue a imagem de exemplo.

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

    1. Crie o ficheiro YAML da política de plataformas:

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

      • POLICY_PATH: um caminho para o ficheiro de política.
      • ARTIFACT_LOCATION: a localização do seu repositório no Artifact Registry.
      • ARTIFACT_PROJECT_ID: o ID do projeto que contém os seus artefactos.
      • 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 de plataformas para que possa isentar imagens sem proveniência para que não violem a política de plataformas. Para registar violações destas imagens, omita este bloco.
      • ATTESTATION_PROJECT_ID: o ID do projeto que armazena as atestações criadas pelo Cloud Build.
      • SOURCE_REPO_PROJECT_ID: o ID do projeto que contém o seu código fonte.
      • SOURCE_REPO_NAME: o repositório que contém a imagem. Para fins ilustrativos, para forçar uma violação desta verificação, defina SOURCE_REPO_NAME para um repositório de código fonte diferente daquele onde a sua 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 restrições adicionais à política SLSA. Por exemplo, para adicionar uma restrição personalizada que exija ainda mais que as imagens provenham 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 qualquer um dos dados de comandos abaixo, faça as seguintes substituições:

      • POLICY_ID: Um ID de política da plataforma à sua escolha. Se a política estiver noutro projeto, pode usar o nome completo do recurso: projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID.
      • POLICY_PATH: um caminho para o ficheiro de política.
      • POLICY_PROJECT_ID: o ID do projeto da 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

    Ative o CV

    Pode criar um novo cluster ou atualizar um cluster existente para usar a monitorização de CV com políticas da plataforma baseadas em verificações.

    Crie um cluster que use a monitorização de CV

    Nesta secção, cria um cluster que usa apenas a monitorização de CV com políticas da plataforma baseadas em verificações.

    Antes de usar qualquer um dos dados de comandos abaixo, faça as seguintes substituições:

    • CLUSTER_NAME: um nome do cluster.
    • LOCATION: a localização, por exemplo, us-central1 ou asia-south1.
    • POLICY_PROJECT_ID: o ID do projeto onde 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

    Crie um cluster que use a aplicação e a monitorização de CV

    Nesta secção, cria um cluster que usa a aplicação de políticas project-singleton e a monitorização de CV com políticas da plataforma baseadas em verificações:

    Antes de usar qualquer um dos dados de comandos abaixo, faça as seguintes substituições:

    • CLUSTER_NAME: um nome do cluster.
    • LOCATION: a localização, por exemplo, us-central1 ou asia-south1.
    • POLICY_PROJECT_ID: o ID do projeto onde 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

    Atualize um cluster para usar a monitorização de CV

    Nesta secção, atualiza um cluster para usar a monitorização de CV apenas com políticas da plataforma baseadas em verificações. Se o cluster já tiver a aplicação de políticas de instância única do projeto ativada, a execução deste comando desativa-a. Em alternativa, considere atualizar o cluster com a aplicação e a monitorização de CV ativadas.

    Antes de usar qualquer um dos dados de comandos abaixo, faça as seguintes substituições:

    • CLUSTER_NAME: o nome do cluster
    • LOCATION: a localização, por exemplo: us-central1 ou asia-south1
    • POLICY_PROJECT_ID: o ID do projeto onde 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

    Atualize um cluster para usar a aplicação e a monitorização de CV

    Nesta secção, atualiza um cluster para usar a aplicação da política de singleton do projeto e a monitorização de CV com políticas da plataforma baseadas em verificações.

    Antes de usar qualquer um dos dados de comandos abaixo, faça as seguintes substituições:

    • CLUSTER_NAME: um nome de cluster
    • LOCATION: a localização, por exemplo: us-central1 ou asia-south1
    • POLICY_PROJECT_ID: o ID do projeto onde 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

    Implemente a imagem

    1. Configure o dispositivo kubectl:

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

      Substitua o seguinte:

      • CLUSTER_NAME: o nome do seu cluster
      • LOCATION: a localização do cluster
      • CLUSTER_PROJECT_ID: o ID do projeto do cluster
    2. Implemente o agrupamento:

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

      O pod é implementado. Uma vez que a imagem foi criada com proveniência e a partir de um repositório de código fonte fidedigno, não viola a verificação SLSA de CV e não são geradas entradas de registo.

      Para forçar uma violação da verificação SLSA, pode definir SOURCE_REPO_NAME para um repositório de código fonte diferente daquele onde a sua imagem reside. Também pode acionar manualmente a compilação, o que ignora a geração de proveniência. Em seguida, verifique as entradas de registo.

    Veja os registos das entradas de CV

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

    O CV regista erros e violações no Cloud Logging no prazo de 24 horas. Normalmente, pode ver as entradas no prazo de algumas horas.

    Veja os registos de erros de configuração do CV

    Para ver os registos de erros de configuração de 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 seguinte mostra um erro de configuração em que não é encontrada uma política da plataforma de CV:

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

    Veja as violações de validação da política da plataforma CV

    Se nenhuma imagem violar as políticas da plataforma que ativou, não são apresentadas entradas nos registos.

    Para ver as entradas do registo de 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 do cluster.

    Tipos de verificações

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

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

    Exemplo de registo

    A seguinte entrada de registo de CV descreve uma imagem não conforme que viola uma verificação de diretório fidedigno:

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

    Esta secção descreve como limpar a monitorização de CV que configurou anteriormente neste guia.

    Pode desativar a monitorização de CV ou a autorização binária e a CV no seu cluster.

    Desative a Autorização binária num cluster

    Para desativar a aplicação da 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 o seguinte:

    • CLUSTER_NAME: o nome do cluster
    • LOCATION: a localização do cluster
    • CLUSTER_PROJECT_ID: o ID do projeto do cluster

    Desative a monitorização de políticas baseada em verificações num cluster

    Para desativar a CV com políticas baseadas em verificações no cluster e reativar a aplicação através da política de aplicação da 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 o seguinte:

    • CLUSTER_NAME: o nome do cluster
    • LOCATION: a localização do cluster
    • CLUSTER_PROJECT_ID: o ID do projeto do cluster

    Tenha em atenção que --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE é equivalente à flag mais antiga --enable-binauthz.

    Elimine a política

    Para eliminar a política, execute o seguinte comando. Não é necessário eliminar a política da plataforma baseada em verificações para desativar a auditoria de políticas baseadas em verificações.

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

    Substitua o seguinte:

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

    O que se segue?