GSP1183

Visão geral

A autorização binária é um controle de segurança de tempo de implantação que garante que apenas imagens de contêineres confiáveis sejam implantadas no Google Kubernetes Engine (GKE) ou no Cloud Run. Com esse controle, é possível solicitar que todas as imagens sejam assinadas por autoridades confiáveis durante o processo de desenvolvimento e, depois disso, aplicar a validação da assinatura ao implantar. Ao aplicar a validação, você assume maior controle sobre o ambiente de contêineres e garante que apenas imagens verificadas sejam integradas ao processo de criação e lançamento.

O diagrama a seguir mostra os componentes em uma configuração de autorização binária/Cloud Build:

Pipeline do Cloud Build que cria um atestado de autorização binária.

Nesse pipeline:

1. O código para criar a imagem do contêiner é enviado para um repositório de origem, como o Cloud Source Repositories.
2. A ferramenta de integração contínua (CI, na sigla em inglês), o Cloud Build cria e testa o contêiner.
3. A criação envia a imagem do contêiner para o Container Registry ou outro registro que armazena as imagens criadas.
4. O Cloud Key Management Service, que fornece gerenciamento de chaves para o par de chaves criptográficas, assina a imagem do contêiner. Depois, a assinatura resultante é armazenada em um atestado recém-criado.
5. No momento da implantação, o atestador verifica o atestado usando a chave pública do par de chaves. A autorização binária aplica a política ao exigir atestados assinados para implantar a imagem do contêiner.

Neste laboratório, você vai aprender sobre as ferramentas e técnicas para proteger artefatos implantados. Este laboratório se concentra em artefatos (contêineres) depois que eles foram criados, mas não implantados em nenhum ambiente específico.

O que você vai aprender

• Assinatura de imagens
• Políticas de controle de admissão
• Assinatura de imagens digitalizadas
• Autorização de imagens assinadas
• Imagens não assinadas bloqueadas

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 é iniciado quando você clica em Começar o 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, 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 ou uma janela anônima do navegador. Isso evita conflitos entre sua conta pessoal e a conta de estudante, o que poderia causar cobranças extras na sua conta pessoal.

• Tempo para concluir o laboratório – não se esqueça: depois de começar, não será possível pausar o laboratório.

Observação: não use seu projeto ou conta do Google Cloud neste laboratório para evitar cobranças extras na sua conta.

Como iniciar seu laboratório e fazer login no console do Google Cloud

1. Clique no botão Começar o laboratório. Se for preciso pagar, você verá um pop-up para selecionar a forma de pagamento. No painel Detalhes do laboratório à esquerda, você vai encontrar o seguinte:

   • O botão Abrir console do Google Cloud
   • O tempo restante
   • As credenciais temporárias que você vai usar neste laboratório
   • Outras informações, se forem necessárias

2. Se você estiver usando o navegador Chrome, clique em Abrir console do Google Cloud ou clique com o botão direito do mouse e selecione Abrir link em uma janela anônima.

   O laboratório ativa os recursos e depois abre a página Fazer login em outra guia.

   Dica: coloque as guias em janelas separadas lado a lado.

   Observação: se aparecer a caixa de diálogo Escolher uma conta, clique em Usar outra conta.

3. Se necessário, copie o Nome de usuário abaixo e cole na caixa de diálogo Fazer login.

   {{{user_0.username | "Nome de usuário"}}}

   Você também encontra o Nome de usuário no painel Detalhes do laboratório.

4. Clique em Avançar.

5. Copie a Senha abaixo e cole na caixa de diálogo de boas-vindas.

   {{{user_0.password | "Senha"}}}

   Você também encontra a Senha no painel Detalhes do laboratório.

6. Clique em Seguinte.

   Importante: você precisa usar as credenciais fornecidas no laboratório, e não as da sua conta do Google Cloud. Observação: se você usar sua própria conta do Google Cloud neste laboratório, é possível que receba cobranças adicionais.

