Esta página foi traduzida pela API Cloud Translation.

Configure uma configuração com vários projetos

Este tutorial descreve como usar a autorização binária numa configuração com vários projetos. Para uma configuração mais simples de projeto único, consulte o artigo Comece a usar a CLI do Google Cloud (GKE).

Para estabelecer a separação de funções, pode configurar a autorização binária numa configuração de vários projetos. A finalidade de cada projeto é abordada mais adiante neste tutorial.

Objetivos

Neste tutorial, vai realizar as seguintes tarefas:

Configure um projeto diferente para a implementação (GKE), o atestador e a gestão de atestação, para suportar a separação de funções.
Configure a regra predefinida da sua política de autorização binária para exigir atestações.
Crie um par de chaves de infraestrutura de chave pública (X.509) (PKIX) para assinar e, posteriormente, validar a atestação.
Crie um atestador que o aplicador da autorização binária usa para validar a atestação.
Assinar uma imagem de exemplo, criando uma atestação.
Teste a política implementando a imagem de exemplo.

Tem de configurar o controlo de acesso adequado de cada projeto através da gestão de identidade e de acesso (IAM).

Para segurança adicional, pode usar os VPC Service Controls para ajudar a proteger os recursos que criar neste tutorial. Para mais informações, consulte o artigo Proteja com o VPC Service Controls.

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

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

Configure o projeto do implementador

O projeto implementador gere os clusters do Google Kubernetes Engine (GKE), onde implementa imagens, e a política de autorização binária que a autorização binária aplica no momento da implementação. Pode ter mais do que um projeto de implementação, consoante o tamanho, a complexidade e outros requisitos do seu ambiente.

Para configurar o projeto de implementação:

Crie o projeto e ative a faturação na Google Cloud consola se ainda não o tiver feito.
Nota sobre a gestão de identidade e de acesso: o projeto de implementação contém o seu cluster do GKE. A configuração da gestão de identidade e de acesso para este projeto deve refletir isso.

Defina variáveis de ambiente para armazenar o Google Cloud projeto e o número:

DEPLOYER_PROJECT_ID=DEPLOYER_PROJECT_ID

Substitua DEPLOYER_PROJECT_ID pelo Google Cloud ID do projeto.

DEPLOYER_PROJECT_NUMBER=$(gcloud projects describe "${DEPLOYER_PROJECT_ID}" \
    --format="value(projectNumber)")

Ative as APIs:

Artifact Registry

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

Obtenha o nome da conta de serviço do projeto implementador:
```
DEPLOYER_SERVICE_ACCOUNT="service-${DEPLOYER_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
```
Usa o nome da conta de serviço num passo posterior quando configura as autorizações na nota de análise de artefactos associada ao seu atestador.

Configure o projeto do atestador

Um projeto de atestador armazena os atestadores que podem validar se uma imagem está pronta para implementação. Muitas vezes, tem um único projeto de atestação que funciona como um repositório centralizado de informações sobre partes fidedignas no processo de autorização. Isto permite-lhe gerir centralmente as chaves de segurança necessárias para validar a identidade dos atestadores e restringir o acesso apenas às partes que as administram.

Para configurar o projeto de atestação:

Crie o projeto e ative a faturação na Google Cloud consola se ainda não o tiver feito.
Nota sobre a gestão de identidades e acessos: uma vez que este projeto contém os seus atestadores, apenas o pessoal de segurança deve ter acesso de escrita.

Defina variáveis de ambiente para armazenar o ID e o número do projeto:

ATTESTOR_PROJECT_ID=ATTESTOR_PROJECT_ID

Substitua ATTESTOR_PROJECT_ID pelo ID do projeto do atestador.

ATTESTOR_PROJECT_NUMBER=$(gcloud projects describe "${ATTESTOR_PROJECT_ID}" \
    --format="value(projectNumber)")

Ative as APIs Artifact Analysis e Binary Authorization:

gcloud services --project=${ATTESTOR_PROJECT_ID} \
    enable containeranalysis.googleapis.com \
    binaryauthorization.googleapis.com

Obtenha o nome da conta de serviço do projeto do atestador:
```
ATTESTOR_SERVICE_ACCOUNT="service-${ATTESTOR_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
```
Usa o nome da conta de serviço num passo posterior quando configura as autorizações na nota de análise de artefactos associada ao seu atestador.

Configure o projeto de atestações

Um projeto de atestação é um projeto que armazena atestações que os atestadores fazem quando validam uma imagem. Um projeto de atestação separado permite-lhe organizar e inspecionar declarações sobre a disponibilidade do software mais facilmente.

