Primeiros passos no Console do Google Cloud (GKE)

Neste tutorial, mostramos como configurar e testar uma política de autorização binária que requer atestados. Esse tipo de política protege sua cadeia de suprimentos de software baseada em contêiner definindo quem pode implantar imagens de contêiner no Google Kubernetes Engine (GKE) e quais imagens de contêiner o GKE tem permissão para implantar.

No momento da implantação, a autorização binária usa atestadores para verificar assinaturas digitais em atestados. Os atestados foram criados por signatários como parte do processo de criação.

Neste tutorial, o cluster do GKE, os atestados e os atestadores estão localizados em um único projeto. Uma configuração de projeto único é muito útil para testar ou testar o serviço. Para ver um exemplo mais real, consulte configuração de vários projetos.

Nas etapas abaixo, descrevemos as tarefas realizadas no Console do Google Cloud, bem como algumas que você executa usando comandos gcloud. Para executar essas etapas usando gcloud, consulte Primeiros passos com a Google Cloud CLI.

Objetivos

Neste tutorial, você aprenderá a realizar as seguintes tarefas:

Criar um cluster (GKE) com a autorização binária ativada
Criar um atestador que o aplicador de autorização binária usa para verificar a assinatura em um atestado
Configurar uma política que exija um atestado
Criar um par de chaves criptográficas para assinar atestados e depois verificá-los
Assinar um resumo de imagem de contêiner, criando uma assinatura
Criar um atestado usando a assinatura
Testar a política implantando uma imagem de contêiner no GKE

Custos

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

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

Antes de começar

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.

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

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

Ative as APIs Container Registry, Artifact Analysis and Binary Authorization.

Ative as APIs

Instale a CLI do Google Cloud.

Para inicializar a CLI gcloud, execute o seguinte comando:

gcloud init

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

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

Ative as APIs Container Registry, Artifact Analysis and Binary Authorization.

Ative as APIs

Instale a CLI do Google Cloud.

Para inicializar a CLI gcloud, execute o seguinte comando:

gcloud init

Instale kubectl.

Definir o projeto padrão

Para facilitar os comandos a seguir, armazene o ID do projeto do Google Cloud em uma variável de ambiente da seguinte maneira:

PROJECT_ID=PROJECT_ID

PROJECT_ID é o nome do projeto.

Se o projeto padrão não estiver selecionado, defina-o agora:

gcloud config set project ${PROJECT_ID}

Criar um cluster com a autorização binária ativada

Criar o cluster

Agora você pode criar um cluster do GKE com a autorização binária ativada. Aqui, você cria um cluster chamado test-cluster na zona us-central1-a do GKE.

Para criar o cluster, siga estas etapas:

Acesse o menu do GKE no Console do Google Cloud.

Acessar o GKE
Clique em Criar cluster.
Insira test-cluster no campo Nome.
Selecione Zonal nas opções de Tipo de local.
Selecione us-central1-a na lista suspensa Zona.
Clique em Disponibilidade, rede, segurança e outros recursos.
Na seção Segurança, selecione Ativar autorização binária.
Selecione Aplicar somente.
Clique em Criar.

Configurar `kubectl`

Também é necessário atualizar o arquivo kubeconfig local para a instalação do kubectl. Isso fornece as credenciais e as informações de endpoint necessárias para acessar o cluster no GKE.

Para atualizar o arquivo kubeconfig local, siga estas etapas:

gcloud container clusters get-credentials \
    --zone us-central1-a \
    test-cluster

Ver a política padrão

Uma política na autorização binária é um conjunto de regras que regem a implantação de imagens de contêiner. Você pode ter uma política por projeto. Por padrão, a política é configurada para permitir a implantação de todas as imagens de contêiner.

Para ver a política padrão, siga estas etapas:

Acesse a página "Autorização binária" no Console do Google Cloud.

Acesse Autorização binária
Clique em Editar política.
Em Regra padrão do projeto, a opção Permitir todas as imagens é exibida.
Clique em Save Policy.

Crie um atestador

Um atestador é a autoridade de verificação que o aplicador de autorização binária usa no momento da implantação para decidir se o GKE implantará a imagem do contêiner assinado correspondente. O atestador contém a chave pública e normalmente é gerenciado por pessoas responsáveis pela segurança da cadeia de suprimentos de software.

Para criar um atestador, você precisa:

Criar o próprio atestador na autorização binária
Gerar automaticamente uma nota do atestado associado no Artifact Analysis para armazenar metadados de atestado confiáveis usados no processo de autorização

Neste tutorial, você tem um atestador chamado test-attestor. Em um cenário real, você pode ter qualquer número de atestadores, cada um representando uma parte que participa do processo de autorização da imagem.

Gerar um par de chaves

