Esta página foi traduzida pela API Cloud Translation.

Codelab de imagens de contêiner assinadas

1. Visão geral

Este codelab se baseia no codelab do Confidential Space. O suporte a imagens de contêiner assinadas oferece a opção de 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 à imagem de contêiner assinada no Confidential Space:

Melhoria na usabilidade:com a introdução do recurso de imagem de contêiner assinada, agora podemos mudar de uma abordagem de resumo de imagem de carga de trabalho para uma abordagem de assinatura de contêiner para colaboradores/auditores que autorizam uma imagem.

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

Nenhuma regressão de segurança:essa abordagem de assinatura de contêiner não vai trazer nenhuma regressão de segurança em relação à abordagem anterior de resumo de imagem, porque os limites de confiança permanecem os mesmos. Na abordagem de assinatura de 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. A verificação de autorização é realizada pelo serviço de atestado e pelo WIP. O serviço de atestado 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 avançada: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 da chave pública de um signatário confiável na política de atestado, o proprietário do recurso autoriza esse signatário a fazer endossos sobre quais imagens do contêiner atendem a uma política. O serviço de verificação de atestados verifica se a assinatura está associada à carga de trabalho em execução, e a política verifica se a chave pública que criou a assinatura está autorizada pela política. Dessa forma, a camada adicional de indirection que a assinatura de imagem oferece mantém as 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 novas vulnerabilidades 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 cosign
Como fazer upload de assinaturas de imagens de contêiner para registros do OCI para descoberta e armazenamento de assinaturas
Como configurar os recursos de nuvem necessários para executar o Espaço confidencial
Como executar a carga de trabalho em um Confidential Space com suporte à imagem de contêiner assinada

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

O que é necessário

Concluir o codelab do Confidential Space.
Um projeto do Google Cloud Platform
Um navegador, como o Chrome ou o Firefox
Conhecer os editores de texto padrão do Linux (como Vim, Emacs ou Nano)
Conhecimento básico sobre coassinatura do Sigstore
Conhecimento básico do Google Compute Engine ( codelab), VM confidencial, Containers e repositórios remotos
Conhecimento básico do Cloud KMS ( codelab).
Conhecimento básico de contas de serviço, federação de identidade da carga de trabalho e condições de atributo.
Conhecimento básico do Artifact Registry
Conhecimento básico de assinaturas digitais

Funções envolvidas em um Confidential Space com imagem de contêiner assinada

Neste codelab, a Primus Bank será a auditora e a proprietária do recurso, que será responsável pelo seguinte:

Configurar os recursos necessários com dados de exemplo.
Auditar o código da carga de trabalho.
Usando cosign para assinar a imagem da carga de trabalho.
Fazer upload da assinatura para um repositório.
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:

Configurar os recursos necessários para armazenar o resultado.
Como escrever o código da carga de trabalho.
Publicação da imagem de carga de trabalho.
Executar a carga de trabalho no Confidential Space com suporte a imagem de contêiner assinada.

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

Recursos envolvidos na configuração de um Confidential Space

Este codelab faz referência a várias variáveis que você precisa definir com valores apropriados para seu projeto do GCP. Os comandos neste 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 de recursos não tiverem sido definidas, elas serão geradas com base no ID do projeto do GCP.

Configure o seguinte no projeto 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, na sigla em inglês) que valida as reivindicações.
$PRIMUS_WIP_PROVIDER: o provedor do pool de Identidade da carga de trabalho, que inclui a condição de autorização a ser usada para tokens assinados pelo serviço de verificação de atestados.
$PRIMUS_SERVICEACCOUNT: a conta de serviço que $PRIMUS_WORKLOAD_IDENTITY_POOL usa para acessar os recursos protegidos. Nesta etapa, ele tem permissão para acessar os dados do cliente armazenados no bucket $PRIMUS_INPUT_STORAGE_BUCKET.
$PRIMUS_ENC_KEY: a chave do 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 do KMS usada para assinar a imagem da carga de trabalho por auditores/colaboradores de dados (por exemplo, o banco Primus neste caso).

Configure o seguinte no projeto Secundus:

$SECUNDUS_ARTIFACT_REGISTRY: o registro de artefatos em que a imagem do contêiner de carga de trabalho será enviada.
$WORKLOAD_IMAGE_NAME: o nome da imagem do contêiner de 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 o upload desses dados para $PRIMUS_INPUT_STORAGE_BUCKET e criar uma carga de trabalho que vai consultar esses dados.

Fluxo de trabalho atual