Crie o projeto e ative a faturação na Google Cloud consola se ainda não o tiver feito.
Nota sobre a gestão de identidade e acesso: todas as funções envolvidas na autorização binária devem ter acesso de leitura às notas e ocorrências da análise de artefactos neste projeto. No entanto, apenas os gestores de atestação precisam de ter acesso de escrita.
Defina uma variável de ambiente para armazenar o nome do projeto:
```
ATTESTATION_PROJECT_ID=ATTESTATION_PROJECT_ID
```
Substitua ATTESTATION_PROJECT_ID pelo ID do projeto de atestação.

Ative as APIs Artifact Analysis e Binary Authorization:

gcloud services --project=${ATTESTATION_PROJECT_ID} \
    enable containeranalysis.googleapis.com \
    binaryauthorization.googleapis.com

Crie um cluster

Agora, pode criar um cluster do GKE no projeto do implementador. Este é o cluster onde quer que as imagens de contentores implementadas sejam executadas. Quando criar o cluster, transmita a flag --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE para o comando gcloud container clusters create.

Para criar o cluster:

gcloud --project=${DEPLOYER_PROJECT_ID} \
    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.

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 --project=${DEPLOYER_PROJECT_ID} \
    container clusters get-credentials \
    --zone us-central1-a \
    test-cluster

Crie um atestador

Um atestador é uma parte responsável por atestar que um processo necessário foi concluído antes de uma imagem de contentor poder ser implementada. Esta parte pode ser um utilizador humano ou, mais frequentemente, um processo de máquina, como um sistema de compilação e teste, ou os seus pipelines de integração contínua (IC) e implementação (IC). Cria atestadores no seu projeto de atestador.

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 no projeto do atestador e associe a nota que criou
Adicione uma associação de funções do IAM para a conta de serviço do projeto de implementação ao atestador
Defina autorizações na nota de análise de artefactos

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 da imagem.

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
```
Substituição:
- test-attestor: nome do atestador à sua escolha.
- test-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/${ATTESTOR_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/${ATTESTOR_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/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}"

Crie o atestador

Agora, pode criar o atestador:

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

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

Verifique se o atestador foi criado:

gcloud --project=${ATTESTOR_PROJECT_ID} \
    container binauthz attestors list

O atestador que criou ainda não é utilizável sem um par de chaves PKIX associado, que cria abaixo.

Adicione uma associação de função do IAM para o projeto implementador

Tem de adicionar uma associação de função do IAM para o projeto de implementação ao atestador. Esta opção é usada pela autorização binária quando avalia uma política para determinar se o projeto tem autorizações para aceder a quaisquer atestações associadas.

Para adicionar a associação de funções IAM:

gcloud --project ${ATTESTOR_PROJECT_ID} \
    container binauthz attestors add-iam-policy-binding \
    "projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}" \
    --member="serviceAccount:${DEPLOYER_SERVICE_ACCOUNT}" \
    --role=roles/binaryauthorization.attestorsVerifier

Defina autorizações na nota de análise de artefactos

Também tem de definir autorizações na nota de análise de artefactos que criou para que seja acessível ao projeto de implementação e ao projeto de atestação. Para o fazer, atualize a política de IAM da nota para atribuir acesso de leitor às contas de serviço do projeto.

Gere um ficheiro JSON que contenha as informações necessárias para definir a política de IAM na sua nota.

cat > /tmp/iam_request.json << EOM
{
  'resource': 'projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}',
  'policy': {
    'bindings': [
      {
        'role': 'roles/containeranalysis.notes.occurrences.viewer',
        'members': [
          'serviceAccount:${ATTESTOR_SERVICE_ACCOUNT}',
          'serviceAccount:${DEPLOYER_SERVICE_ACCOUNT}'
        ]
      }
    ]
  }
}
EOM

Adicione a conta de serviço e as funções de acesso pedidas à política de IAM para a nota que criou:
```
curl -X POST  \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    --data-binary @/tmp/iam_request.json \
    "https://containeranalysis.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}:setIamPolicy"