A autorização binária usa chaves criptográficas para verificar com segurança a identidade dos assinantes. Isso garante que somente imagens de contêiner autorizadas possam ser implantadas. O par de chaves consiste em uma chave privada e uma chave pública. O signer usa a chave privada para assinar o resumo da imagem do contêiner, produzindo uma assinatura que é armazenada em um atestado. A chave pública é armazenada no atestador. No momento da implantação, o implementador de autorização binária usa a chave pública do atestador para verificar a assinatura no atestado antes de permitir a implantação do contêiner.

Neste tutorial, você usará o formato Public-Key Infrastructure (X.509) (PKIX) para chaves criptográficas. Este tutorial usa o Algoritmo de assinatura digital de curva elíptica (ECDSA, na sigla em inglês) recomendado para gerar um par de chaves PKIX. Também é possível usar chaves RSA ou PGP para assinatura. Consulte Principais finalidades e algoritmos para mais informações sobre algoritmos de assinatura.

As chaves geradas e armazenadas pelo Cloud Key Management Service (Cloud KMS) são compatíveis com o PKIX. Consulte Como criar atestadores usando a CLI para mais informações sobre o uso de chaves PKIX e do Cloud KMS.

Para gerar um par de chaves PKIX, faça o seguinte:

Crie a chave privada:

PRIVATE_KEY_FILE="/tmp/ec_private.pem"
openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}

Extraia a chave pública da chave privada:

PUBLIC_KEY_FILE="/tmp/ec_public.pem"
openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}

Crie o atestador

Agora você pode criar o próprio atestador na autorização binária e associar a chave pública que você criou.

Para criar o atestador, faça o seguinte:

Retorne à página "Autorização binária" no Console do Google Cloud.

Retorne para Autorização binária
Na guia Atestadores, clique em Criar.
Preencha os campos da seguinte forma:
1. Digite test-attestor no campo Nome do atestador.
2. Verifique se a opção Criar automaticamente uma nota do Artifact Analysis está marcada.
3. Clique em Adicionar uma chave pública PKIX.
4. Abra /tmp/ec_public.pem em um editor de texto. Esse é o arquivo de chave pública criado na etapa anterior. Copie o conteúdo do arquivo para a caixa de texto Material da chave pública.
5. Clique em Elliptic Curve P-256 - SHA256 Digest no menu suspenso Algoritmo de assinatura.
6. Clique em Concluído.
Clique em Create para criar o atestador.
Armazene o ID da chave pública.

Para ver o ID da chave pública do atestador depois de adicioná-lo ao atestador, use gcloud container binauthz attestors describe ${ATTESTOR_NAME}: Para criar uma variável de ambiente para armazenar o ID da chave pública, execute este comando:
```
ATTESTOR_NAME=test-attestor
PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME}\
  --format='value(userOwnedGrafeasNote.publicKeys[0].id)')
```

Configurar a política

Agora, você pode configurar sua política:

Volte para a página "Autorização binária" no Console do Google Cloud.
Na guia Política, clique em Editar política.
Selecione Permitir apenas imagens que foram aprovadas pelos seguintes atestadores.
Clique em Adicionar atestadores.
Clique em Adicionar por projeto e nome do atestador.
Digite PROJECT_ID no campo Nome do projeto.
Digite test-attestor no campo Nome do atestador.
Clique em Adicionar um atestador.
Clique em Save Policy.

Para mais informações, consulte Como configurar uma política usando o Console.

Testar a política

Para testar a política configurada acima, tente implantar uma imagem de contêiner de amostra no cluster. A política bloqueará a implantação porque o atestado necessário não foi feito.

Neste tutorial, é possível usar imagens de amostra do Container Registry e do Artifact Registry. A imagem do Container Registry está localizada no caminho gcr.io/google-samples/hello-app:1.0. A imagem do Artifact Registry está localizada no caminho us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0. Os dois caminhos contêm imagem pública criada pelo Google que contém um aplicativo de amostra "Hello, World!".

Para tentar implantar a imagem, execute o seguinte comando:

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

Agora verifique se a implantação foi bloqueada pela autorização binária:

kubectl get pods

O comando imprime a seguinte mensagem, que indica que a imagem não foi implantada:

No resources found.

Veja mais detalhes sobre a implantação:

kubectl get event --template \
'{{range.items}}{{"\033[0;36m"}}{{.reason}}:{{"\033[0m"}}\{{.message}}{{"\n"}}{{end}}'

Você verá uma resposta semelhante a esta:

FailedCreate: Error creating: pods POD_NAME is forbidden: admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image IMAGE_NAME denied by Binary Authorization default admission rule. Image IMAGE_NAME denied by ATTESTOR_NAME: No attestations found

Nesta saída:

POD_NAME: o nome do pod.
IMAGE_NAME: o nome da imagem.
ATTESTOR_NAME: o nome do atestador.

Exclua a implantação para seguir para a próxima etapa:

kubectl delete deployment hello-server

Criar um atestado

Um atestado é um documento digital criado por um signatário que certifica que o GKE tem permissão para implantar a imagem de contêiner associada. O processo de criação de um atestado às vezes é chamado de "assinatura de imagem".

