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:
- Artifact Registry
- Binary Authorization
- GKE
- Container Registry
- Optional: Cloud Key Management Service
Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços.
Antes de começar
- Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the Container Registry, Artifact Analysis and Binary Authorization APIs.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the Container Registry, Artifact Analysis and Binary Authorization APIs.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
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.
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.
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ê vai usar o formato de infraestrutura de chave pública (X.509) (PKIX) para chaves criptográficas. Este tutorial usa o Algoritmo de assinatura digital de curva elíptica (ECDSA) recomendado para gerar um par de chaves PKIX. Também é possível usar chaves RSA ou PGP para assinatura. Consulte Finalidades de chave 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.
Na guia Atestadores, clique em Criar.
Preencha os campos da seguinte forma:
Digite
test-attestor
no campo Nome do atestador.Verifique se a opção Criar automaticamente uma nota do Artifact Analysis está marcada.
Clique em Adicionar uma chave pública PKIX.
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.Clique em
Elliptic Curve P-256 - SHA256 Digest
no menu suspenso Algoritmo de assinatura.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, você precisa implantar a imagem usando o resumo em vez de uma tag, como 1.0
ou latest
, já que a autorização binária usará o resumo 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). - Saiba como usar resumos de imagem nos manifestos do Kubernetes
- Ativar o modo de simulação para desativar a aplicação