Como implementar a autorização binária usando o Cloud Build e o GKE

Este tutorial mostra como configurar e usar a Autorização binária no Google Kubernetes Engine (GKE). A autorização binária é o processo de criação de atestados nas imagens de contêiner para verificar se determinados critérios foram atendidos antes de implantar as imagens no GKE.

Por exemplo, a autorização binária pode verificar se o app foi aprovado nos testes de unidade ou se o app foi criado usando um conjunto específico de sistemas. Para mais informações, consulte Visão geral do Software Delivery Shield.

Este tutorial destina-se a profissionais que querem entender melhor a verificação de vulnerabilidade de contêiner e a autorização binária, bem como a implementação e aplicação delas em um pipeline de CI/CD.

Neste tutorial, é preciso que você esteja familiarizado com os seguintes tópicos e tecnologias:

  • Integração e implantação contínuas
  • Verificação de vulnerabilidades e exposições comuns (CVE)
  • GKE
  • Artifact Registry
  • Cloud Build
  • Cloud Key Management Service (Cloud KMS)

Objetivos

  • Implantar clusters do GKE para preparo e produção.
  • Criar vários atestadores e atestados.
  • Implantar um pipeline de CI/CD usando o Cloud Build.
  • Testar o pipeline de implantação.
  • Desenvolver um processo de acesso imediato.

Custos

Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Saiba mais em Limpeza.

Antes de começar

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

  2. No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

    Acessar o seletor de projetos

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

  4. Ative as APIs Binary Authorization, Cloud Build, Cloud KMS, GKE, Artifact Registry, Artifact Analysis, Resource Manager, and Cloud Source Repositories.

    Ative as APIs

    5.

  5. No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

    Acessar o seletor de projetos

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

  7. Ative as APIs Binary Authorization, Cloud Build, Cloud KMS, GKE, Artifact Registry, Artifact Analysis, Resource Manager, and Cloud Source Repositories.

    Ative as APIs

    8.

  8. No Console do Google Cloud, ative o Cloud Shell.

    Ativar o Cloud Shell

    Na parte inferior do Console do Google Cloud, uma sessão do Cloud Shell é iniciada e exibe um prompt de linha de comando. O Cloud Shell é um ambiente shell com a CLI do Google Cloud já instalada e com valores já definidos para o projeto atual. A inicialização da sessão pode levar alguns segundos.

    9. Todos os comandos neste tutorial são executados no Cloud Shell.

Arquitetura do pipeline de CI/CD

Um aspecto importante do ciclo de vida de desenvolvimento de software (SDLC) é garantir e impor que as implantações de aplicativos sigam os processos aprovados pela sua organização. Um método para estabelecer essas verificações e estimativas é com a Autorização binária no GKE. Primeiro, a autorização binária anexa observações às imagens do contêiner. Depois, o GKE verifica se as observações obrigatórias estão presentes antes da implantação do app.

Essas observações ou atestados fazem declarações sobre a imagem. Os atestados são completamente configuráveis, mas veja alguns exemplos comuns:

  • O app passou nos testes de unidade.
  • O app foi verificado pela equipe de controle de qualidade.
  • O app foi verificado quanto a vulnerabilidades e nenhuma foi encontrada.

O diagrama a seguir retrata um SDLC em que um único atestado é aplicado após a conclusão da verificação de vulnerabilidades, sem vulnerabilidades conhecidas.

Arquitetura do SDLC com um único atestado aplicado

Neste tutorial, você criará um pipeline de CI/CD usando o Cloud Source Repositories, o Cloud Build, o Artifact Registry e o GKE. O diagrama a seguir ilustra o pipeline de CI/CD.

Arquitetura do pipeline de CI/CD com três produtos do Google Cloud

Três etapas compõem esse pipeline de CI/CD:

  1. Criar uma imagem de contêiner com o código-fonte do app.

  2. Enviar a imagem do contêiner para o Artifact Registry.

  3. Verificar, com o Artifact Analysis, a imagem do contêiner quanto a vulnerabilidades de segurança conhecidas ou CVEs.

Se a imagem não tiver CVEs com uma pontuação de gravidade maior que cinco, a imagem será atestada como não tendo CVEs críticos e será automaticamente implantada para o preparo. Uma pontuação maior que cinco indica uma vulnerabilidade média a crítica. Nesses casos, a imagem não é atestada ou implantada.

