Comece a usar a consola Google Cloud (GKE)

Nota: este tutorial pressupõe que leu a vista geral da autorização binária.

Este tutorial mostra como configurar e testar uma política de autorização binária que requer atestações. Este tipo de política protege a sua cadeia de fornecimento de software baseada em contentores, definindo quem pode implementar imagens de contentores no Google Kubernetes Engine (GKE) e que imagens de contentores o GKE tem autorização para implementar.

No momento da implementação, a autorização binária usa atestadores para validar assinaturas digitais em atestações. As atestações foram criadas por signatários como parte do processo de compilação.

Neste tutorial, o cluster do GKE, as atestações e os atestadores estão todos localizados num único projeto. Uma configuração de projeto único é principalmente útil para testar ou experimentar o serviço. Para um exemplo mais real, consulte a configuração de vários projetos.

Os passos abaixo descrevem as tarefas que realiza a partir da Google Cloud consola, bem como algumas tarefas que realiza através de comandos gcloud. Para realizar estes passos com o gcloud, consulte o artigo Comece a usar a CLI Google Cloud.

Defina o projeto predefinido

Para facilitar os comandos seguintes, armazene o Google Cloud ID do projeto numa variável de ambiente da seguinte forma:

PROJECT_ID=PROJECT_ID

em que PROJECT_ID é o nome do seu projeto.

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

gcloud config set project ${PROJECT_ID}

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

Crie o cluster

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

Para criar o cluster, siga estes passos:

1. Visite o menu GKE na Google Cloud consola.

   Aceda ao GKE

2. Clique em Criar cluster.

3. Introduza test-cluster no campo Nome.

4. Selecione Zonal nas opções de Tipo de localização.

5. Selecione us-central1-a na lista pendente Zona.

6. Clique em Disponibilidade, rede, segurança e funcionalidades adicionais.

7. Na secção Segurança, selecione Ativar autorização binária.

8. Selecione Apenas aplicar.

9. Clique em Criar.

Configure o kubectl

Também tem de atualizar o ficheiro kubeconfig local para a sua instalação do kubectl. Isto fornece as credenciais e as informações do ponto final necessárias para aceder ao cluster no GKE.

Para atualizar o ficheiro kubeconfig local, siga estes passos:

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

Veja a política predefinida

Uma política na Autorização binária é um conjunto de regras que regem a implementação de imagens de contentores. Pode ter uma política por projeto. Por predefinição, a política está configurada para permitir a implementação de todas as imagens de contentores.

Para ver a política predefinida, siga estes passos:

1. Aceda à página Binary Authorization na Google Cloud consola.

   Aceda à Autorização binária

2. Clique em Editar política.

3. Em Regra predefinida do projeto, é apresentada a opção Permitir todas as imagens.

4. Clique em Guardar política.

Crie um atestador

Um atestador é a autoridade de validação que o aplicador da autorização binária usa no momento da implementação para decidir se permite que o GKE implemente a imagem de contentor assinada correspondente. O atestador contém a chave pública e é normalmente gerido por pessoas responsáveis pela segurança da cadeia de abastecimento de software.

Para criar um atestador, tem de:

• Crie o atestador na autorização binária
• Gerar automaticamente uma nota do atestador associada na análise de artefactos para armazenar metadados de atestação fidedignos usados no processo de autorização

Para este tutorial, tem um atestador com o nome test-attestor. Num cenário do mundo real, pode ter qualquer número de atestadores, cada um representando uma parte que participa no processo de autorização da imagem.

Gere um par de chaves

A autorização binária usa chaves criptográficas para validar a identidade dos signatários de forma segura. Isto garante que apenas as imagens de contentores autorizadas podem ser implementadas. O par de chaves consiste numa chave privada e numa chave pública. O signatário usa a chave privada para assinar o resumo da imagem do contentor, produzindo uma assinatura que é, depois, armazenada numa atestação. A chave pública é armazenada no atestador. No momento da implementação, o agente de aplicação da autorização binária usa a chave pública do atestador para validar a assinatura na atestação antes de permitir a implementação do contentor.

Neste tutorial, 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 pode usar chaves RSA ou PGP para assinar. 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) estão em conformidade com a norma PKIX. Consulte o artigo Criar atestadores com a CLI para mais informações sobre a utilização de chaves PKIX e do Cloud KMS.

Aviso: recomendamos vivamente que não use pares de chaves gerados localmente em ambientes de produção, uma vez que representam um risco de segurança. Em alternativa, recomendamos que use o Cloud Key Management Service. Este exemplo é fornecido apenas a título ilustrativo.

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

1. Crie a chave privada:

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

2. 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, pode criar o próprio atestador na autorização binária e associar a chave pública que criou.

Para criar o atestador, faça o seguinte:

1. Volte à página Binary Authorization na Google Cloud consola.

   Regressar à autorização binária