Neste tutorial, você criará um atestado para imagens de exemplo no Container Registry e no Artifact Registry.

Para criar um atestado, faça o seguinte:

Defina as variáveis que armazenam o caminho do registro e o resumo da imagem, além do nome do atestador:

Container Registry

IMAGE_PATH="gcr.io/google-samples/hello-app"
IMAGE_DIGEST="sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4"
ATTESTOR="test-attestor"
IMAGE_TO_ATTEST=${IMAGE_PATH}@${IMAGE_DIGEST}

Artifact Registry

IMAGE_PATH="us-docker.pkg.dev/google-samples/containers/gke/hello-app"
IMAGE_DIGEST="sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567"
ATTESTOR="test-attestor"
IMAGE_TO_ATTEST=${IMAGE_PATH}@${IMAGE_DIGEST}

Gere o payload do atestado:

Container Registry

gcloud container binauthz create-signature-payload \
--artifact-url=${IMAGE_PATH}@${IMAGE_DIGEST} > /tmp/generated_payload.json

O arquivo JSON de payload tem o seguinte conteúdo:

{
"critical": {
  "identity": {
    "docker-reference": "gcr.io/google-samples/hello-app"
  },
  "image": {
    "docker-manifest-digest": "sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea
882eb722c3be4"
  },
  "type": "Google cloud binauthz container signature"
}
}

Artifact Registry

gcloud container binauthz create-signature-payload \
--artifact-url=${IMAGE_PATH}@${IMAGE_DIGEST} > /tmp/generated_payload.json

O arquivo JSON de payload tem o seguinte conteúdo:

{
"critical": {
  "identity": {
    "docker-reference": "us-docker.pkg.dev/google-samples/containers/gke/hello-app"
  },
  "image": {
    "docker-manifest-digest": "sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567"
  },
  "type": "Google cloud binauthz container signature"
}
}

Assine o payload com a chave privada PKIX e gere um arquivo de assinatura:
```
openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature
```
O arquivo de assinatura é uma versão assinada digitalmente do payload JSON criado acima.

Crie e valide o atestado:

gcloud container binauthz attestations create \
    --project="${PROJECT_ID}" \
    --artifact-url="${IMAGE_TO_ATTEST}" \
    --attestor="projects/${PROJECT_ID}/attestors/${ATTESTOR_NAME}" \
    --signature-file=/tmp/ec_signature \
    --public-key-id="${PUBLIC_KEY_ID}" \
    --validate

em que PUBLIC_KEY_ID é o ID da chave pública que você encontrou em Gerar um par de chaves PKIX acima.

A sinalização validate verifica se o atestado pode ser verificado pelo atestador que você configurou na política.

Verifique se o atestado foi criado:

gcloud container binauthz attestations list \
    --attestor=$ATTESTOR_NAME --attestor-project=$PROJECT_ID

Para mais informações sobre como criar atestados, consulte Como criar atestados.

Testar a política outra vez

Novamente, teste a política implantando uma imagem de contêiner de amostra no cluster. Desta vez, implante a imagem usando o resumo em vez de uma tag como 1.0 ou latest, já que a autorização binária usará o caminho e o resumo da imagem para procurar atestados. Aqui, a autorização binária permite que a imagem seja implantada porque o atestado necessário foi feito.

Para implantar a imagem, execute o comando a seguir.

kubectl run hello-server --image ${IMAGE_PATH}@${IMAGE_DIGEST} --port 8080

Para verificar se a imagem foi implantada, execute o comando abaixo:

kubectl get pods

O comando imprime uma mensagem semelhante à seguinte, que indica que a implantação foi bem-sucedida:

NAME                            READY     STATUS    RESTARTS   AGE
hello-server-579859fb5b-h2k8s   1/1       Running   0          1m

Para excluir o pod, execute o seguinte comando:

kubectl delete pod hello-server

Limpar

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 cluster que você criou no GKE:

gcloud container clusters delete \
    --zone=us-central1-a \
    test-cluster

A seguir

Saiba mais sobre Autorização binária
Conheça os principais conceitos usados na autorização binária
Use o atestador built-by-cloud-build para implantar somente imagens criadas pelo Cloud Build (visualização).
Saiba como usar resumos de imagem nos manifestos do Kubernetes
Ativar o modo de simulação para desativar a aplicação

Primeiros passos no Console do Google Cloud (GKE)

Objetivos

Custos

Antes de começar

Definir o projeto padrão

Criar um cluster com a autorização binária ativada

Criar o cluster

Configurar kubectl

Ver a política padrão

Crie um atestador

Gerar um par de chaves

Crie o atestador

Configurar a política

Testar a política

Criar um atestado

Container Registry

Artifact Registry

Container Registry

Artifact Registry

Testar a política outra vez

Limpar

A seguir

Configurar `kubectl`