7. Acesse as próximas páginas:

   • Aceite os Termos e Condições.
   • Não adicione opções de recuperação nem autenticação de dois fatores (porque essa é uma conta temporária).
   • Não se inscreva em testes sem custo financeiro.

Depois de alguns instantes, o console do Google Cloud será aberto nesta guia.

Observação: clique em Menu de navegação no canto superior esquerdo para acessar uma lista de produtos e serviços do Google Cloud.

Ativar o Cloud Shell

O Cloud Shell é uma máquina virtual com várias ferramentas de desenvolvimento. Ele tem um diretório principal permanente de 5 GB e é executado no Google Cloud. O Cloud Shell oferece acesso de linha de comando aos recursos do Google Cloud.

1. Clique em Ativar o Cloud Shell na parte de cima do console do Google Cloud.

Depois de se conectar, você verá que sua conta já está autenticada e que o projeto está configurado com seu Project_ID, . A saída contém uma linha que declara o projeto PROJECT_ID para esta sessão:

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

A gcloud é a ferramenta de linha de comando do Google Cloud. Ela vem pré-instalada no Cloud Shell e aceita preenchimento com tabulação.

2. (Opcional) É possível listar o nome da conta ativa usando este comando:

gcloud auth list

3. Clique em Autorizar.

Saída:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

4. (Opcional) É possível listar o ID do projeto usando este comando:

gcloud config list project

Saída:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} Observação: consulte a documentação completa da gcloud no Google Cloud no guia de visão geral da gcloud CLI.

Configuração do ambiente

No Cloud Shell, defina o ID e o número do projeto. Salve-os como as variáveis PROJECT_ID e PROJECT_NUMBER.

export PROJECT_ID=$(gcloud config get-value project) export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \ --format='value(projectNumber)')

Ativar serviços

Ative todos os serviços necessários:

gcloud services enable \ cloudkms.googleapis.com \ cloudbuild.googleapis.com \ container.googleapis.com \ containerregistry.googleapis.com \ artifactregistry.googleapis.com \ containerscanning.googleapis.com \ ondemandscanning.googleapis.com \ binaryauthorization.googleapis.com

Tarefa 1: criar um repositório do Artifact Registry

Neste laboratório, você vai usar o Artifact Registry para armazenar e verificar suas imagens.

1. Crie o repositório com o seguinte comando:

gcloud artifacts repositories create artifact-scanning-repo \ --repository-format=docker \ --location={{{ project_0.default_region | "REGION" }}} \ --description="Docker repository"

2. Configure o Docker para usar suas credenciais do gcloud ao acessar o Artifact Registry:

gcloud auth configure-docker {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev

3. Crie e acesse um diretório de trabalho:

mkdir vuln-scan && cd vuln-scan

4. Em seguida, defina uma imagem de amostra. Crie um arquivo chamado Dockerfile com o seguinte conteúdo:

cat > ./Dockerfile << EOF FROM python:3.8-alpine # App WORKDIR /app COPY . ./ RUN pip3 install Flask==2.1.0 RUN pip3 install gunicorn==20.1.0 RUN pip3 install Werkzeug==2.2.2 CMD exec gunicorn --bind :\$PORT --workers 1 --threads 8 main:app EOF

5. Crie um arquivo chamado main.py com o seguinte conteúdo:

cat > ./main.py << EOF import os from flask import Flask app = Flask(__name__) @app.route("/") def hello_world(): name = os.environ.get("NAME", "Worlds") return "Hello {}!".format(name) if __name__ == "__main__": app.run(debug=True, host="0.0.0.0", port=int(os.environ.get("PORT", 8080))) EOF

6. Use o Cloud Build para criar e enviar automaticamente seu contêiner para o Artifact Registry.

gcloud builds submit . -t {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image

Clique em Verificar meu progresso para conferir o objetivo. Criar um repositório do Artifact Registry.

Tarefa 2: assinatura de imagens

O que é um atestador

• Essa pessoa/processo é responsável por um elo na cadeia de confiança do sistema.
• O atestador tem uma chave criptográfica e assina uma imagem se ela passar pelo processo de aprovação.
• O criador de políticas determina a política de forma abstrata e de alto nível, enquanto o atestador é responsável por aplicar concretamente algum aspecto da política.
• O atestador pode ser uma pessoa real, como um testador de controle de qualidade ou um gerente, ou um bot em um sistema de CI.
• A segurança do sistema depende da confiabilidade dele, por isso é importante que as chaves privadas sejam mantidas em segurança.

Cada um desses papéis pode representar uma pessoa ou uma equipe na sua organização. Em um ambiente de produção, esses papéis provavelmente seriam gerenciados por projetos separados do Google Cloud Platform, e o acesso aos recursos seria compartilhado entre eles de forma limitada usando o Cloud IAM.

Os atestadores na Autorização Binária são implementados na API Cloud Container Analysis, por isso é importante descrever como isso funciona antes de prosseguir. A API Container Analysis foi projetada para permitir que você associe metadados a imagens de contêiner específicas.

Por exemplo, uma nota pode ser criada para rastrear a vulnerabilidade Heartbleed. Os fornecedores de segurança criariam verificadores para testar as imagens de contêiner em busca da vulnerabilidade e criariam uma ocorrência associada a cada contêiner comprometido.

Além de rastrear vulnerabilidades, o Container Analysis foi projetado para ser uma API de metadados genérica. A autorização binária usa o Container Analysis para associar assinaturas às imagens de contêiner que estão sendo verificadas. Uma nota do Container Analysis é usada para representar um único atestador, e as ocorrências são criadas e associadas a cada contêiner que o atestador aprovou.

A API Binary Authorization usa os conceitos de "atestadores" e "atestados", mas eles são implementados usando as observações e ocorrências correspondentes na API Container Analysis.

Criar uma nota de atestador

Uma nota de atestador é simplesmente um pequeno conjunto de dados que funciona como um rótulo para o tipo de assinatura que está sendo aplicado. Por exemplo, uma nota pode indicar uma verificação de vulnerabilidade, enquanto outra pode ser usada para aprovação de QA. A nota será referida durante o processo de assinatura.

1. Crie uma nota:

cat > ./vulnz_note.json << EOM { "attestation": { "hint": { "human_readable_name": "Container Vulnerabilities attestation authority" } } } EOM

2. Armazene a nota

NOTE_ID=vulnz_note curl -vvv -X POST \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ --data-binary @./vulnz_note.json \ "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=${NOTE_ID}"

3. Verifique a nota

curl -vvv \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}"

Sua nota agora está salva na API Container Analysis.

4. Como criar um atestador

Os atestadores são usados para realizar o processo real de assinatura de imagem e anexarão uma ocorrência da nota à imagem para verificação posterior. Para usar o atestador, você também precisa registrar a nota na Autorização Binária:

5. Criar atestador

ATTESTOR_ID=vulnz-attestor gcloud container binauthz attestors create $ATTESTOR_ID \ --attestation-authority-note=$NOTE_ID \ --attestation-authority-note-project=${PROJECT_ID}

6. Verificar atestador

gcloud container binauthz attestors list

A última linha indica NUM_PUBLIC_KEYS: 0. Você vai fornecer as chaves em uma etapa posterior.

O Cloud Build cria automaticamente o atestador built-by-cloud-build no seu projeto quando você executa um build que gera imagens. O comando acima retorna dois atestadores: vulnz-attestor e built-by-cloud-build. Depois que as imagens são criadas, o Cloud Build assina e cria atestados automaticamente.

7. A conta de serviço da Autorização Binária precisa ter direitos para visualizar as anotações de atestado. Forneça o acesso ao papel do IAM com a seguinte chamada de API:

PROJECT_NUMBER=$(gcloud projects describe "${PROJECT_ID}" --format="value(projectNumber)") BINAUTHZ_SA_EMAIL="service-${PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com" cat > ./iam_request.json << EOM { 'resource': 'projects/${PROJECT_ID}/notes/${NOTE_ID}', 'policy': { 'bindings': [ { 'role': 'roles/containeranalysis.notes.occurrences.viewer', 'members': [ 'serviceAccount:${BINAUTHZ_SA_EMAIL}' ] } ] } } EOM

8. Use o arquivo para criar a política do IAM:

curl -X POST \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ --data-binary @./iam_request.json \ "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}:setIamPolicy"

Clique em Verificar meu progresso para conferir o objetivo. Criar um atestador.

Tarefa 3: adicionar uma chave do KMS

Antes de usar esse atestador, sua autoridade precisa criar um par de chaves criptográficas que possa ser usado para assinar imagens de contêiner. Isso pode ser feito com o Google Cloud Key Management Service (KMS).

1. Primeiro, adicione algumas variáveis de ambiente para descrever a nova chave:

KEY_LOCATION=global KEYRING=binauthz-keys KEY_NAME=codelab-key KEY_VERSION=1

2. Crie um keyring para armazenar um conjunto de chaves:

gcloud kms keyrings create "${KEYRING}" --location="${KEY_LOCATION}"

3. Crie um novo par de chaves de assinatura assimétricas para o atestador

gcloud kms keys create "${KEY_NAME}" \ --keyring="${KEYRING}" --location="${KEY_LOCATION}" \ --purpose asymmetric-signing \ --default-algorithm="ec-sign-p256-sha256"

A chave vai aparecer na página do KMS no console do Cloud.

4. Agora, associe a chave ao atestador usando o comando binauthz do gcloud:

gcloud beta container binauthz attestors public-keys add \ --attestor="${ATTESTOR_ID}" \ --keyversion-project="${PROJECT_ID}" \ --keyversion-location="${KEY_LOCATION}" \ --keyversion-keyring="${KEYRING}" \ --keyversion-key="${KEY_NAME}" \ --keyversion="${KEY_VERSION}"

5. Se você exibir a lista de autoridades novamente, verá uma chave registrada:

gcloud container binauthz attestors list

Clique em Verificar meu progresso para conferir o objetivo. Adicionar uma chave do KMS.

Tarefa 4: como criar um atestado assinado

Neste ponto, você já configurou os recursos que permitem assinar imagens. Use o atestador que você criou anteriormente para assinar a imagem de contêiner com a qual você tem trabalhado.

Um atestado precisa incluir uma assinatura criptográfica para declarar que o atestador verificou uma imagem de contêiner específica e que ela é segura para ser executada no cluster.

1. Para especificar qual imagem de contêiner atestar, execute o seguinte para determinar o resumo dela:

CONTAINER_PATH={{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:latest \ --format='get(image_summary.digest)')

2. Agora você pode usar a gcloud para criar sua atestação. O comando recebe os detalhes da chave que você quer usar para assinar e a imagem de contêiner específica que você quer aprovar:

gcloud beta container binauthz attestations sign-and-create \ --artifact-url="${CONTAINER_PATH}@${DIGEST}" \ --attestor="${ATTESTOR_ID}" \ --attestor-project="${PROJECT_ID}" \ --keyversion-project="${PROJECT_ID}" \ --keyversion-location="${KEY_LOCATION}" \ --keyversion-keyring="${KEYRING}" \ --keyversion-key="${KEY_NAME}" \ --keyversion="${KEY_VERSION}"

Em termos de Container Analysis, isso vai criar uma nova ocorrência e anexá-la à nota do seu atestador.

3. Para garantir que tudo funcionou como esperado, execute o seguinte para listar suas atestações:

gcloud container binauthz attestations list \ --attestor=$ATTESTOR_ID --attestor-project=${PROJECT_ID}

Tarefa 5: políticas de controle de admissão

A Autorização Binária é um recurso do GKE e do Cloud Run que permite validar regras antes que uma imagem de contêiner possa ser executada. A validação é executada em qualquer solicitação para executar uma imagem, seja de um pipeline de CI/CD confiável ou de um usuário tentando implantar uma imagem manualmente. Com esse recurso, você protege seus ambientes de execução de forma mais eficaz do que apenas verificações de pipeline de CI/CD.

Para entender essa capacidade, você vai modificar a política padrão do GKE para aplicar uma regra de autorização rigorosa.

1. Criar um cluster (GKE) com a Autorização Binária ativada:

gcloud beta container clusters create binauthz \ --zone {{{ project_0.default_zone | "ZONE" }}} \ --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE

2. Permita que o Cloud Build faça a implantação nesse cluster:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \ --role="roles/container.developer"

Política "Permitir tudo"

Primeiro, verifique o estado da política padrão e sua capacidade de implantar qualquer imagem

1. Analisar a política atual:

gcloud container binauthz policy export

2. Observe que a política de aplicação está definida como ALWAYS_ALLOW

evaluationMode: ALWAYS_ALLOW

3. Implante a amostra para verificar se é possível implantar alguma coisa:

kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080

4. Verifique se a implantação funcionou:

kubectl get pods

A saída a seguir vai aparecer:

5. Exclua a implantação:

kubectl delete pod hello-server

Política "Negar tudo"

Agora atualize a política para proibir todas as imagens.

1. Exporte a política atual para um arquivo editável:

gcloud container binauthz policy export > policy.yaml

2. Em um editor de texto, abra o arquivo policy.yaml' e altere o evaluationMode de `ALWAYS_ALLOW para ALWAYS_DENY:

edit policy.yaml

Verifique se o arquivo YAML da política editada aparece da seguinte maneira:

globalPolicyEvaluationMode: ENABLE defaultAdmissionRule: evaluationMode: ALWAYS_DENY enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG name: projects/PROJECT_ID/policy

Essa política é relativamente simples. A linha globalPolicyEvaluationMode declara que esta política estende a política global definida pelo Google. Isso permite que todos os contêineres oficiais do GKE sejam executados por padrão. Além disso, a política declara uma defaultAdmissionRule que afirma que todos os outros pods serão rejeitados. A regra de admissão inclui uma linha enforcementMode, que declara que todos os pods que não estiverem em conformidade com essa regra devem ser impedidos de serem executados no cluster.

Para instruções sobre como criar políticas mais complexas, consulte a documentação da Autorização Binária.

3. No Cloud Shell, execute o seguinte para aplicar a nova política:

gcloud container binauthz policy import policy.yaml

Aguarde alguns segundos para que a alteração seja propagada.

4. Tente implantar uma carga de trabalho de amostra:

kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080

5. A implantação falha com a seguinte mensagem:

Error from server (VIOLATES_POLICY): admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image gcr.io/google-samples/hello-app:1.0 denied by Binary Authorization default admission rule. Denied by always_deny admission rule

Reverter a política para permitir tudo

Antes de passar para a próxima seção, reverta as mudanças na política.

1. Em um editor de texto, altere o evaluationMode de ALWAYS_DENY para ALWAYS_ALLOW.

edit policy.yaml

O arquivo YAML da política editada será exibido da seguinte maneira:

globalPolicyEvaluationMode: ENABLE defaultAdmissionRule: evaluationMode: ALWAYS_ALLOW enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG name: projects/PROJECT_ID/policy

2. Aplique a política revertida:

gcloud container binauthz policy import policy.yaml

Clique em Verificar meu progresso para conferir o objetivo. Criar um cluster do GKE e atualizar as políticas.

Tarefa 6: assinatura automática de imagens

Você ativou a assinatura de imagens e usou o atestador manualmente para assinar sua imagem de amostra. Na prática, você precisa aplicar atestações durante processos automatizados, como pipelines de CI/CD.

Nesta seção, você vai configurar o Cloud Build para atestar imagens automaticamente.

Papéis necessários

1. Adicione o papel Visualizador de atestador de autorização binária à conta de serviço do Cloud Build:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \ --role roles/binaryauthorization.attestorsViewer

2. Adicione o papel Signatário/Verificador de CryptoKey do Cloud KMS à conta de serviço do Cloud Build (assinatura baseada em KMS):

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \ --role roles/cloudkms.signerVerifier gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member serviceAccount:${PROJECT_NUMBER}-compute@developer.gserviceaccount.com \ --role roles/cloudkms.signerVerifier

3. Adicione o papel Anexador de notas do Container Analysis à conta de serviço do Cloud Build:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \ --role roles/containeranalysis.notes.attacher

Fornecer acesso à conta de serviço do Cloud Build

O Cloud Build vai precisar de direitos para acessar a API On-Demand Scanning.

• Forneça acesso com os seguintes comandos:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \ --role="roles/iam.serviceAccountUser" gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \ --role="roles/ondemandscanning.admin"

Preparar a etapa de versão personalizada do Cloud Build

Você vai usar uma etapa de versão personalizada no Cloud Build para simplificar o processo de atestado. O Google fornece essa etapa do build personalizado, contendo mais funções auxiliares para simplificar o processo. Antes do uso, o código da etapa de versão personalizada precisa ser integrado a um contêiner e enviado ao Cloud Build.

• Para fazer isso, execute os seguintes comandos:

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

Adicionar uma etapa de assinatura ao seu cloudbuild.yaml

Adicione a etapa de atestado ao seu pipeline do Cloud Build.

1. Confira a etapa de assinatura abaixo.

Apenas revisão. Não copiar

#Sign the image only if the previous severity check passes - id: 'create-attestation' name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest' args: - '--artifact-url' - '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image' - '--attestor' - 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID' - '--keyversion' - 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION'

2. Escreva um arquivo cloudbuild.yaml com o pipeline completo abaixo:

cat > ./cloudbuild.yaml << EOF steps: # build - id: "build" name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '.'] waitFor: ['-'] # additional CICD checks (not shown) #Retag - id: "retag" name: 'gcr.io/cloud-builders/docker' args: ['tag', '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good'] #pushing to artifact registry - id: "push" name: 'gcr.io/cloud-builders/docker' args: ['push', '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good'] #Sign the image only if the previous severity check passes - id: 'create-attestation' name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest' args: - '--artifact-url' - '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good' - '--attestor' - 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID' - '--keyversion' - 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION' images: - {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good EOF

3. Execute o build

gcloud builds submit

Analisar o build no histórico do Cloud Build

No console do Cloud, acesse a página Cloud Build > Histórico de builds e confira o build mais recente e a execução bem-sucedida das etapas de build.

Clique em Verificar meu progresso para conferir o objetivo. Adicionar uma etapa de assinatura.

Tarefa 7: autorização de imagens assinadas

Agora você vai atualizar o GKE para usar a autorização binária para validar se a imagem tem uma assinatura da verificação de vulnerabilidades antes de permitir que ela seja executada.

Atualizar a política do GKE para exigir atestado

Exigir que as imagens sejam assinadas pelo seu atestador adicionando clusterAdmissionRules à sua política BinAuth do GKE

Atualmente, seu cluster está executando uma política com uma regra: permitir contêineres de repositórios oficiais e rejeitar todos os outros.

1. Substitua a política pela configuração atualizada usando o comando abaixo:

COMPUTE_ZONE={{{ project_0.default_region | "REGION" }}} cat > binauth_policy.yaml << EOM defaultAdmissionRule: enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG evaluationMode: REQUIRE_ATTESTATION requireAttestationsBy: - projects/${PROJECT_ID}/attestors/vulnz-attestor globalPolicyEvaluationMode: ENABLE clusterAdmissionRules: ${COMPUTE_ZONE}.binauthz: evaluationMode: REQUIRE_ATTESTATION enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG requireAttestationsBy: - projects/${PROJECT_ID}/attestors/vulnz-attestor EOM

2. Agora você tem um novo arquivo no disco chamado updated_policy.yaml. Agora, em vez de rejeitar todas as imagens, a regra padrão primeiro verifica seu atestador em busca de verificações.

3. Faça upload da nova política para a Autorização Binária:

gcloud beta container binauthz policy import binauth_policy.yaml

Implantar uma imagem assinada

1. Receba o resumo da imagem boa:

CONTAINER_PATH={{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:good \ --format='get(image_summary.digest)')

2. Use o resumo na configuração do Kubernetes:

cat > deploy.yaml << EOM apiVersion: v1 kind: Service metadata: name: deb-httpd spec: selector: app: deb-httpd ports: - protocol: TCP port: 80 targetPort: 8080 --- apiVersion: apps/v1 kind: Deployment metadata: name: deb-httpd spec: replicas: 1 selector: matchLabels: app: deb-httpd template: metadata: labels: app: deb-httpd spec: containers: - name: deb-httpd image: ${CONTAINER_PATH}@${DIGEST} ports: - containerPort: 8080 env: - name: PORT value: "8080" EOM

3. Implantar o aplicativo no GKE

kubectl apply -f deploy.yaml

No console do Cloud, acesse Kubernetes Engine > Cargas de trabalho e confira a implantação bem-sucedida da imagem.

Clique em Verificar meu progresso para conferir o objetivo. Implantar uma imagem assinada.

Tarefa 8: imagens não assinadas bloqueadas

Criar uma imagem

1. Use o Docker local para criar a imagem no cache local:

docker build -t {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad .

2. Envie a imagem não assinada para o repositório:

docker push {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad

3. Receba o resumo da imagem inadequada:

CONTAINER_PATH={{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:bad \ --format='get(image_summary.digest)')

4. Use o resumo na configuração do Kubernetes:

cat > deploy.yaml << EOM apiVersion: v1 kind: Service metadata: name: deb-httpd spec: selector: app: deb-httpd ports: - protocol: TCP port: 80 targetPort: 8080 --- apiVersion: apps/v1 kind: Deployment metadata: name: deb-httpd spec: replicas: 1 selector: matchLabels: app: deb-httpd template: metadata: labels: app: deb-httpd spec: containers: - name: deb-httpd image: ${CONTAINER_PATH}@${DIGEST} ports: - containerPort: 8080 env: - name: PORT value: "8080" EOM

5. Tente implantar o app no GKE

kubectl apply -f deploy.yaml

Analise a carga de trabalho no console e observe o erro que indica que a implantação foi negada:

No attestations found that were valid and signed by a key trusted by the attestor

Clique em Verificar meu progresso para conferir o objetivo. Implantar uma imagem não assinada.

Parabéns!

Você aprendeu a criar um atestador para assinar imagens e validar regras antes que uma imagem de contêiner possa ser executada. Você aprendeu a escrever uma política para informar ao Cloud Build se ele deve permitir ou negar o acesso ao cluster do GKE. Também usou a Autorização Binária com o Google Cloud KMS para validar assinaturas de imagens e impedir que imagens não assinadas acessem o cluster do Kubernetes.

Próximas etapas / Saiba mais

• Como proteger implantações de imagens no Cloud Run e no Google Kubernetes Engine | Documentação do Cloud Build
• Guia de início rápido: configurar uma política de autorização binária com o GKE | Google Cloud

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, on demand 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 setembro de 2024

Laboratório testado em 11 de julho de 2024

Copyright 2024 Google LLC. Todos os direitos reservados. Google e o logotipo do Google são marcas registradas da Google LLC. Todos os outros nomes de empresas e produtos podem ser marcas registradas das empresas a que estão associados.