Uma equipe de controle de qualidade inspeciona o app no cluster de preparo. Se ele é aprovado nos critérios, a equipe aplica um atestado manual de que a imagem tem qualidade suficiente para a implantação na produção. Os manifestos de produção são atualizados, e o app é implantado no cluster de produção do GKE.

Os clusters do GKE são configurados para analisar as imagens de contêiner em busca de atestados e rejeitar as implantações que não têm os atestados obrigatórios. Apenas o atestado da verificação de vulnerabilidades é necessário para o cluster de preparo do GKE, enquanto para o de produção também é necessário o de controle de qualidade.

Neste tutorial, você introduzirá falhas no pipeline de CI/CD para testar e verificar essa aplicação. Por fim, você implementará um procedimento de acesso imediato para ignorar essas verificações de implantação no GKE em caso de emergência.

Como configurar o ambiente

Neste tutorial, são usadas as variáveis de ambiente a seguir. É possível alterar esses valores para atender aos seus requisitos, mas todas as etapas do tutorial foram pensadas partindo do pressuposto de que essas variáveis de ambiente existem e contêm um valor válido.

  1. No Cloud Shell, defina o projeto do Google Cloud em que você implantará e gerenciará todos os recursos usados neste tutorial:

    export PROJECT_ID="${DEVSHELL_PROJECT_ID}"
gcloud config set project ${PROJECT_ID}

  2. Defina a região na qual você implantará esses recursos:

    export REGION="us-central1"

    O cluster do GKE e as chaves do Cloud KMS residirão nessa região. Neste tutorial, a região é us-central1. Para saber mais sobre regiões, consulte Geografia e regiões.

  3. Defina o número do projeto do Cloud Build:

    export PROJECT_NUMBER="$(gcloud projects describe "${PROJECT_ID}" \
  --format='value(projectNumber)')"

  4. Defina o e-mail da conta de serviço do Cloud Build:

    export CLOUD_BUILD_SA_EMAIL="${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com"

Como criar clusters do GKE

Crie dois clusters e conceda permissões de gerenciamento de identidade e acesso (IAM, na sigla em inglês) para o Cloud Build implantar aplicativos no GKE. Criar clusters do GKE pode levar alguns minutos.

  1. No Cloud Shell, crie um cluster de preparo do GKE:

    gcloud container clusters create "staging-cluster" \
  --project "${PROJECT_ID}" \
  --machine-type "n1-standard-1" \
  --region "${REGION}" \
  --num-nodes "1" \
  --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE

  2. Crie um cluster de produção do GKE:

    gcloud container clusters create "prod-cluster" \
  --project "${PROJECT_ID}" \
  --machine-type "n1-standard-1" \
  --region "${REGION}" \
  --num-nodes "1" \
  --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE

  3. Conceda permissão à conta de serviço do Cloud Build para implantar no GKE:

    gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
  --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \
  --role "roles/container.developer"

Como criar chaves de assinatura

Crie duas chaves assimétricas do Cloud KMS para assinar os atestados.

  1. No Cloud Shell, crie um keyring do Cloud KMS chamado binauthz:

    gcloud kms keyrings create "binauthz" \
  --project "${PROJECT_ID}" \
  --location "${REGION}"

  2. Crie uma chave assimétrica do Cloud KMS chamada vulnz-signer que será usada para assinar e verificar os atestados da verificação de vulnerabilidades:

    gcloud kms keys create "vulnz-signer" \
  --project "${PROJECT_ID}" \
  --location "${REGION}" \
  --keyring "binauthz" \
  --purpose "asymmetric-signing" \
  --default-algorithm "rsa-sign-pkcs1-4096-sha512"

  3. Crie uma chave assimétrica do Cloud KMS chamada qa-signer para assinar e verificar os atestados do controle de qualidade:

    gcloud kms keys create "qa-signer" \
  --project "${PROJECT_ID}" \
  --location "${REGION}" \
  --keyring "binauthz" \
  --purpose "asymmetric-signing" \
  --default-algorithm "rsa-sign-pkcs1-4096-sha512"

Como configurar atestados

Use as chaves das etapas anteriores para criar as observações anexadas às imagens do contêiner e conceder permissões para a conta de serviço do Cloud Build visualizar e anexar observações e criar os atestadores.

