O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Comece a usar a CLI do Google Cloud (GKE)

Este tutorial mostra como configurar e testar uma política de autorização binária que requer atestados. Este tipo de política protege a sua cadeia de fornecimento de software baseada em contentores, verificando se uma imagem de contentor tem uma atestação assinada antes de permitir a implementação da imagem.

No momento da implementação, a autorização binária usa atestadores para validar assinaturas digitais em atestações. As atestações são criadas por signatários, normalmente como parte de um pipeline de integração contínua (IC).

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 tarefas que executa na linha de comandos. Para seguir estes passos através da Google Cloud consola, consulte o artigo Comece a usar a Google Cloud consola.

Objetivos

Neste tutorial, vai aprender a:

Crie um cluster do Google Kubernetes Engine (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 prevista, use a calculadora de preços.

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

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.

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 role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Install the Google Cloud CLI.

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

Para inicializar a CLI gcloud, execute o seguinte comando:

gcloud init

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 role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Install the Google Cloud CLI.

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

Para inicializar a CLI gcloud, execute o seguinte comando:

gcloud init

Instale o kubectl para interagir com o GKE.

Ative a Autorização binária

Defina o projeto predefinido

O primeiro passo é definir o Google Cloud projeto predefinido usado pelo comandogcloud:

PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}

em que PROJECT_ID é o nome do seu projeto.

Ative as APIs necessárias

Ative as APIs para:

Artifact Registry

gcloud --project=${PROJECT_ID} \
    services enable\
    container.googleapis.com\
    artifactregistry.googleapis.com\
    binaryauthorization.googleapis.com

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

Crie o cluster

Crie um cluster do GKE com a autorização binária ativada. Este é o cluster onde quer que as imagens de contentores implementadas sejam executadas. Quando cria o cluster, passa a flag --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE para o comando gcloud container clusters create.

Para criar o cluster, siga estes passos:

gcloud container clusters create \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
    --zone us-central1-a \
    test-cluster

Aqui, cria um cluster denominado test-cluster na zona do GKE us-central1-a.

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:

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.

A autorização binária permite-lhe exportar e importar um ficheiro de política no formato YAML. Este formato reflete a estrutura de uma política tal como é armazenada pelo serviço. Quando configura uma política através de comandos gcloud, edita este ficheiro.

Para ver a política predefinida, exporte o ficheiro YAML da política:

gcloud container binauthz policy export

Por predefinição, o ficheiro tem o seguinte conteúdo:

defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_ALLOW
globalPolicyEvaluationMode: ENABLE
name: projects/PROJECT_ID/policy

A regra predefinida está definida no nó defaultAdmissionRule. evaluationMode especifica que a política permite todas as tentativas de implementação de imagens. Neste tutorial, vai atualizar a regra predefinida para exigir atestações.

globalPolicyEvaluationMode Isenta as imagens do sistema geridas pela Google da aplicação da autorização binária.

Para adicionar uma imagem isenta à lista de autorizações, adicione o seguinte ao ficheiro de políticas:

admissionWhitelistPatterns:
  - namePattern: EXEMPT_IMAGE_PATH

Substitua EXEMPT_IMAGE_PATH pelo caminho para uma imagem a isentar. Para isentar imagens adicionais, adicione entradas - namePattern adicionais. Saiba mais sobre admissionWhitelistPatterns.

Para mais informações sobre a estrutura de uma política, consulte a Referência YAML de políticas.

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 pessoal da sua organização responsável pela segurança da cadeia de fornecimento de software.

Para criar um atestador, tem de:

Crie uma nota na análise de artefactos para armazenar metadados fidedignos usados no processo de autorização
Crie o atestador na autorização binária e associe a nota que criou

Para este tutorial, tem um atestador denominado test-attestor e uma nota de análise do contentor denominada test-attestor-note. Num cenário real, pode ter qualquer número de atestadores, cada um representando uma parte que participa no processo de autorização de uma imagem de contentor.

Crie a nota de análise de artefactos

Defina variáveis que armazenam o nome do atestador e a nota de análise de artefactos:
```
ATTESTOR_NAME=test-attestor
NOTE_ID=test-attestor-note
```
Substituir:
- test-attestor: nome do atestador à sua escolha.
- attestor-note: o nome da nota do atestador à sua escolha.