Ao executar a carga de trabalho no Confidential Space, o processo a seguir é realizado usando os recursos configurados:

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 atestado com declarações de carga de trabalho e ambiente.
Se as declarações de medição de carga de trabalho no token de serviço do verificador de atestado corresponderem à condição de atributo no WIP, ele retornará o token de acesso para $PRIMUS_SERVICEACCOUNT..
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.
A carga de trabalho realiza uma operação nesses dados.
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 a contêineres assinados será integrado ao fluxo de trabalho atual, conforme destacado abaixo. Quando você executa a carga de trabalho no Confidential Space com suporte para imagem de contêiner assinada, o processo a seguir é realizado usando os recursos configurados:

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 atestado. O verificador de atestados verifica a assinatura e inclui todas as assinaturas válidas nas declarações de atestado.
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 atestado com declarações de carga de trabalho e ambiente.
Se as declarações de assinatura do contêiner no token de serviço do verificador de atestado corresponderem à condição de atributo no WIP, ele retornará o token de acesso para $PRIMUS_SERVICEACCOUNT.
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.
A carga de trabalho realiza uma operação nesses dados.
A carga de trabalho usa o $WORKLOAD_SERVICEACCOUNT para gravar os resultados dessa operação no bucket $SECUNDUS_RESULT_STORAGE_BUCKET.

2. Configurar recursos do Cloud

Como parte da configuração do Espaço confidencial, primeiro você vai criar os recursos de nuvem necessários nos projetos do GCP do banco Primus e Secundus. Estes são os recursos novos neste codelab:

No projeto 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 de coassinatura.

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

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

Antes de começar

Clone este repositório usando o comando abaixo para receber os scripts necessários que são usados como parte deste codelab.

git clone https://github.com/GoogleCloudPlatform/confidential-space

Mude o diretório para este codelab.

