Codelab de imagens de contêiner assinadas

1. Visão geral

Este codelab tem como base o codelab do Confidential Space (em inglês). Suporte à imagem de contêiner assinado, com uma opção para autenticar um contêiner usando uma chave pública atestada em vez de especificar o resumo da imagem na política do pool de Identidade da carga de trabalho (WIP).

O que mudou com o suporte a imagens de contêiner assinadas no Confidential Space:

Uso aprimorado:com a introdução do recurso de imagem de contêiner assinado, agora podemos mudar de uma abordagem de resumo de imagens de carga de trabalho para uma abordagem de assinatura de contêiner para colaboradores/auditores que autorizam uma imagem.

  • Ao usar resumos de imagens diretamente, os proprietários de recursos precisam atualizar as políticas com um resumo de imagem sempre que autorizarem uma nova imagem. Usando assinaturas de imagem, a política contém uma impressão digital de chave pública, cuja chave privada correspondente pertence ao colaborador/auditor e é usada para assinar as imagens auditadas.
  • Para alguns modelos de segurança, referenciar uma chave de assinatura de imagem confiável é mais conveniente do que atualizar uma lista de novos valores de resumo de imagem.

Sem regressão de segurança:essa abordagem de assinatura de contêiner não traz nenhuma regressão de segurança em relação à abordagem de resumo de imagem anterior, porque os limites de confiança permanecem os mesmos. Na abordagem de assinatura do contêiner, o proprietário do recurso autoriza uma chave de verificação especificando a impressão digital da chave pública confiável na política de WIP, e a verificação de autorização é realizada pelo Serviço do Verificador de atestados e pelo WIP. O serviço Attestation Verifier verifica se a assinatura está associada à carga de trabalho em execução, e a política de WIP verifica se a chave pública declarada pelo serviço está autorizada pela política.

Segurança forte:o uso de assinaturas de imagem de contêiner permite delegar um pouco de confiança ao signatário da imagem. Ao especificar a impressão digital de chave pública de um signatário confiável na política de atestado, o proprietário do recurso autoriza o signatário a fazer recomendações sobre quais imagens de contêiner atendem a uma política. O serviço Attestation Verifier verifica se a assinatura está associada à carga de trabalho em execução, e se a política confere se a chave pública que criou a assinatura está autorizada pela política. Com isso, a assinatura de imagens oferece uma camada extra de indireção que mantém as fortes garantias de segurança do Confidential Space.

A única diferença entre essas abordagens é que a última usa uma camada extra de indireção em que as imagens de carga de trabalho são autorizadas com uma chave de assinatura. Isso não introduz nenhuma nova vulnerabilidade de segurança porque os limites de confiança permanecem os mesmos.

O que você vai aprender

Neste codelab, você vai aprender a usar uma assinatura de imagem de contêiner para autorizar o acesso a recursos protegidos:

  • Como assinar uma imagem de contêiner auditada usando o cosign
  • Como fazer upload de assinaturas de imagem de contêiner para registros OCI para descoberta e armazenamento de assinaturas
  • Como configurar os recursos de nuvem necessários para executar o Confidential Space
  • Como executar a carga de trabalho em um espaço confidencial com suporte à imagem de contêiner assinada

Este codelab mostra como usar o Espaço confidencial para atestar remotamente uma imagem de contêiner assinada por uma chave confiável em execução no Google Compute Engine.

O que é necessário

Papéis envolvidos em um espaço confidencial com imagem de contêiner assinada

Neste codelab, o Primus Bank será o auditor e o proprietário do recurso, que será responsável pelo seguinte:

  1. Como configurar os recursos necessários com dados de amostra.
  2. Como auditar o código da carga de trabalho.
  3. Usando cosign para assinar a imagem da carga de trabalho.
  4. Fazer upload da assinatura para um repositório.
  5. Como configurar a política de WIP para proteger os dados do cliente.

O Secundus Bank será o autor e operador da carga de trabalho e será responsável por:

  1. Configurar os recursos necessários para armazenar o resultado.
  2. Como escrever o código da carga de trabalho.
  3. Publicando a imagem da carga de trabalho.
  4. Como executar a carga de trabalho no Confidential Space com suporte à imagem de contêiner assinado.