```
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/).

Configure chaves PKIX

A autorização binária usa chaves criptográficas para validar de forma segura a identidade dos atestadores. Isto garante que apenas as partes validadas podem participar na autorização de uma imagem de contentor. O par de chaves consiste numa chave privada, que o atestador usa para assinar digitalmente as atestações, e numa chave pública, que adiciona ao atestador conforme armazenado pelo serviço de autorização binária.

Neste tutorial, vai usar o algoritmo de assinatura digital de curva elíptica (ECDSA) recomendado para criar o par de chaves. 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 assimétricas geradas e armazenadas pelo Cloud Key Management Service (Cloud KMS) estão em conformidade com a norma PKIX. Consulte o artigo Criar atestadores através da CLI para mais informações sobre a utilização de chaves PKIX e do Cloud KMS.

Gere um par de chaves

Um par de chaves PKIX consiste numa chave privada, que o signatário usa para assinar digitalmente atestações, e numa chave pública, que adiciona ao atestador. No momento da implementação, a autorização binária usa esta chave pública para validar a atestação assinada pela chave privada.

Gere a chave privada:

Para gerar um novo par de chaves PKIX assimétricas locais e armazená-lo num ficheiro:
PKIX (Cloud KMS)
Este passo mostra como realizar uma atestação através de chaves geradas e armazenadas no Cloud Key Management Service.
1. Configure variáveis de ambiente para armazenar informações sobre o par de chaves gerido pelo Cloud KMS:
  
  Se já tiver um par de chaves, pode definir estas variáveis de ambiente e ignorar o passo seguinte.
  KMS_KEY_PROJECT_ID=KMS_KEY_PROJECT_ID KMS_KEY_LOCATION=KMS_KEY_LOCATION KMS_KEYRING_NAME=KMS_KEYRING_NAME KMS_KEY_NAME=KMS_KEY_NAME KMS_KEY_VERSION=KMS_KEY_VERSION
  Substitua o seguinte:
  - KMS_KEY_PROJECT_ID: o ID do projeto onde as chaves estão armazenadas
  - KMS_KEY_LOCATION: a localização da chave
  - KMS_KEYRING_NAME: o nome do conjunto de chaves
  - KMS_KEY_NAME: o nome da chave
  - KMS_KEY_VERSION: a versão da chave
2. [Opcional] Configure uma chave do KMS:
  
  Nota: pode ignorar estes passos se já tiver uma chave do KMS.
  1. Crie uma chave do KMS cuja chave pública possa ser armazenada num atestador. Este passo também configura as variáveis de ambiente que usa abaixo.
    
    Para criar uma chave e configurar as variáveis de ambiente:
    
    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
  2. Crie um conjunto de chaves do KMS:
    
    gcloud kms keyrings create ${KMS_KEYRING_NAME} \ --location ${KMS_KEY_LOCATION} \ --project ${KMS_KEY_PROJECT_ID}
  3. Crie a chave:
    
    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} \ --project ${KMS_KEY_PROJECT_ID}
    
    Para mais informações sobre a criação de chaves do KMS, consulte o artigo Crie uma chave assimétrica.
3. Adicione a chave pública ao atestador:
  gcloud --project="${ATTESTOR_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}"
PKIX (chave local)

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.
1. Para gerar a chave privada, execute os seguintes comandos:
  PRIVATE_KEY_FILE="/tmp/ec_private.pem" openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}
  PRIVATE_KEY_FILE é o nome do ficheiro que contém a chave privada armazenada no atestador.
2. Extraia a chave pública da chave privada e armazene-a num ficheiro:
  PUBLIC_KEY_FILE="/tmp/ec_public.pem" openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}
  PUBLIC_KEY_FILE é o nome do ficheiro que contém a chave pública armazenada no atestador.
3. Para adicionar a chave pública que exportou para o atestador, execute o seguinte código.
  gcloud --project="${ATTESTOR_PROJECT_ID}" \ container binauthz attestors public-keys add \ --attestor="${ATTESTOR_NAME}" \ --pkix-public-key-file=${PUBLIC_KEY_FILE} \ --pkix-public-key-algorithm=ecdsa-p256-sha256
  A autorização binária usa a chave pública no atestador para validar a atestação.

Configure a política

Agora, pode configurar a sua política no projeto implementador. Neste passo, vai exportar o ficheiro YAML da política para o seu sistema local e modificar a regra predefinida para que exija uma atestação por parte do atestador que definiu acima.

Para configurar a política:

Crie um novo ficheiro de política que permita imagens do sistema mantidas pela Google, defina evaluationMode como REQUIRE_ATTESTATION e adicione um nó denominado requireAttestationsBy que faça referência ao atestador que criou:

cat > /tmp/policy.yaml << EOM
    globalPolicyEvaluationMode: ENABLE
    defaultAdmissionRule:
      evaluationMode: REQUIRE_ATTESTATION
      enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
      requireAttestationsBy:
        - projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}
    name: projects/${DEPLOYER_PROJECT_ID}/policy
EOM

Importe o ficheiro YAML da política para a Binary Authorization:

gcloud --project=${DEPLOYER_PROJECT_ID} \
    container binauthz policy import /tmp/policy.yaml

Para mais informações sobre a configuração de uma política, consulte o artigo Configurar uma política através da CLI.

Teste a política

Neste tutorial, cria uma atestação, por exemplo, de imagens públicas "Hello World!" do Artifact Registry. Inicialmente, o aplicador impede a implementação das imagens porque a atestação necessária não existe.

Para tentar implementar a imagem:

Artifact Registry

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 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 é uma declaração de um atestador de que um processo obrigatório no seu pipeline foi concluído e que a imagem do contentor em questão está autorizada para implementação. A própria atestação é um registo assinado digitalmente que contém o caminho completo para uma versão da imagem, conforme armazenada no seu registo de imagens de contentores, bem como a identidade do atestador.

Neste tutorial, a sua atestação indica simplesmente que autoriza a imagem para implementação. Cria a atestação no projeto de atestação.

Para criar uma atestação:

Defina variáveis que armazenam o caminho do registo e o resumo da imagem:

Artifact Registry

IMAGE_PATH="us-docker.pkg.dev/google-samples/containers/gke/hello-app"
IMAGE_DIGEST="sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567"
IMAGE_TO_ATTEST=${IMAGE_PATH}@${IMAGE_DIGEST}

Crie a atestação

PKIX Cloud KMS

Para criar a atestação com a chave do Cloud KMS, execute o seguinte comando:

gcloud beta container binauthz attestations sign-and-create \
    --project="${PROJECT_ID}" \
    --artifact-url="${IMAGE_TO_ATTEST}" \
    --attestor="${ATTESTOR_NAME}" \
    --attestor-project="${PROJECT_ID}" \
    --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}"

PKIX (chave local)

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

Gere o payload de atestação:

gcloud --project=${ATTESTATION_PROJECT_ID} \
  container binauthz create-signature-payload \
  --artifact-url=${IMAGE_TO_ATTEST} > /tmp/generated_payload.json

O ficheiro JSON do payload tem o seguinte conteúdo:

Artifact Registry

{
"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.

Se usar ficheiros PKIX locais, assine a carga útil com a sua chave privada PKIX local e gere um ficheiro de assinatura:
```
openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature
```
O ficheiro de saída é uma versão assinada do ficheiro JSON do payload que criou acima.
Obtenha o ID da chave pública do atestador.

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

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 ${ATTESTOR_PROJECT_ID})
```