2. No separador Atestadores, clique em Criar.

   

3. Preencha os campos da seguinte forma:

   1. Introduza test-attestor no campo Nome do atestador.

   2. Verifique se a opção Criar automaticamente uma nota de análise de artefactos está selecionada.

   3. Clique em Adicionar uma chave pública PKIX.

   4. Abra /tmp/ec_public.pem num editor de texto. Este é o ficheiro de chave pública que criou no passo anterior. Copie o conteúdo do ficheiro para a caixa de texto Material da chave pública.

   5. Clique em Elliptic Curve P-256 - SHA256 Digest no menu pendente Algoritmo de assinatura.

   6. Clique em Concluído.

4. Clique em Criar para criar o atestador.

5. Armazenar o ID da chave pública.

   Para ver o ID da chave pública do atestador depois de o adicionar 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 o seguinte comando:

   ATTESTOR_NAME=test-attestor
   PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME}\
     --format='value(userOwnedGrafeasNote.publicKeys[0].id)')
   

Configure a política

Agora, pode configurar a sua política:

1. Volte à página Binary Authorization na Google Cloud consola.

2. No separador Política, clique em Editar política.

3. Selecione Permitir apenas imagens que tenham sido aprovadas pelos seguintes atestadores.

4. Clique em Adicionar atestantes.

5. Clique em Adicionar por projeto e nome do atestador.

6. Introduza PROJECT_ID no campo Nome do projeto.

7. Introduza test-attestor no campo Nome do atestador.

8. Clique em Adicionar 1 atestante.

9. Clique em Guardar política.

Nota: a política pode demorar alguns minutos a entrar em vigor.

Para mais informações, consulte o artigo Configurar uma política através da consola.

Teste a política

Pode testar a política que configurou acima tentando implementar uma imagem de contentor de exemplo no cluster. A política bloqueia a implementação porque a atestação necessária não foi feita.

Para este tutorial, pode usar imagens de amostra do Artifact Registry. A imagem do Artifact Registry encontra-se no caminho us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0. O caminho contém uma imagem pública criada pela Google que contém uma aplicação de exemplo "Hello, World!".

Para tentar implementar a imagem, execute o seguinte comando:

kubectl run hello-server --image us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0 --port 8080

Agora, valide se a implementaçã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 implementada:

No resources found.

Pode obter mais detalhes sobre a implementação:

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

Vê uma resposta semelhante à seguinte:

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

Neste resultado:

• POD_NAME: o nome do agrupamento.
• IMAGE_NAME: o nome da imagem.
• ATTESTOR_NAME: o nome do atestador.

Certifique-se de que elimina a implementação para poder continuar para o passo seguinte:

kubectl delete deployment hello-server

Crie uma atestação

Uma atestação é um documento digital criado por um signatário que certifica que o GKE tem autorização para implementar a imagem de contentor associada. O processo de criação de uma atestação é por vezes denominado "assinar uma imagem".

Neste tutorial, cria uma atestação para imagens de exemplo do Artifact Registry.

Para criar uma atestação, faça o seguinte:

1. Defina variáveis que armazenam o caminho do registo e o resumo da imagem, bem como o nome do atestador:

   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}
   

2. Gere o payload de atestação:

   Nota: no comando seguinte, embora seja necessário um ${IMAGE_PATH} para criar a carga útil da assinatura para a atestação, apenas o ${IMAGE_DIGEST} é usado no momento da implementação. Isto significa que pode implementar uma imagem de contentor idêntica a partir de várias localizações com a mesma atestação.

   Artifact Registry

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

   O ficheiro JSON do 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"
   }
   }
   

3. Assine a carga útil com a sua chave privada PKIX e gere um ficheiro de assinatura:

   openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature
   

   O ficheiro de assinatura é uma versão com assinatura digital do ficheiro JSON de dados que criou acima.

4. Crie e valide a atestação:

   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
   

   onde PUBLIC_KEY_ID é o ID da chave pública que encontrou em Gere um par de chaves PKIX acima.

   A flag validate verifica se a atestação pode ser validada pelo atestador que configurou na sua política.

5. Verifique se a atestação foi criada:

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

Para mais informações sobre a criação de atestações, consulte o artigo Criar atestações.

Volte a testar a política

Mais uma vez, teste a política implementando uma imagem de contentor de amostra no cluster. Desta vez, tem de implementar a imagem através do resumo, em vez de uma etiqueta como 1.0 ou latest, uma vez que a autorização binária usa o resumo para procurar atestações. Aqui, a autorização binária permite a implementação da imagem porque foi feita a atestação necessária.

Para implementar a imagem, execute o seguinte comando:

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

Para verificar se a imagem foi implementada, execute o seguinte comando:

kubectl get pods

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

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

Para eliminar o pod, execute o seguinte comando:

kubectl delete pod hello-server