Criar o atestado da verificação de vulnerabilidades

  1. No Cloud Shell, crie uma nota do Artifact Analysis chamada vulnz-note:

    curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=vulnz-note" \
  --request "POST" \
  --header "Content-Type: application/json" \
  --header "Authorization: Bearer $(gcloud auth print-access-token)" \
  --header "X-Goog-User-Project: ${PROJECT_ID}" \
  --data-binary @- <<EOF
    {
      "name": "projects/${PROJECT_ID}/notes/vulnz-note",
      "attestation": {
        "hint": {
          "human_readable_name": "Vulnerability scan note"
        }
      }
    }
EOF

  2. Conceda permissão à conta de serviço do Cloud Build para visualizar e anexar a observação vulnz-note às imagens do contêiner:

    curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/vulnz-note:setIamPolicy" \
  --request POST \
  --header "Content-Type: application/json" \
  --header "Authorization: Bearer $(gcloud auth print-access-token)" \
  --header "X-Goog-User-Project: ${PROJECT_ID}" \
  --data-binary @- <<EOF
    {
      "resource": "projects/${PROJECT_ID}/notes/vulnz-note",
      "policy": {
        "bindings": [
          {
            "role": "roles/containeranalysis.notes.occurrences.viewer",
            "members": [
              "serviceAccount:${CLOUD_BUILD_SA_EMAIL}"
            ]
          },
          {
            "role": "roles/containeranalysis.notes.attacher",
            "members": [
              "serviceAccount:${CLOUD_BUILD_SA_EMAIL}"
            ]
          }
        ]
      }
    }
EOF

  3. Crie o atestador de verificação de vulnerabilidades:

    gcloud container binauthz attestors create "vulnz-attestor" \
  --project "${PROJECT_ID}" \
  --attestation-authority-note-project "${PROJECT_ID}" \
  --attestation-authority-note "vulnz-note" \
  --description "Vulnerability scan attestor"

  4. Adicione a chave pública da chave de assinatura do atestador:

    gcloud beta container binauthz attestors public-keys add \
  --project "${PROJECT_ID}" \
  --attestor "vulnz-attestor" \
  --keyversion "1" \
  --keyversion-key "vulnz-signer" \
  --keyversion-keyring "binauthz" \
  --keyversion-location "${REGION}" \
  --keyversion-project "${PROJECT_ID}"

  5. Conceda permissão à conta de serviço do Cloud Build para ver os atestados feitos por vulnz-attestor:

    gcloud container binauthz attestors add-iam-policy-binding "vulnz-attestor" \
  --project "${PROJECT_ID}" \
  --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \
  --role "roles/binaryauthorization.attestorsViewer"

  6. Conceda permissão à conta de serviço do Cloud Build para assinar objetos usando a chave vulnz-signer:

    gcloud kms keys add-iam-policy-binding "vulnz-signer" \
  --project "${PROJECT_ID}" \
  --location "${REGION}" \
  --keyring "binauthz" \
  --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \
  --role 'roles/cloudkms.signerVerifier'

Criar o atestado de controle de qualidade

  1. No Cloud Shell, crie uma nota do Artifact Analysis chamada qa-note:

    curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=qa-note" \
  --request "POST" \
  --header "Content-Type: application/json" \
  --header "Authorization: Bearer $(gcloud auth print-access-token)" \
  --header "X-Goog-User-Project: ${PROJECT_ID}" \
  --data-binary @- <<EOF
    {
      "name": "projects/${PROJECT_ID}/notes/qa-note",
      "attestation": {
        "hint": {
          "human_readable_name": "QA note"
        }
      }
    }
EOF

  2. Conceda permissão à conta de serviço do Cloud Build para visualizar e anexar a observação qa-note às imagens do contêiner:

    curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/qa-note:setIamPolicy" \
  --request POST \
  --header "Content-Type: application/json" \
  --header "Authorization: Bearer $(gcloud auth print-access-token)" \
  --header "X-Goog-User-Project: ${PROJECT_ID}" \
  --data-binary @- <<EOF
    {
      "resource": "projects/${PROJECT_ID}/notes/qa-note",
      "policy": {
        "bindings": [
          {
            "role": "roles/containeranalysis.notes.occurrences.viewer",
            "members": [
              "serviceAccount:${CLOUD_BUILD_SA_EMAIL}"
            ]
          },
          {
            "role": "roles/containeranalysis.notes.attacher",
            "members": [
              "serviceAccount:${CLOUD_BUILD_SA_EMAIL}"
            ]
          }
        ]
      }
    }
