GSP521

Visão geral
Nos laboratórios com desafio, apresentamos uma situação e um conjunto de tarefas. Para concluí-las, em vez de seguir instruções detalhadas, você usará o que aprendeu nos laboratórios do curso. Um sistema automático de pontuação (mostrado nesta página) vai avaliar seu desempenho.
Nos laboratórios com desafio, não ensinamos novos conceitos do Google Cloud. O objetivo dessas tarefas é aprimorar aquilo que você já aprendeu, como a alteração de valores padrão ou a leitura e pesquisa de mensagens para corrigir seus próprios erros.
Para alcançar a pontuação de 100%, você precisa concluir todas as tarefas no tempo definido.
Este laboratório é recomendado para estudantes que se inscreveram no curso Segurança na entrega de software. Tudo pronto para começar o desafio?
Cenário do desafio
Você é engenheiro de software no Cymbal Bank, e sua tarefa é implantar, com segurança, um novo aplicativo da Web na nuvem. O aplicativo lida com dados sensíveis do cliente, então a segurança é fundamental. Sua meta é implementar um pipeline automatizado e robusto que crie, verifique, assine e implante o aplicativo conteinerizado, seguindo padrões de segurança rigorosos. Para este desafio, você vai usar serviços do Google Cloud, como Artifact Registry, Autorização binária e Cloud Build, para alcançar esse objetivo em um aplicativo de amostra.
Conhecimentos avaliados
-
Criar repositórios do Artifact Registry: como configurar repositórios do Artifact Registry para armazenar imagens do Docker para verificação e produção.
-
Enviar imagens Docker: crie e envie imagens Docker para o Artifact Registry usando o Cloud Build para verificação de vulnerabilidades.
-
Configurar a Autorização Binária: configure a autorização binária com atestadores e chaves para aplicar políticas de assinatura de imagem.
-
Verificar verificações de vulnerabilidades: examine os resultados da verificação de vulnerabilidades no Artifact Registry para identificar e entender possíveis riscos de segurança.
-
Criar um pipeline de CI/CD seguro: criar um pipeline do Cloud Build que automatize a criação de imagens, a verificação de vulnerabilidades e a assinatura de imagens.
-
Analisar e corrigir: analisar uma build com falha devido a vulnerabilidades críticas e corrigir os problemas no código do aplicativo.
-
Recriar e implantar: execute novamente o pipeline de CI/CD com o código corrigido e garanta a implantação bem-sucedida no Cloud Run.
Configuração e requisitos
Antes de clicar no botão Começar o Laboratório
Leia estas instruções. Os laboratórios são cronometrados e não podem ser pausados. O timer é ativado quando você clica em Iniciar laboratório e mostra por quanto tempo os recursos do Google Cloud vão ficar disponíveis.
Este laboratório prático permite que você realize as atividades em um ambiente real de nuvem, e não em uma simulação ou demonstração. Você vai receber novas credenciais temporárias para fazer login e acessar o Google Cloud durante o laboratório.
Confira os requisitos para concluir o laboratório:
- Acesso a um navegador de Internet padrão (recomendamos o Chrome).
Observação: para executar este laboratório, use o modo de navegação anônima (recomendado) ou uma janela anônima do navegador. Isso evita conflitos entre sua conta pessoal e de estudante, o que poderia causar cobranças extras na sua conta pessoal.
- Tempo para concluir o laboratório: não se esqueça que, depois de começar, não será possível pausar o laboratório.
Observação: use apenas a conta de estudante neste laboratório. Se usar outra conta do Google Cloud, você poderá receber cobranças nela.
Tarefa 1: Ativar APIs e configurar o ambiente
Antes de começar a criar seu pipeline de CI/CD seguro, você precisa ativar as APIs necessárias do Google Cloud e configurar seu ambiente de desenvolvimento. Isso garante que você tenha acesso a todos os serviços e ferramentas necessários.
- Ative as APIs necessárias para este laboratório:
gcloud services enable \
cloudkms.googleapis.com \
run.googleapis.com \
cloudbuild.googleapis.com \
container.googleapis.com \
containerregistry.googleapis.com \
artifactregistry.googleapis.com \
containerscanning.googleapis.com \
ondemandscanning.googleapis.com \
binaryauthorization.googleapis.com
- No Cloud Shell, execute o comando a seguir para baixar os arquivos de amostra do Python, Docker e Cloud Build:
mkdir sample-app && cd sample-app
gcloud storage cp gs://spls/gsp521/* .
- Criar dois repositórios do Artifact Registry: um para verificação e outro para produção. Nomeie os repositórios como
artifact-scanning-repo e artifact-prod-repo, respectivamente.
O repositório de verificação será usado para armazenar a imagem Docker antes da verificação de vulnerabilidades, enquanto o repositório de produção vai armazenar a imagem depois que ela for assinada e estiver pronta para implantação.
Para conferir o objetivo, clique em verificar meu progresso.
Ativar APIs e configurar o Artifact Registry.
Tarefa 2: Criar o pipeline do Cloud Build
Nesta tarefa, você vai criar a base do seu pipeline de CI/CD criando uma configuração básica do Cloud Build para criar e enviar sua imagem Docker para o Artifact Registry. Essa etapa inicial vai permitir que você verifique se há vulnerabilidades na imagem mais tarde no laboratório.
-
Comece adicionando os seguintes papéis à conta de serviço do Cloud Build:
roles/iam.serviceAccountUser
roles/ondemandscanning.admin
-
No Editor do Cloud Shell, abra o arquivo sample-app/cloudbuild.yaml.
-
Conclua as tarefas pendentes:preencha os marcadores de posição do nome da imagem (<image-name>). Para isso, você precisará consultar o repositório artifact-scanning-repo. O nome da imagem deve ser sample-image. Use a região .
-
Enviar o build.
-
Confira a imagem que você enviou para o repositório artifact-scanning-repo e verifique se há várias vulnerabilidades Críticas nos resultados da verificação.
Para conferir o objetivo, clique em verificar meu progresso.
Criar um pipeline do Cloud Build
Tarefa 3: Configurar a autorização binária
Para aplicar políticas de segurança rigorosas para implantações de contêineres, você vai usar a autorização binária. Com esse serviço, você define quem pode implantar quais imagens e em quais condições. Nesta tarefa, você vai criar e configurar os componentes necessários da Autorização Binária, incluindo atestadores, anotações e chaves do KMS. Isso vai preparar você para integrar a Autorização Binária ao seu pipeline de CI/CD.
Criar um atestador.
-
No Cloud Shell, crie um arquivo JSON. Esse arquivo vai definir uma nota do atestador que contém a dica de atestado. O human_readable_name da dica de atestado deve ser definido como "Container Vulnerabilities attestation authority".
-
Usar a API Container Analysis para criar uma nova nota com o ID vulnerability_note. Os detalhes da nota devem ser definidos no arquivo de notas criado na etapa anterior. Inclua a autenticação adequada e defina o cabeçalho Content-Type apropriado na sua solicitação de API.
-
Usar a API Container Analysis para recuperar os detalhes da anotação de atestador que você acabou de criar. Inclua a autenticação adequada na sua solicitação de API.
-
Usar a ferramenta de linha de comando gcloud para criar um novo atestador da Autorização Binária. O ID do atestador deve ser vulnerability-attestor e estar associado à nota do atestador criada anteriormente.
-
Usar a ferramenta de linha de comando gcloud para listar todos os atestadores de autorização binária atuais. Verifique se o atestador que você acabou de criar está incluído na lista.
-
Crie uma política do IAM que conceda à conta de serviço da Autorização Binária o papel roles/containeranalysis.notes.occurrences.viewer na anotação do atestador que você criou. Em seguida, use a API Container Analysis para definir essa política de IAM na nota.
Gerar um par de KMS
Nesta seção, você vai gerar um par de chaves do KMS para assinar atestados.
-
Configurar o gerenciamento de chaves:
- Crie um keyring do KMS chamado
binauthz-keys no local global para armazenar as chaves.
- Nesse keyring, gere um novo par de chaves de assinatura assimétricas. Nomeie a chave como
lab-key e verifique se ela é a versão 1.
-
Vincule a chave ao atestador:
- Usar a ferramenta de linha de comando
gcloud para associar a lab-key (versão 1) ao seu atestador da Autorização Binária. Ao fazer referência à chave, especifique o local global e o keyring binauthz-keys.
Atualizar a política de autorização binária
-
Modificar a política: ajustar a política de autorização binária para aplicar a exigência de atestados para a regra padrão.
-
Incorporar seu atestador: inclua o vulnerability-attestor que você criou anteriormente como parte da configuração da política.
Para conferir o objetivo, clique em verificar meu progresso.
Criar um atestador, um par de KMS e atualizar a política.
Tarefa 4: Criar um pipeline de CI/CD do Cloud Build com verificação de vulnerabilidades
Com base no pipeline básico da Tarefa 2, agora você vai aprimorá-lo com recursos de segurança essenciais. Isso inclui a verificação de vulnerabilidades para identificar possíveis pontos fracos nas imagens de contêiner e a assinatura de imagens para garantir a integridade delas. Nesta tarefa, você vai integrar a verificação de vulnerabilidades e a assinatura de imagens ao seu pipeline de CI/CD, tornando-o mais robusto e seguro.
Adicione os papéis necessários à conta de serviço do Cloud Build
-
Conceda à conta de serviço do Cloud Build os seguintes papéis do IAM no seu projeto:
roles/binaryauthorization.attestorsViewer
roles/cloudkms.signerVerifier
roles/containeranalysis.notes.attacher
roles/iam.serviceAccountUser
roles/ondemandscanning.admin
-
Além disso, verifique se a conta de serviço padrão do Compute Engine também tem o papel cloudkms.signerVerifier.
Instalar a etapa de build personalizado
- Você usará uma etapa do build personalizado no Cloud Build para simplificar o processo de atestação. O Google fornece essa etapa do build personalizado, contendo mais funções auxiliares para simplificar o processo. Antes de usar, o código da etapa do build personalizado precisa ser integrado a um contêiner e enviado ao Cloud Build. Para isso, execute este comando:
git clone https://github.com/GoogleCloudPlatform/cloud-builders-community.git
cd cloud-builders-community/binauthz-attestation
gcloud builds submit . --config cloudbuild.yaml
cd ../..
rm -rf cloud-builders-community
Atualizar o pipeline do Cloud Build
Nesta seção, você vai concluir o pipeline do Cloud Build para incluir a verificação de vulnerabilidades, verificações de gravidade, assinatura de imagens e implantação no Cloud Run. O código abaixo é uma implementação parcial do pipeline. Você vai precisar preencher as partes que estão faltando para concluir o pipeline.
-
Concluir TODOs:preencha as partes que faltam no pipeline, incluindo:
- Especificar o local da imagem no Artifact Registry para verificação de vulnerabilidades. Observe que você quer verificar a imagem no repositório
artifact-scanning-repo.
- Definir o nível de gravidade apropriado para verificações de vulnerabilidade. O pipeline deve falhar se alguma vulnerabilidade
CRÍTICA for encontrada.
- Configurar a etapa de assinatura de imagem com as informações corretas do atestador e da chave do KMS. O nome do atestador é
vulnerability-attestor e a versão da chave é o caminho completo para a versão 1 de lab-key.
- Retagging the image for production and pushing it to the production repository. Você deve usar o repositório
artifact-prod-repo para essa finalidade.
- Implantar a imagem no Cloud Run. Você vai usar a imagem de produção do repositório
artifact-prod-repo nesta etapa.
Observação:você já preencheu os primeiros TODOs no arquivo cloudbuild.yaml na segunda tarefa deste laboratório. Substitua o restante dos marcadores pelos valores corretos para os outros TODOs.
cloudbuild.yaml
steps:
# TODO: #1. Etapa do build. Substitua o marcador <image-name> pelo valor correto.
- id: "build"
name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', '<image-name>', '.']
waitFor: ['-']
# TODO: #2. Envie para o Artifact Registry. Substitua o marcador <image-name> pelo valor correto.
- id: "push"
name: 'gcr.io/cloud-builders/docker'
args: ['push', '<image-name>']
# TODO: #3. Executar uma verificação de vulnerabilidades. Substitua o marcador <image-name> pelo valor correto.
- id: scan
name: 'gcr.io/cloud-builders/gcloud'
entrypoint: 'bash'
args:
- '-c'
- |
(gcloud artifacts docker images scan \
<image-name> \
--location us \
--format="value(response.scan)") > /workspace/scan_id.txt
# TODO: #4. Analise o resultado da verificação. SE vulnerabilidades CRÍTICAS forem encontradas, a compilação vai falhar.
# Substitua os marcadores <correct vulnerability> pelos valores corretos. Diferencia maiúsculas de minúsculas!
- id: severity check
name: 'gcr.io/cloud-builders/gcloud'
entrypoint: 'bash'
args:
- '-c'
- |
gcloud artifacts docker images list-vulnerabilities $(cat /workspace/scan_id.txt) \
--format="value(vulnerability.effectiveSeverity)" | if grep -Fxq <correct vulnerability>; \
then echo "Failed vulnerability check for <correct vulnerability> level" && exit 1; else echo \
"No <correct vulnerability> vulnerability found, congrats !" && exit 0; fi
# TODO: #5. Assine a imagem somente se a verificação de gravidade anterior for aprovada.
# Substitua os marcadores de posição pelos valores corretos: <image-name>, <attestor-name> e <key-version>.
# Observe que <key-version> deve ser o caminho **completo** para a versão da chave.
- id: 'create-attestation'
name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest'
args:
- '--artifact-url'
- '<image-name>'
- '--attestor'
- '<attestor-name>'
- '--keyversion'
- '<key-version>'
# TODO: #6. Marque a imagem novamente para produção e envie-a para o repositório de produção usando a tag "latest".
# Substitua os marcadores <image-name> e <production-image-name> pelos valores corretos.
- id: "push-to-prod"
name: 'gcr.io/cloud-builders/docker'
args:
- 'tag'
- '<image-name>'
- '<production-image-name>'
- id: "push-to-prod-final"
name: 'gcr.io/cloud-builders/docker'
args: ['push', '<production-image-name>']
# TODO: #7. Implantar no Cloud Run. Substitua os marcadores <image-name> e <your-region> pelos valores corretos.
- id: 'deploy-to-cloud-run'
name: 'gcr.io/cloud-builders/gcloud'
entrypoint: 'bash'
args:
- '-c'
- |
gcloud run deploy auth-service --image=<image-name> \
--binary-authorization=default --region=<your-region> --allow-unauthenticated
# TODO: #8. Substitua o marcador <image-name> pelo valor da etapa de build.
images:
- <image-name>
-
Acione o build:
- Envie a configuração do Cloud Build que você criou para iniciar o processo de build.
- Preste atenção na região em que você está trabalhando ao enviar a build.
-
Observe a falha de build:
- Acesse a página de histórico do Cloud Build no console do Google Cloud.
- Procure a build que você acabou de acionar e examine o status dela.
- Confirme se o build falha devido à presença de uma vulnerabilidade de gravidade
CRÍTICA.
Observação:o build deve falhar devido a uma vulnerabilidade de gravidade CRÍTICA. Você vai resolver esse problema na próxima tarefa.
Para conferir o objetivo, clique em verificar meu progresso.
Integrar a verificação de vulnerabilidades ao pipeline de CI/CD.
Tarefa 5: Corrigir a vulnerabilidade e reimplantar o pipeline de CI/CD
Em um cenário real, as verificações de vulnerabilidade costumam revelar problemas que precisam ser resolvidos. Esta tarefa simula esse cenário, em que sua build falha devido a uma vulnerabilidade crítica. Nesta tarefa, você vai analisar a falha de build, identificar a vulnerabilidade e corrigi-la atualizando as dependências do aplicativo. Em seguida, você vai acionar novamente o pipeline do Cloud Build para garantir que o build seja concluído sem vulnerabilidades críticas.
-
Atualizar o Dockerfile:modifique o Dockerfile para usar a imagem de base python:3.8-alpine. Atualize as dependências Flask, Gunicorn e Werkzeug para as seguintes versões:
- Flask:
3.0.3
- Gunicorn:
23.0.0
- Werkzeug:
3.0.4
-
Acionar o build novamente: envie sua configuração atualizada do Cloud Build para iniciar um novo build.
-
Verificar o sucesso do build: confira a página "Histórico do Cloud Build" para confirmar se o build foi concluído sem problemas de vulnerabilidade CRÍTICA.
-
Para fins de teste, execute o comando a seguir para permitir o acesso não autenticado ao serviço do Cloud Run para que você possa validar a implantação. Substitua <your-region> pela região em que você implantou o serviço.
gcloud beta run services add-iam-policy-binding --region=<your-region> --member=allUsers --role=roles/run.invoker auth-service
Observação: este comando é apenas para fins de teste e não deve ser usado em um ambiente de produção.
-
Validar a implantação:acesse o URL do serviço Cloud Run para garantir que o aplicativo esteja implantado e funcionando corretamente.
Para conferir o objetivo, clique em verificar meu progresso.
Corrigir a vulnerabilidade e reimplantar o pipeline de CI/CD.
Parabéns!
Parabéns! Neste laboratório, você implementou com sucesso um pipeline CI/CD seguro que compila, verifica, assina e implanta uma aplicação web na nuvem. Essa experiência prática equipou você com habilidades essenciais para criar e implantar aplicativos seguros na nuvem, incorporar práticas recomendadas de segurança nos seus fluxos de trabalho de desenvolvimento e garantir a integridade do seu processo de entrega de software.

Próximas etapas/saiba mais
Confira recursos a seguir para saber mais sobre os tópicos deste laboratório:
Treinamento e certificação do Google Cloud
Esses treinamentos ajudam você a aproveitar as tecnologias do Google Cloud ao máximo. Nossas aulas incluem habilidades técnicas e práticas recomendadas para ajudar você a alcançar rapidamente o nível esperado e continuar sua jornada de aprendizado. Oferecemos treinamentos que vão do nível básico ao avançado, com opções de aulas virtuais, sob demanda e por meio de transmissões ao vivo para que você possa encaixá-las na correria do seu dia a dia. As certificações validam sua experiência e comprovam suas habilidades com as tecnologias do Google Cloud.
Manual atualizado em 10 de dezembro de 2025
Laboratório testado em 4 de setembro de 2024
Copyright 2026 Google LLC. Todos os direitos reservados. Google e o logotipo do Google são marcas registradas da Google LLC. Todos os outros nomes de produtos e empresas podem ser marcas registradas das respectivas empresas a que estão associados.