O Secundus Bank desenvolverá e publicará uma carga de trabalho que consultará os dados do cliente armazenados em um bucket de armazenamento em nuvem pertencente ao Primus Bank. O Primus Bank auditará a carga de trabalho, assinará a imagem do contêiner e configurará políticas de WIP para permitir o acesso aos dados por cargas de trabalho aprovadas. O resultado da execução da carga de trabalho será armazenado em um bucket do Cloud Storage de propriedade do banco Secundus.

Recursos envolvidos em uma configuração do Confidential Space

Este codelab faz referência a diversas variáveis que você precisa definir como valores apropriados para seu projeto do GCP. Os comandos deste codelab presumem que essas variáveis foram definidas. Por exemplo, export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket' pode ser usado para definir o nome do bucket de armazenamento de entrada do Primus Bank. Se as variáveis dos nomes dos recursos não tiverem sido definidas, elas serão geradas com base no ID do projeto do GCP.

Configure o seguinte no projeto do Primus:

  • $PRIMUS_INPUT_STORAGE_BUCKET: o bucket que armazena o arquivo de dados do cliente.
  • $PRIMUS_WORKLOAD_IDENTITY_POOL: o pool de Identidade da carga de trabalho (WIP) que valida as declarações.
  • $PRIMUS_WIP_PROVIDER: o provedor do pool de Identidade da carga de trabalho, que inclui a condição de autorização que será usada em tokens assinados pelo serviço Verificador de atestados.
  • $PRIMUS_SERVICEACCOUNT: a conta de serviço que o $PRIMUS_WORKLOAD_IDENTITY_POOL usa para acessar os recursos protegidos. Nesta etapa, ele tem permissão para visualizar os dados do cliente armazenados no bucket $PRIMUS_INPUT_STORAGE_BUCKET.
  • $PRIMUS_ENC_KEY: a chave KMS usada para criptografar os dados armazenados em $PRIMUS_INPUT_STORAGE_BUCKET.

Recursos novos neste codelab:

  • $PRIMUS_COSIGN_REPOSITORY: o Artifact Registry para armazenar assinaturas de imagens de carga de trabalho.
  • $PRIMUS_SIGNING_KEY: a chave KMS usada para assinar a imagem da carga de trabalho pelo auditor/colaboradores de dados (por exemplo, o primus Bank, neste caso).

Configure o seguinte no projeto do Secundus:

  • $SECUNDUS_ARTIFACT_REGISTRY: o Artifact Registry para o qual a imagem do Docker da carga de trabalho será enviada.
  • $WORKLOAD_IMAGE_NAME: o nome da imagem do Docker da carga de trabalho.
  • $WORKLOAD_IMAGE_TAG: a tag da imagem do Docker da carga de trabalho.
  • $WORKLOAD_SERVICEACCOUNT: a conta de serviço que tem permissão para acessar a VM confidencial que executa a carga de trabalho.
  • $SECUNDUS_RESULT_BUCKET: o bucket que armazena os resultados da carga de trabalho.

Outros recursos:

  • primus_customer_list.csv contém os dados do cliente. Vamos fazer upload desses dados para $PRIMUS_INPUT_STORAGE_BUCKET e criar uma carga de trabalho que vai consultar esses dados.

Fluxo de trabalho atual

Quando você executa a carga de trabalho no Confidential Space, o seguinte processo ocorre usando os recursos configurados:

  1. A carga de trabalho solicita um token de acesso geral do Google para o $PRIMUS_SERVICEACCOUNT do WIP. Ele oferece um token de serviço do Verificador de atestados com declarações de carga de trabalho e ambiente.
  2. Se as declarações de medição de carga de trabalho no token de serviço do verificador de atestado corresponderem à condição do atributo no WIP, ele retornará o token de acesso para $PRIMUS_SERVICEACCOUNT..
  3. A carga de trabalho usa o token de acesso da conta de serviço associado a $PRIMUS_SERVICEACCOUNT para acessar os dados do cliente no bucket $PRIMUS_INPUT_STORAGE_BUCKET.
  4. A carga de trabalho executa uma operação nesses dados.
  5. A carga de trabalho usa a conta de serviço $WORKLOAD_SERVICEACCOUNT para gravar os resultados dessa operação no bucket $SECUNDUS_RESULT_STORAGE_BUCKET.