Crie e valide a atestação:

gcloud container binauthz attestations create \
  --project="${ATTESTATION_PROJECT_ID}" \
  --artifact-url="${IMAGE_TO_ATTEST}" \
  --attestor="projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}" \
  --signature-file=/tmp/ec_signature \
  --public-key-id="${PUBLIC_KEY_ID}" \
  --validate

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

Verifique se a atestação foi criada:

gcloud --project=${ATTESTATION_PROJECT_ID} \
    container binauthz attestations list \
    --attestor=$ATTESTOR_NAME --attestor-project=$ATTESTOR_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

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 imagem tem uma atestação associada.

Para implementar a imagem:

kubectl run hello-server --image ${IMAGE_TO_ATTEST} --port 8080

Para verificar se a imagem foi implementada:

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

Agora que implementou com êxito a imagem do contentor e verificou que a configuração está a funcionar, pode eliminar o cluster que criou no GKE:

gcloud --project=${DEPLOYER_PROJECT_ID} \
    container clusters delete \
    --zone=us-central1-a \
    test-cluster

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

Também pode eliminar Google Cloud projetos que criou para este tutorial.

Configure uma configuração com vários projetos Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Objetivos

Custos

Antes de começar

Configure o projeto do implementador

Artifact Registry

Configure o projeto do atestador

Configure o projeto de atestações

Crie um cluster

Crie um atestador

Crie a nota de análise de artefactos

Crie o atestador

Adicione uma associação de função do IAM para o projeto implementador

Defina autorizações na nota de análise de artefactos

Configure chaves PKIX

Gere um par de chaves

PKIX (Cloud KMS)

PKIX (chave local)

Configure a política

Teste a política

Artifact Registry

Crie uma atestação

Artifact Registry

PKIX Cloud KMS

PKIX (chave local)

Artifact Registry

Volte a testar a política

Limpar

O que se segue?

Configure uma configuração com vários projetos