Crie um ficheiro JSON em /tmp/note_payload.json que descreva a nota de análise do contentor:

cat > /tmp/note_payload.json << EOM
{
  "name": "projects/${PROJECT_ID}/notes/${NOTE_ID}",
  "attestation": {
    "hint": {
      "human_readable_name": "Attestor Note"
    }
  }
}
EOM

Crie a nota enviando um pedido HTTP para a API REST Artifact Analysis:
```
curl -X POST \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
    --data-binary @/tmp/note_payload.json  \
    "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=${NOTE_ID}"
```
Aviso: a autorização binária não suporta o armazenamento regional nem os pontos finais regionais da análise de artefactos. Recomendamos que use o ponto final da API global Artifact Analysis (https://containeranalysis.googleapis.com/).

Verifique se a nota foi criada:

curl \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}"

Crie o atestador

Agora, pode criar o atestador:

Crie o atestador na Autorização binária:

gcloud container binauthz attestors create ${ATTESTOR_NAME} \
--attestation-authority-note=${NOTE_ID} \
--attestation-authority-note-project=${PROJECT_ID}

Verifique se o atestador foi criado:

gcloud container binauthz attestors list

O atestador que criou ainda não é utilizável sem um par de chaves associado, que cria mais tarde neste guia.

Para uma configuração com vários projetos, tem de definir autorizações na nota de análise do contentor, conforme descrito na configuração com vários projetos. Isto não é necessário num cenário de projeto único, porque o projeto tem o roles/containeranalysis.notes.occurrences.viewer necessário por predefinição.

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 só é possível implementar imagens de contentores autorizadas. 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 é armazenada numa atestação. A chave pública está armazenada no atestador. No momento da implementação, o aplicador 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 imagens.

Para mais informações sobre algoritmos de assinatura, consulte o artigo Finalidades e algoritmos das chaves.

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 gcloud para mais informações sobre a utilização de chaves PKIX e do Cloud KMS.

PKIX (Cloud KMS)

Para criar o par de chaves no Cloud KMS, faça o seguinte:

Configure as variáveis de ambiente necessárias para criar o par de chaves.

KMS_KEY_PROJECT_ID=${PROJECT_ID}
KMS_KEYRING_NAME=my-binauthz-keyring
KMS_KEY_NAME=my-binauthz-kms-key-name
KMS_KEY_LOCATION=global
KMS_KEY_PURPOSE=asymmetric-signing
KMS_KEY_ALGORITHM=ec-sign-p256-sha256
KMS_PROTECTION_LEVEL=software
KMS_KEY_VERSION=1

Para criar o conjunto de chaves, execute o seguinte comando:

gcloud kms keyrings create ${KMS_KEYRING_NAME} \
  --location ${KMS_KEY_LOCATION}

Para criar a chave, execute o seguinte comando:

gcloud kms keys create ${KMS_KEY_NAME} \
  --location ${KMS_KEY_LOCATION} \
  --keyring ${KMS_KEYRING_NAME}  \
  --purpose ${KMS_KEY_PURPOSE} \
  --default-algorithm ${KMS_KEY_ALGORITHM} \
  --protection-level ${KMS_PROTECTION_LEVEL}

Para adicionar a chave pública ao atestador, execute o seguinte comando:

gcloud --project="${PROJECT_ID}" \
    container binauthz attestors public-keys add \
    --attestor="${ATTESTOR_NAME}" \
    --keyversion-project="${KMS_KEY_PROJECT_ID}" \
    --keyversion-location="${KMS_KEY_LOCATION}" \
    --keyversion-keyring="${KMS_KEYRING_NAME}" \
    --keyversion-key="${KMS_KEY_NAME}" \
    --keyversion="${KMS_KEY_VERSION}"

Obtenha o ID da chave pública do atestador da seguinte forma:

Pode ver o ID da chave pública em qualquer altura através do comando: gcloud container binauthz attestors describe <var>ATTESTOR_NAME</var>.

Para guardar o ID da chave pública numa variável de ambiente, introduza este comando:
```
PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME} \
--format='value(userOwnedGrafeasNote.publicKeys[0].id)' --project ${PROJECT_ID})
```

PKIX (chave local)

Para gerar um par de chaves PKIX, siga estes passos:

Crie a chave privada:

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