cd confidential-space/codelabs/signed_container_codelab/scripts

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 para os nomes de recursos mencionados acima usando este comando. É possível substituir os nomes de recursos usando estas variáveis (por exemplo, export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket')
Execute o script abaixo para definir os nomes das variáveis restantes como valores com base no ID do projeto para nomes de recursos.

source config_env.sh

Instale o cosign seguindo as instruções neste link.

Configurar recursos do banco Primus

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

Bucket do Cloud Storage ($PRIMUS_INPUT_STORAGE_BUCKET) para armazenar o arquivo de dados do cliente criptografado do banco Primus.
Chave de criptografia ($PRIMUS_ENC_KEY) e chaveiro ($PRIMUS_ENC_KEYRING) no KMS para criptografar o arquivo de dados do banco Primus.
Pool de identidade da carga de trabalho ($PRIMUS_WORKLOAD_IDENTITY_POOL) 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 do 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 recursos do banco Secundus

Nesta etapa, você vai configurar os recursos de nuvem necessários para o banco Secundus. Execute o script abaixo para configurar os recursos do banco Secundus. Como parte destas etapas, os recursos abaixo 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 uma conta de serviço de carga de trabalho

Agora, você vai criar uma conta de serviço para a carga de trabalho com as funções e permissões necessárias. Execute o script abaixo para criar uma conta de serviço de carga de trabalho no projeto de banco Secundus. Essa conta de serviço seria usada pela VM que executa a carga de trabalho.

Essa conta de serviço de carga de trabalho ($WORKLOAD_SERVICEACCOUNT) terá as seguintes funções:
confidentialcomputing.workloadUser para receber um token de atestado
logging.logWriter para gravar registros no Cloud Logging.
objectViewer para ler dados do bucket de armazenamento em nuvem $PRIMUS_INPUT_STORAGE_BUCKET.
objectAdmin para gravar o resultado da carga de trabalho no bucket de armazenamento em nuvem $SECUNDUS_RESULT_STORAGE_BUCKET.

./create_workload_serviceaccount.sh

Criar carga de trabalho

Nesta etapa, você vai criar uma imagem Docker de carga de trabalho. A carga de trabalho usada neste codelab é um app Go simples baseado em CLI que conta clientes (de dados de clientes do banco Primus) de um local geográfico fornecido no argumento. Execute o script abaixo para criar uma carga de trabalho em que as etapas a seguir estão sendo realizadas:

Criar o registro de artefato($SECUNDUS_ARTIFACT_REGISTRY) do banco Secundus.
Atualize o código da carga de trabalho com os nomes dos recursos necessários. Este é o código de carga de trabalho usado neste codelab.
Crie o binário Go e o Dockerfile para criar uma imagem do Docker do código da carga de trabalho. Este é o Dockerfile usado neste codelab.
Crie e publique a imagem Docker no Artifact Registry ($SECUNDUS_ARTIFACT_REGISTRY) do banco Secundus.
Conceda a permissão de leitura $WORKLOAD_SERVICEACCOUNT para $SECUNDUS_ARTIFACT_REGISTRY. Isso é necessário para que o contêiner da carga de trabalho extraia a imagem do contêiner da carga de trabalho do Artifact Registry.

./create_workload.sh

Carga de trabalho do sinal

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

Aqui, vamos usar o Artifact Registry como exemplo. Você também pode escolher outros registros baseados no OCI, como o Docker Hub e o AWS CodeArtifact, de acordo com sua preferência.

Crie um repositório do Docker no Artifact Registry.

gcloud config set project $PRIMUS_PROJECT_ID

gcloud artifacts repositories create $PRIMUS_COSIGN_REPOSITORY \
  --repository-format=docker --location=${PRIMUS_PROJECT_REPOSITORY_REGION}

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=${PRIMUS_PROJECT_LOCATION}

gcloud kms keys create $PRIMUS_SIGNING_KEY \
  --keyring=$PRIMUS_SIGNING_KEYRING \
  --purpose=asymmetric-signing \
  --default-algorithm=ec-sign-p256-sha256 \
  --location=${PRIMUS_PROJECT_LOCATION}

Para o Artifact Registry, é esperado um nome de imagem completo, como $LOCATION/$PROJECT/$REPOSITORY/$IMAGE_NAME. Você pode fazer upload de qualquer imagem de contêiner para o repositório para armazenamento de assinaturas.

export COSIGN_REPOSITORY=us-docker.pkg.dev/${PRIMUS_PROJECT_ID}/${PRIMUS_COSIGN_REPOSITORY}/demo

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 do contêiner enviadas para o $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"

A Cosign é uma ferramenta poderosa com vários recursos de assinatura. Para nosso caso de uso, só precisamos que a Cosign assine com um par de chaves. A assinatura sem chave de coassinatura não é compatível com esse recurso de imagem de contêiner assinada.

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

Assine com um par de chaves local gerado pelo Cosign.
Assinar com um par de chaves armazenado em outro lugar (por exemplo, em um KMS).

Gere um par de chaves no Cosign se você ainda não tiver um. Consulte Como assinar com chaves autogerenciadas para mais detalhes. Aqui, especificamos as duas maneiras (localmente e usando o provedor do KMS) de gerar o par de chaves e assinar a carga de trabalho. Siga uma dessas maneiras para assinar o contêiner da carga de trabalho.

// 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> por gcpkms://projects/$PRIMUS_PROJECT_ID/locations/global/keyRings/$PRIMUS_SIGNING_KEYRING/cryptoKeys/$PRIMUS_SIGNING_KEY/cryptoKeyVersions/$PRIMUS_SIGNING_KEYVERSION.

<provider> : refere-se à solução do KMS que você está usando.
<key> : refere-se ao caminho da chave no KMS.

Extraia 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

Assine a carga de trabalho usando a Cosign. Fazer a codificação base64 sem padding na chave pública

PUB=$(cat pub.pem | openssl base64)

// Remove spaces and trailing "=" signs.
PUB=$(echo $PUB | tr -d '[:space:]' | sed 's/[=]*$//')

Assine a carga de trabalho usando a 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 do KMS, siga o formato de URI específico do suporte do KMS do Sigstore. Ao se referir a uma chave gerada pela Cosign, use cosign.key.
$IMAGE_REFERENCE [OBRIGATÓRIO] especifica qual imagem do contêiner assinar. O formato de IMAGE_REFERENCE pode ser identificado por tag ou resumo de 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 a chave pública e os algoritmos de assinatura ao payload da assinatura.

dev.cosignproject.cosign/sigalg SOMENTE aceita três valores:
RSASSA_PSS_SHA256: algoritmo RSASSA com preenchimento PSS e resumo SHA256.
RSASSA_PKCS1V15_SHA256: algoritmo RSASSA com preenchimento PKCS#1 v1.5 e 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 pela Cosign.

Fazer upload de assinaturas para o repositório do Docker

A assinatura de coassinatura vai fazer o upload automático das assinaturas para o COSIGN_REPOSITORY. especificado

4. Autorizar e executar a carga de trabalho

Autorizar a carga de trabalho

Nesta etapa, vamos configurar o provedor de identidade da carga de trabalho no pool de identidades 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 é validar a impressão digital da assinatura da imagem da carga de trabalho em relação à impressão digital da chave pública de assinatura. 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 de carga de trabalho sem precisar atualizar a política de WIP com o resumo de 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

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

gcloud compute instances create ${WORKLOAD_VM} \
 --confidential-compute-type=SEV \
 --shielded-secure-boot \
 --maintenance-policy=MIGRATE \
 --scopes=cloud-platform \
 --zone=${SECUNDUS_PROJECT_ZONE} \
 --project=${SECUNDUS_PROJECT_ID} \
 --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 será 3, porque é o número de pessoas de Seattle listadas no arquivo primus_customer_list.csv.

5. Limpeza

Este é o script que pode ser usado para limpar os recursos criados como parte deste codelab. Como parte dessa limpeza, os seguintes recursos serão excluídos:

Bucket de armazenamento de entrada do banco Primus ($PRIMUS_INPUT_STORAGE_BUCKET).
Conta de serviço do banco Primus ($PRIMUS_SERVICEACCOUNT).
Registro de artefatos do Primus Bank, que contém assinaturas de imagem ($PRIMUS_COSIGN_REPOSITORY).
Pool de identidade da 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 de computação de carga de trabalho.
Bucket de armazenamento de resultados do Secundus Bank ($SECUNDUS_RESULT_STORAGE_BUCKET).
Registro de artefatos do Secundus Bank ($SECUNDUS_ARTIFACT_REGISTRY).
VM de carga de trabalho do Secundus Bank ($WORKLOAD_VM).

./cleanup.sh

Se você já tiver terminado 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 de cima. Isso vai programar o projeto para exclusão.

Parabéns

Parabéns, você concluiu o codelab.

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

Qual é a próxima etapa?

Confira alguns desses codelabs semelhantes: