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 e casos de uso, consulte Ajudar a proteger as cadeias de suprimento de software no Google Kubernetes Engine.

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
  • Container 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 tutorial, usamos 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 ser qualificados para uma avaliação gratuita.

Ao concluir este tutorial, exclua os recursos criados para evitar o faturamento contínuo. Para mais informações, consulte Como fazer a 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 o faturamento está ativado para seu projeto na nuvem. Saiba como confirmar se o faturamento está ativado para o projeto.

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

    Ative as APIs

  5. No Console do Cloud, ative o Cloud Shell.

    Ativar o Cloud Shell

    Na parte inferior do Console do Cloud, uma sessão do Cloud Shell é iniciada e exibe um prompt de linha de comando. O Cloud Shell é um ambiente com o SDK do Cloud pré-instalado com a ferramenta de linha de comando gcloud e os valores já definidos para seu projeto atual. A inicialização da sessão pode levar alguns segundos.

  6. 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 Container 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 Container Registry.

  3. Verificar, com o Container 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 Cloud em que você implantará e gerenciará todos os recursos usados neste tutorial:

    export PROJECT_ID="${DEVSHELL_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" \
      --enable-binauthz
    
  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" \
      --enable-binauthz
    
  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 observação do Container 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 verificar 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 observação do Container 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 verificar 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 --enable-binauthz, 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 para o projeto do 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 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, clone as ferramentas de autorização binária e a fonte do aplicativo de exemplo:

    git clone https://github.com/GoogleCloudPlatform/gke-binary-auth-tools ~/binauthz-tools
    
  2. Crie e envie o contêiner do atestador do verificador de vulnerabilidades chamado cloudbuild-attestor para o Container Registry:

    gcloud builds submit \
      --project "${PROJECT_ID}" \
      --tag "gcr.io/${PROJECT_ID}/cloudbuild-attestor" \
      ~/binauthz-tools
    
  3. Ative a API de verificação de vulnerabilidades:

    gcloud services enable containerscanning.googleapis.com
    

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 acionador do Cloud Source Repositories para o hello-app

  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
    

Criar o acionador do Cloud Build para o hello-app

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

    Acessar acionadores

  2. Clique em Criar acionador.

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

    • No menu do campo Repositório, escolha hello-app.
    • No campo Nome, use build-vulnz-deploy.
    • Em Tipo de acionador, selecione Ramificação.
    • No campo Ramificação (regex), use main.
    • Configuração: selecione Arquivo de configuração do Cloud Build (yaml ou json).
    • No Local do arquivo de configuração do Cloud Build , use o valor padrão /cloudbuild.yaml.
  4. 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.
  5. Clique em Criar acionador.

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 main
    
  2. No Console do Cloud, acesse a página Histórico.

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

    Acessar a página de imagens

  7. Clique em hello-app.

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

    Nome da imagem validada

  9. Na página Detalhes do resumo, copie o valor do Resumo dos detalhes da imagem. Essa informação é necessária no próximo passo.

    Valor do resumo da imagem

  10. 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 "gcr.io/${PROJECT_ID}/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}"
    
  11. Para verificar se o app foi implantado, acesse a página Serviços.

    Acessar a página de serviços

  12. 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/FROM debian/g" Dockerfile
    
  2. Confirme e envie as alterações:

    git add .
    git commit -m "Change message and base image"
    git push origin main
    
  3. Para monitorar o status do pipeline de CI/CD, no Console do 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/GOOGLE_CLOUD_PROJECT/${DEVSHELL_PROJECT_ID}/g" \
        kubernetes/deployment.yaml.tpl | sed -e  \
        "s/DIGEST/${SHA_DIGEST}/g" > kubernetes/deployment.yaml
    
    gcloud container clusters get-credentials \
        --project=${DEVSHELL_PROJECT_ID} \
        --region="${REGION}" prod-cluster
    
    kubectl apply -f kubernetes
    
  8. No Console do 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 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 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