EOF

  3. Crie o atestador de controle de qualidade:

    gcloud container binauthz attestors create "qa-attestor" \
  --project "${PROJECT_ID}" \
  --attestation-authority-note-project "${PROJECT_ID}" \
  --attestation-authority-note "qa-note" \
  --description "QA attestor"

  4. Adicione a chave pública da chave de assinatura do atestador:

    gcloud beta container binauthz attestors public-keys add \
  --project "${PROJECT_ID}" \
  --attestor "qa-attestor" \
  --keyversion "1" \
  --keyversion-key "qa-signer" \
  --keyversion-keyring "binauthz" \
  --keyversion-location "${REGION}" \
  --keyversion-project "${PROJECT_ID}"

  5. Conceda permissão à conta de serviço do Cloud Build para ver os atestados feitos por qa-attestor:

    gcloud container binauthz attestors add-iam-policy-binding "qa-attestor" \
  --project "${PROJECT_ID}" \
  --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \
  --role "roles/binaryauthorization.attestorsViewer"

  6. Conceda permissão para a equipe de controle de qualidade assinar os atestados:

    gcloud kms keys add-iam-policy-binding "qa-signer" \
  --project "${PROJECT_ID}" \
  --location "${REGION}" \
  --keyring "binauthz" \
  --member "group:qa-team@example.com" \
  --role 'roles/cloudkms.signerVerifier'

Como definir a política de autorização binária

Mesmo que tenha criado os clusters do GKE com --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE, crie uma política para instruir o GKE sobre quais são os atestados necessários para a execução dos binários no cluster. As políticas de autorização binária existem no nível do projeto, mas têm configuração para o nível do cluster.

A política a seguir altera a política padrão das seguintes maneiras:

  • Altera o evaluationMode padrão para ALWAYS_DENY. Somente imagens isentas ou imagens com os atestados obrigatórios podem ser executadas no cluster.

  • Ativa o globalPolicyEvaluationMode, o que altera a lista de permissões padrão para incluir apenas imagens do sistema fornecidas pelo Google.

  • Define as seguintes regras de admissão de cluster:

    • staging-cluster requer atestados do vulnz-attestor.

    • prod-cluster requer atestados do vulnz-attestor e do qa-attestor.

Para mais informações sobre políticas de autorização binária, consulte Referência de política YAML.

  1. No Cloud Shell, crie um arquivo YAML que descreva a política de autorização binária do projeto do Google Cloud:

    cat > ./binauthz-policy.yaml <<EOF