Novo fluxo de trabalho com suporte a contêineres assinados

O suporte ao contêiner assinado será integrado ao fluxo de trabalho atual, conforme destacado abaixo. Quando você executa a carga de trabalho no Confidential Space com suporte a imagens de contêiner assinadas, ocorre o seguinte processo usando os recursos configurados:

  1. O Confidential Space descobre todas as assinaturas de contêiner relacionadas à imagem da carga de trabalho em execução e as envia ao verificador de atestados. O verificador de atestado verifica a assinatura e inclui qualquer assinatura válida nas declarações do atestado.
  2. A carga de trabalho solicita um token de acesso geral do Google para o $PRIMUS_SERVICEACCOUNT do WIP. Ele oferece um token de serviço do Verificador de atestados com declarações de carga de trabalho e ambiente.
  3. Se as declarações de assinatura do contêiner no token de serviço do verificador de atestado corresponderem à condição do atributo no WIP, ele retornará o token de acesso para $PRIMUS_SERVICEACCOUNT.
  4. A carga de trabalho usa o token de acesso da conta de serviço associado a $PRIMUS_SERVICEACCOUNT para acessar os dados do cliente no bucket $PRIMUS_INPUT_STORAGE_BUCKET.
  5. A carga de trabalho executa uma operação nesses dados.
  6. A carga de trabalho usa $WORKLOAD_SERVICEACCOUNT para gravar os resultados dessa operação no bucket $SECUNDUS_RESULT_STORAGE_BUCKET.

2. Configurar recursos na nuvem

Como parte da configuração do Confidential Space, primeiro você vai criar os recursos de nuvem necessários nos projetos do GCP dos bancos Primus e Secundus. Estes são os novos recursos deste codelab:

No projeto do Primus:

  • Chave de assinatura do KMS usada para assinar cargas de trabalho do Secundus, após a auditoria do código.
  • Repositório do Artifact Registry para armazenar as assinaturas do Cosign.

Não há recursos novos no projeto Secundus. Depois de configurar esses recursos, você vai criar uma conta de serviço para a carga de trabalho com os papéis e permissões necessários. Em seguida, você criará uma imagem da carga de trabalho e o auditor, o Primus Bank, assinará a imagem da carga de trabalho. A carga de trabalho será autorizada pelos colaboradores de dados (o banco Primus neste codelab) e o operador da carga de trabalho (Secundus Bank, neste caso) executará a carga de trabalho.

Como parte da configuração do Confidential Space, você vai criar os recursos de nuvem necessários nos projetos do GCP da Primus e Secundus.

Antes de começar

  • Clone este repositório com o comando abaixo para acessar os scripts necessários que são usados como parte deste codelab.
$ git clone https://github.com/GoogleCloudPlatform/confidential-space
  • Verifique se você definiu os projetos necessários conforme mostrado abaixo.
$ export PRIMUS_PROJECT_ID=<GCP project id of primus bank>
$ export SECUNDUS_PROJECT_ID=<GCP project id of secundus bank>
  • Defina as variáveis dos nomes de recursos mencionados acima usando este comando. É possível modificar os nomes dos recursos usando essas variáveis (por exemplo, export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket').
  • Execute o script a seguir para definir os nomes de variáveis restantes como valores baseados no ID do projeto para nomes de recursos.
$ source config_env.sh
  • Instale o cosign seguindo as instruções disponíveis aqui.

Configurar os recursos bancários do Primus

Como parte desta etapa, você vai configurar os recursos de nuvem necessários para o Primus Bank. Execute o script a seguir para configurar os recursos do Primus Bank. Como parte dessas etapas, os recursos abaixo serão criados:

  • Bucket do Cloud Storage ($PRIMUS_INPUT_STORAGE_BUCKET) para armazenar o arquivo criptografado de dados do cliente do Primus Bank.
  • Chave de criptografia ($PRIMUS_ENC_KEY) e keyring ($PRIMUS_ENC_KEYRING) no KMS para criptografar o arquivo de dados do Primus Bank.
  • O pool de Identidade da carga de trabalho ($PRIMUS_WORKLOAD_IDENTITY_POOL) é usado para validar declarações com base nas condições de atributos configuradas no provedor.
  • Conta de serviço ($PRIMUS_SERVICEACCOUNT) anexada ao pool de identidade da carga de trabalho ($PRIMUS_WORKLOAD_IDENTITY_POOL) mencionado acima com o seguinte acesso do IAM:
  • roles/cloudkms.cryptoKeyDecrypter para descriptografar os dados usando a chave KMS.
  • objectViewer para ler dados do bucket do Cloud Storage.
  • roles/iam.workloadIdentityUser para conectar essa conta de serviço ao pool de identidades da carga de trabalho.
$ ./setup_primus_bank_resources.sh

Configurar os recursos do banco Secundus

Como parte desta etapa, você vai configurar os recursos de nuvem necessários para o Secundus Bank. Execute o script a seguir para configurar os recursos do Secundus Bank. Como parte das etapas abaixo, os recursos mencionados serão criados:

  • Bucket do Cloud Storage ($SECUNDUS_RESULT_STORAGE_BUCKET) para armazenar o resultado da execução da carga de trabalho pelo banco Secundus.
$ ./setup_secundus_bank_resources.sh

3. Criar e assinar carga de trabalho

Criar conta de serviço da carga de trabalho

Agora você vai criar uma conta de serviço para a carga de trabalho com os papéis e as permissões necessários. Execute o script a seguir para criar uma conta de serviço de carga de trabalho no projeto do banco Secundus. Essa conta de serviço seria usada pela VM que executa a carga de trabalho.

  • A conta de serviço da carga de trabalho ($WORKLOAD_SERVICEACCOUNT) terá os seguintes papéis:
  • confidentialcomputing.workloadUser para receber um token de atestado
  • logging.logWriter para gravar registros no Cloud Logging.
  • objectViewer para ler dados do bucket do Cloud Storage $PRIMUS_INPUT_STORAGE_BUCKET.
  • objectAdmin para gravar o resultado da carga de trabalho no bucket do Cloud Storage $SECUNDUS_RESULT_STORAGE_BUCKET.
$ ./create_workload_serviceaccount.sh

Criar carga de trabalho

Como parte desta etapa, você criará uma imagem Docker de carga de trabalho. A carga de trabalho usada neste codelab é um aplicativo Go simples baseado em CLI que conta os clientes (a partir dos dados de clientes do banco Primus) a partir de uma localização geográfica fornecida no argumento. Execute o script a seguir para criar uma carga de trabalho em que as seguintes etapas estão sendo realizadas:

  • Crie um Artifact Registry($SECUNDUS_ARTIFACT_REGISTRY) de propriedade do banco Secundus.
  • Atualize o código da carga de trabalho com os nomes dos recursos obrigatórios. Confira aqui o código da carga de trabalho usado neste codelab.
  • Crie o binário Go e o Dockerfile para gerar uma imagem do Docker do código da carga de trabalho. Confira aqui o Dockerfile usado neste codelab.
  • Crie e publique a imagem Docker no Artifact Registry ($SECUNDUS_ARTIFACT_REGISTRY) do banco Secundus.
  • Conceder permissão de leitura a $WORKLOAD_SERVICEACCOUNT para $SECUNDUS_ARTIFACT_REGISTRY. Isso é necessário para que o contêiner da carga de trabalho extraia a imagem do Docker da carga de trabalho do Artifact Registry.
$ ./create_workload.sh

Assinar carga de trabalho

Vamos usar o Cosign para assinar a imagem da carga de trabalho. O padrão do Cosign será armazenar assinaturas no mesmo repositório que a imagem que ele está assinando. Para especificar um repositório diferente para assinaturas, defina a variável de ambiente COSIGN_REPOSITORY.

Vamos usar o Artifact Registry como exemplo. Também é possível escolher outros registros baseados em OCI, como o Docker Hub e o AWS CodeArtifact, de acordo com sua preferência.

  1. Criar um repositório Docker do Artifact Registry.
$ gcloud config set project $PRIMUS_PROJECT_ID

$ gcloud artifacts repositories create $PRIMUS_COSIGN_REPOSITORY \
  --repository-format=docker --location=us
  1. Crie um keyring e uma chave no KMS para assinar uma imagem de carga de trabalho.
$ gcloud config set project $PRIMUS_PROJECT_ID

$ gcloud kms keyrings create $PRIMUS_SIGNING_KEYRING \
  --location=global

$ gcloud kms keys create $PRIMUS_SIGNING_KEY \
  --keyring=$PRIMUS_SIGNING_KEYRING \
  --purpose=asymmetric-signing \
  --default-algorithm=ec-sign-p256-sha256
  --location=us
  1. No Artifact Registry, é esperado um nome completo da imagem como $LOCATION/$PROJECT/$REPOSITORY/$IMAGE_NAME. É possível fazer upload de qualquer imagem de contêiner no repositório para armazenamento de assinaturas.
$ export COSIGN_REPOSITORY=us-docker.pkg.dev/${PRIMUS_PROJECT_ID}/${PRIMUS_COSIGN_REPOSITORY}/demo
  1. Conceda o papel de Leitor no repositório $PRIMUS_COSIGN_REPOSITORY à conta de serviço $WORKLOAD_SERVICEACCOUNT. Isso permite que o Confidential Space descubra todas as assinaturas de imagem de contêiner enviadas ao $PRIMUS_COSIGN_REPOSITORY.
$ gcloud artifacts repositories add-iam-policy-binding ${PRIMUS_COSIGN_REPOSITORY} \
--project=${PRIMUS_PROJECT_ID} --role='roles/viewer' --location=us \
--member="serviceAccount:${WORKLOAD_SERVICEACCOUNT}@${SECUNDUS_PROJECT_ID}.iam.gserviceaccount.com"

O Cosign é uma ferramenta com vários recursos de assinatura. No nosso caso de uso, exigimos que o Cosign assine apenas com um par de chaves. A assinatura sem chave cosign não é compatível com este recurso de imagem de contêiner assinado.

Ao assinar com um par de chaves, há duas opções:

  1. Assine com um par de chaves local gerado pelo Cosign.
  2. Assinar com um par de chaves armazenado em outro lugar (por exemplo, em um KMS).
  1. Gere um par de chaves no Cosign se você não tiver um. Consulte como assinar com chaves autogerenciadas para mais detalhes.
// Set Application Default Credentials.
$ gcloud auth application-default login 

// Generate keys using a KMS provider.
$ cosign generate-key-pair --kms <provider>://<key>

// Generate keys using Cosign.
$ cosign generate-key-pair

No exemplo acima, substitua <provider>://<key> com gcpkms://projects/$PRIMUS_PROJECT_ID/locations/global/keyRings/$PRIMUS_SIGNING_KEYRING/cryptoKeys/$PRIMUS_SIGNING_KEY/cryptoKeyVersions/$PRIMUS_SIGNING_KEYVERSION

  • &lt;provider&gt; : Refere-se à solução KMS que você está usando.
  • &lt;key&gt; : refere-se ao caminho da chave no KMS
  1. Recuperar a chave pública para verificação.
// For KMS providers.
$ cosign public-key --key <some provider>://<some key> > pub.pem

// For local key pair signing.
$ cosign public-key --key cosign.key > pub.pem
  1. Assinar a carga de trabalho usando o Cosign. Executar a codificação base64 sem preenchimento na chave pública
$ PUB=$(cat pub.pem | openssl base64)

// Remove spaces and trailing "=" signs.
$ PUB=$(echo $PUB | tr -d '[:space:]' | sed 's/[=]*$//')
  1. Assine a carga de trabalho usando o Cosign com a chave pública exportada e os algoritmos de assinatura anexados.
$ IMAGE_REFERENCE=us-docker.pkg.dev/$SECUNDUS_PROJECT_ID/$SECUNDUS_ARTIFACT_REPOSITORY/$WORKLOAD_IMAGE_NAME:$WORKLOAD_IMAGE_TAG

// Sign with KMS support.
$ cosign sign --key <some provider>://<some key> $IMAGE_REFERENCE \
-a dev.cosignproject.cosign/sigalg=ECDSA_P256_SHA256 \
-a dev.cosignproject.cosign/pub=$PUB

// Sign with a local key pair.
$ cosign sign --key cosign.key $IMAGE_REFERENCE \
-a dev.cosignproject.cosign/sigalg=ECDSA_P256_SHA256 \
-a dev.cosignproject.cosign/pub=$PUB
  • --key [OBRIGATÓRIO] especifica qual chave de assinatura usar. Ao se referir a uma chave gerenciada por um provedor de KMS, siga o formato de URI específico do suporte de KMS do Sigstore. Ao se referir a uma chave gerada pelo Cosign, use cosign.key.
  • $IMAGE_REFERENCE [OBRIGATÓRIO] especifica qual imagem de contêiner será assinada. O formato de IMAGE_REFERENCE pode ser identificado por uma tag ou um resumo da imagem. Por exemplo: us-docker.pkg.dev/$SECUNDUS_PROJECT_ID/secundus-workloads/workload-container:latest or us-docker.pkg.dev/$SECUNDUS_PROJECT_ID/secundus-workloads/workload-container[IMAGE-digest]
  • -a [OBRIGATÓRIO] especifica anotações anexadas ao payload da assinatura. Para imagens de contêiner assinadas pelo Confidential Space, é necessário anexar os algoritmos de chave pública e de assinatura ao payload de assinatura.
  • dev.cosignproject.cosign/sigalg SOMENTE aceita três valores:
  • RSASSA_PSS_SHA256: algoritmo RSASSA com preenchimento PSS com um resumo SHA256.
  • RSASSA_PKCS1V15_SHA256: algoritmo RSASSA com preenchimento PKCS#1 v1.5 com um resumo SHA256.
  • ECDSA_P256_SHA256: ECDSA na curva P-256 com um resumo SHA256. Esse também é o algoritmo de assinatura padrão para pares de chaves gerados pelo Cosign.
  1. fazer upload de assinaturas para o repositório do Docker

O Cosign fará upload automático das assinaturas para o COSIGN_REPOSITORY especificado.

4. Autorizar e executar carga de trabalho

Autorizar carga de trabalho

Como parte desta etapa, vamos configurar o provedor de identidade da carga de trabalho no pool de identidade da carga de trabalho ($PRIMUS_WORKLOAD_IDENTITY_POOL). Há condições de atributo configuradas para a identidade da carga de trabalho, conforme mostrado abaixo. Uma das condições é comparar a impressão digital da assinatura da imagem de carga de trabalho com a impressão digital da chave pública. Com essa condição de atributo, quando o Secundus Bank lança uma nova imagem de carga de trabalho, o Primus Bank audita o código da carga de trabalho e assina a nova imagem sem precisar atualizar a política de WIP com o resumo da imagem.

$ gcloud config set project $PRIMUS_PROJECT_ID

$ PUBLIC_KEY_FINGERPRINT=$(openssl pkey -pubin -in pub.pem -outform DER | openssl sha256 | cut -d' ' -f2)

$ gcloud iam workload-identity-pools providers create-oidc ${PRIMUS_WIP_PROVIDER} \
   --location="global" \
   --workload-identity-pool="${PRIMUS_WORKLOAD_IDENTITY_POOL}" \
   --issuer-uri="https://confidentialcomputing.googleapis.com/" \
   --allowed-audiences="https://sts.googleapis.com" \
   --attribute-mapping="google.subject='assertion.sub'" \
   --attribute-condition="assertion.swname == 'CONFIDENTIAL_SPACE' &&
  'STABLE' in assertion.submods.confidential_space.support_attributes
     && '${WORKLOAD_SERVICEACCOUNT}@${SECUNDUS_PROJECT_ID}.iam.gserviceaccount.com' in
     assertion.google_service_accounts
     && ['ECDSA_P256_SHA256:${PUBLIC_KEY_FINGERPRINT}']
       .exists(fingerprint, fingerprint in assertion.submods.container.image_signatures.map(sig,sig.signature_algorithm+':'+sig.key_id))"

Executar carga de trabalho

Como parte desta etapa, vamos executar a carga de trabalho na VM confidencial. Os argumentos TEE exigidos são transmitidos usando a flag de metadados. Os argumentos do contêiner de carga de trabalho são transmitidos usando "tee-cmd" da sinalização. A carga de trabalho é codificada para publicar o resultado em $SECUNDUS_RESULT_STORAGE_BUCKET.

$ gcloud config set project $SECUNDUS_PROJECT_ID

$ gcloud compute instances create signed-container-vm \
 --confidential-compute-type=SEV \
 --shielded-secure-boot \
 --maintenance-policy=TERMINATE \
 --scopes=cloud-platform --zone=us-west1-b \
 --image-project=confidential-space-images \
 --image-family=confidential-space \ --service-account=${WORKLOAD_SERVICEACCOUNT}@${SECUNDUS_PROJECT_ID}.iam.gserviceaccount.com \
 --metadata "^~^tee-image-reference=us-docker.pkg.dev/${SECUNDUS_PROJECT_ID}/${SECUNDUS_ARTIFACT_REPOSITORY}/${WORKLOAD_IMAGE_NAME}:${WORKLOAD_IMAGE_TAG}~tee-restart-policy=Never~tee-cmd="[\"count-location\",\"Seattle\",\"gs://${SECUNDUS_RESULT_STORAGE_BUCKET}/seattle-result\"]"~tee-signed-image-repos=us-docker.pkg.dev/${PRIMUS_PROJECT_ID}/${PRIMUS_COSIGN_REPOSITORY}/demo"

Ver resultados

No projeto Secundus, confira os resultados da carga de trabalho.

$ gcloud config set project $SECUNDUS_PROJECT_ID

$ gsutil cat gs://$SECUNDUS_RESULT_STORAGE_BUCKET/seattle-result

O resultado deve ser 3, já que é quantas pessoas de Seattle estão listadas no arquivo primus_customer_list.csv.

5. Limpeza

Confira aqui o script que pode ser usado para limpar os recursos criados neste codelab. Como parte dessa limpeza, os seguintes recursos serão excluídos:

  • Bucket de armazenamento de entrada do Primus Bank ($PRIMUS_INPUT_STORAGE_BUCKET).
  • Conta de serviço do banco Primus ($PRIMUS_SERVICEACCOUNT).
  • Registro de artefatos do Primus Bank que contém assinaturas de imagens ($PRIMUS_COSIGN_REPOSITORY).
  • Pool de identidades de carga de trabalho do Primus Bank ($PRIMUS_WORKLOAD_IDENTITY_POOL).
  • Conta de serviço de carga de trabalho do Secundus Bank ($WORKLOAD_SERVICEACCOUNT).
  • Instância do Compute da carga de trabalho.
  • Bucket de armazenamento de resultados do Secundus Bank ($SECUNDUS_RESULT_STORAGE_BUCKET).
  • Artefato do Secundus Bank ($SECUNDUS_ARTIFACT_REGISTRY).
// run the clean up script to delete the resources created as part of this codelab.
$ ./cleanup.sh

Quando terminar de explorar, considere excluir seu projeto.

  • Acesse o console do Cloud Platform.
  • Selecione o projeto que você quer encerrar e clique em "Excluir". Na parte superior: isso programa a exclusão do projeto

Parabéns

Parabéns, você concluiu o codelab.

Você aprendeu a usar o recurso de imagem de contêiner assinada para melhorar a usabilidade do Confidential Space.

Qual é a próxima etapa?

Confira alguns destes codelabs parecidos:

Leia mais