Primeiros passos no Console do Google Cloud (GKE)

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:

1. Acesse o menu do GKE no Console do Google Cloud.

   Acessar o GKE

2. Clique em Criar cluster.

3. Insira test-cluster no campo Nome.

4. Selecione Zonal nas opções de Tipo de local.

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

6. Clique em Disponibilidade, rede, segurança e outros recursos.

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

8. Selecione Aplicar somente.

9. 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:

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

   Acesse Autorização binária

2. Clique em Editar política.

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

4. 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:

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 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:

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

   Retorne para Autorização binária

2. Na guia Atestadores, clique em Criar.

   

3. 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.

4. Clique em Create para criar o atestador.

5. 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:

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

2. Na guia Política, clique em Editar política.

3. Selecione Permitir apenas imagens que foram aprovadas pelos seguintes atestadores.

4. Clique em Adicionar atestadores.

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

6. Digite PROJECT_ID no campo Nome do projeto.

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

8. Clique em Adicionar um atestador.

9. 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:

1. 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}
   

2. 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"
   }
   }
   

3. 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.

4. 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.

5. 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