admissionWhitelistPatterns:
- namePattern: docker.io/istio/*
defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_DENY
globalPolicyEvaluationMode: ENABLE
clusterAdmissionRules:
  # Staging cluster
  ${REGION}.staging-cluster:
    evaluationMode: REQUIRE_ATTESTATION
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    requireAttestationsBy:
    - projects/${PROJECT_ID}/attestors/vulnz-attestor

  # Production cluster
  ${REGION}.prod-cluster:
    evaluationMode: REQUIRE_ATTESTATION
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    requireAttestationsBy:
    - projects/${PROJECT_ID}/attestors/vulnz-attestor
    - projects/${PROJECT_ID}/attestors/qa-attestor
EOF

  2. Faça o upload da nova política para o projeto do Google Cloud:

    gcloud container binauthz policy import ./binauthz-policy.yaml \
  --project "${PROJECT_ID}"

Como criar o verificador de vulnerabilidades e ativar a API

Crie uma imagem de contêiner que seja usada como uma etapa da criação no Cloud Build. Esse contêiner compara as pontuações de gravidade das vulnerabilidades detectadas com o limite configurado. Se a pontuação estiver dentro do limite, o Cloud Build criará um atestado para o contêiner. Se a pontuação estiver fora do limite, haverá falha e nenhum atestado será criado.

  1. No Cloud Shell, crie um novo repositório do Artifact Registry para armazenar a imagem do atestador:

    gcloud artifacts repositories create cloudbuild-helpers \
  --repository-format=DOCKER --location=${REGION}

  2. Clone as ferramentas de autorização binária e o exemplo de origem do aplicativo:

    git clone https://github.com/GoogleCloudPlatform/gke-binary-auth-tools ~/binauthz-tools

  3. Crie e envie o contêiner do atestador do verificador de vulnerabilidades chamado attestor para o Artifact Registry cloudbuild-helpers:

    gcloud builds submit \
  --project "${PROJECT_ID}" \
  --tag "us-central1-docker.pkg.dev/${PROJECT_ID}/cloudbuild-helpers/attestor" \
  ~/binauthz-tools

Como configurar o pipeline do Cloud Build

Crie um repositório do Cloud Source Repositories e um acionador do Cloud Build para o app de exemplo e os manifestos do Kubernetes.

Criar o repositório hello-app Cloud Source Repositories e Artifact Registry

  1. No Cloud Shell, crie um repositório do Cloud Source Repositories para o app de exemplo:

    gcloud source repos create hello-app \
  --project "${PROJECT_ID}"

  2. Clone o repositório localmente:

    gcloud source repos clone hello-app ~/hello-app \
  --project "${PROJECT_ID}"

  3. Copie o código de exemplo no repositório:

    cp -R ~/binauthz-tools/examples/hello-app/* ~/hello-app

  4. Crie um novo repositório do Artifact Registry para armazenar imagens de aplicativo:

    gcloud artifacts repositories create applications \
  --repository-format=DOCKER --location=${REGION}

Criar o acionador do Cloud Build para o hello-app

  1. No Console do Google Cloud, acesse a página Gatilhos.

    Acessar acionadores

  2. Clique em Gerenciar repositórios.

  3. Para o repositório hello-app, clique em ... e selecione Adicionar gatilho.

  4. Na janela Configurações do acionador, digite os detalhes a seguir:

    • No campo Nome, use build-vulnz-deploy.
    • Em Evento, escolha Enviar para uma ramificação.
    • No menu do campo Repositório, escolha hello-app.
    • No campo Ramificação, digite master.
    • Configuração: selecione Arquivo de configuração do Cloud Build (yaml ou json).
    • Em Local, selecione Repositório e insira o valor padrão /cloudbuild.yaml.

  5. Adicione os seguintes pares de variável de substituição:

    • _COMPUTE_REGION com o valor us-central1 (ou a região escolhida no início).
    • _KMS_KEYRING com o valor binauthz.
    • _KMS_LOCATION com o valor us-central1 (ou a região escolhida no início).
    • _PROD_CLUSTER com o valor prod-cluster.
    • _QA_ATTESTOR com o valor qa-attestor.
    • _QA_KMS_KEY com o valor qa-signer.
    • _QA_KMS_KEY_VERSION com o valor 1.
    • _STAGING_CLUSTER com o valor staging-cluster.
    • _VULNZ_ATTESTOR com o valor vulnz-attestor.
    • _VULNZ_KMS_KEY com o valor vulnz-signer.
    • _VULNZ_KMS_KEY_VERSION com o valor 1.

  6. Clique em Criar.

Testar o pipeline do Cloud Build

Confirme e envie o app de exemplo para o repositório do Cloud Source Repositories para testar o pipeline de CI/CD. O Cloud Build detecta a alteração, cria e implanta o app em staging-cluster. O pipeline aguarda até 10 minutos pela confirmação do controle de qualidade. Depois que a equipe de controle de qualidade verifica a implantação, o processo continua, os manifestos de produção do Kubernetes são atualizados, e o Cloud Build implanta o app em prod-cluster.

  1. No Cloud Shell, confirme e envie os arquivos hello-app para o repositório do Cloud Source Repositories para acionar uma versão:

    cd ~/hello-app

git add .
git commit -m "Initial commit"
git push origin master

  2. No console do Google Cloud, abra a página IAM.

    Acessar a página de histórico

  3. Para ver o progresso da versão, clique na execução mais recente do Cloud Build.

    Informações sobre a versão

  4. Quando a implantação no staging-cluster tiver terminado, vá para a página Serviços.

    Acessar a página de serviços

  5. Para verificar se o app está funcionando, clique no link Endpoints do app.

  6. Acesse a página Repositórios.

    Acessar a página de imagens

  7. Clique em applications.

  8. Clique em hello-app.

  9. Clique na imagem que você validou na implantação de preparo.

    Nome da imagem validada

  10. Copie o valor de Resumo dos detalhes da imagem. Essa informação é necessária na próxima etapa

    Valor do resumo da imagem

  11. Para aplicar o atestado de controle de qualidade manual, substitua ... pelo valor que você copiou dos detalhes da imagem. A variável DIGEST precisa estar no formato sha256:hash-value`.

    A etapa Await QA attestation da versão também emitirá um comando para copiar e colar, mostrado abaixo.

    DIGEST="sha256:..." # Replace with your value

gcloud beta container binauthz attestations sign-and-create \
  --project "${PROJECT_ID}" \
  --artifact-url "${REGION}-docker.pkg.dev/${PROJECT_ID}/applications/hello-app@${DIGEST}" \
  --attestor "qa-attestor" \
  --attestor-project "${PROJECT_ID}" \
  --keyversion "1" \
  --keyversion-key "qa-signer" \
  --keyversion-location "${REGION}" \
  --keyversion-keyring "binauthz" \
  --keyversion-project "${PROJECT_ID}"

  12. Para verificar se o app foi implantado, acesse a página Serviços.

    Acessar a página de serviços

  13. Para ver o app, clique no link do endpoint.

Como implantar uma imagem sem atestado

Até o momento, o aplicativo de exemplo não tinha vulnerabilidades. Atualize o app para gerar outra mensagem e alterar a imagem de base.

  1. No Cloud Shell, altere Hello World para Binary Authorization e altere a imagem base de distroless para debian:

    cd ~/hello-app
sed -i "s/Hello World/Binary Authorization/g" main.go
sed -i "s/FROM gcr\.io\/distroless\/static-debian11/FROM debian/g" Dockerfile

  2. Confirme e envie as alterações:

    git add .
git commit -m "Change message and base image"
git push origin master

  3. Para monitorar o status do pipeline de CI/CD, no Console do Google Cloud, acesse a página Histórico.

    Acessar a página de histórico

    Essa versão falha por causa dos CVEs detectados na imagem.

  4. Para examinar os CVEs identificados, acesse a página Imagens.

    Acessar a página de imagens

  5. Clique em hello-app.

  6. Para revisar os CVEs identificados, clique no resumo de vulnerabilidades da imagem mais recente.

    Link de resumo de vulnerabilidades de uma imagem recente.

  7. No Cloud Shell, tente implantar a nova imagem na produção sem o atestado de verificação de vulnerabilidades:

    export SHA_DIGEST="[SHA_DIGEST_VALUE]"

cd ~/hello-app
sed "s/REGION/${REGION}/g" kubernetes/deployment.yaml.tpl | \
    sed "s/GOOGLE_CLOUD_PROJECT/${PROJECT_ID}/g" | \
    sed -e "s/DIGEST/${SHA_DIGEST}/g" > kubernetes/deployment.yaml

gcloud container clusters get-credentials \
    --project=${PROJECT_ID} \
    --region="${REGION}" prod-cluster

kubectl apply -f kubernetes

  8. No Console do Google Cloud, acesse a página Cargas de trabalho.

    Acessar a página de cargas de trabalho

    Status de falha de imagem.

    Falha ao implantar a imagem porque ela não foi assinada pelo vulnz-attestor e pelo qa-attestor.

Procedimento de acesso imediato

De vez em quando, você precisa permitir alterações que estão fora do fluxo de trabalho normal. Para permitir implantações de imagem sem os atestados obrigatórios, a definição do pod é anotada com uma sinalização de política de acesso imediato. Ativar essa sinalização ainda faz com que o GKE verifique os atestados obrigatórios, mas permite que a imagem do contêiner seja implantada e registra as violações.

Para mais informações sobre como ignorar verificações de atestado, consulte Substituir uma política.

  1. No Cloud Shell, remova a marca de comentário da anotação de acesso imediato no manifesto do Kubernetes:

    sed -i "31s/^#//" kubernetes/deployment.yaml

  2. Use kubectl para aplicar as alterações:

    kubectl apply -f kubernetes

  3. Para verificar se a alteração foi implantada no prod-cluster, acesse Cargas de trabalho no Console do Google Cloud.

    Acessar a página de cargas de trabalho

    A mensagem de erro de implantação desaparece.

  4. Para verificar se o aplicativo foi implantado, acesse a página Serviços.

    Acessar a página de serviços

  5. Para ver o app, clique no link do endpoint.

Limpeza

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados no tutorial, exclua o projeto que os contém ou mantenha o projeto e exclua os recursos individuais.

Exclua o projeto

  1. No Console do Google Cloud, acesse a página Gerenciar recursos.

    Acessar "Gerenciar recursos"

  2. Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
  3. Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

A seguir