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.

    Se você ainda não tiver uma, inscreva-se.

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

    Acessar a página do seletor de projetos

  3. Verifique se a cobrança está ativada para o seu projeto do Google Cloud. Saiba como confirmar se a cobrança está ativada para o seu 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/v1beta1/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.attestorsVerifier"
    
  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/v1beta1/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.attestorsVerifier"
    
  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 Acionadores.

    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 master.
    • Em Configuração de compilação, selecione o arquivo de configuração do Cloud Build.
    • 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 master
    
  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 master
    
  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} \
        --zone=${COMPUTE_ZONE} 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 app 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.

Como fazer a limpeza

Para evitar que os recursos usados neste tutorial sejam cobrados na conta do Google Cloud Platform, faça o seguinte:

Excluir o projeto

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

    Acessar a página "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