Comece a usar a consola Google Cloud (GKE)

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.

Objetivos

Neste tutorial, vai aprender a:

  • Crie um cluster (GKE) com a autorização binária ativada
  • Crie um atestador que o aplicador da autorização binária usa para validar a assinatura numa atestação
  • Configure uma política que exija uma atestação
  • Crie um par de chaves criptográficas para assinar atestações e validá-las posteriormente
  • Assine um resumo de imagem de contentor, criando uma assinatura
  • Crie uma atestação com a assinatura
  • Teste a política implementando uma imagem de contentor no GKE

Custos

Neste documento, usa os seguintes componentes faturáveis do Google Cloud:

Para gerar uma estimativa de custos com base na sua utilização projetada, use a calculadora de preços.

Os novos Google Cloud utilizadores podem ser elegíveis para uma avaliação gratuita.

Antes de começar

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

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

  4. Enable the Container Registry, Artifact Analysis and Binary Authorization APIs.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the APIs

  5. Install the Google Cloud CLI.

  6. Se estiver a usar um fornecedor de identidade (IdP) externo, tem primeiro de iniciar sessão na CLI gcloud com a sua identidade federada.

  7. Para inicializar a CLI gcloud, execute o seguinte comando: 

    gcloud init

  8. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  9. Verify that billing is enabled for your Google Cloud project.

  10. Enable the Container Registry, Artifact Analysis and Binary Authorization APIs.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the APIs

  11. Install the Google Cloud CLI.

  12. Se estiver a usar um fornecedor de identidade (IdP) externo, tem primeiro de iniciar sessão na CLI gcloud com a sua identidade federada.

  13. Para inicializar a CLI gcloud, execute o seguinte comando: 

    gcloud init
  14. Instale kubectl.

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

    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.

      Captura de ecrã do separador Política que mostra a regra predefinida

    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.

    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:

      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 a atestação necessária foi feita.

    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

    Limpar

    Para evitar incorrer em custos na sua conta do Google Cloud pelos recursos usados neste tutorial, elimine o projeto que contém os recursos ou mantenha o projeto e elimine os recursos individuais.

    Elimine o cluster que criou no GKE:

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

    O que se segue?