Codelab de imagens de contêiner assinadas

1. Visão geral

Este codelab se baseia no codelab do Confidential Space. Suporte a imagens de contêiner assinadas 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 identidades da carga de trabalho (WIP, na sigla em inglês).

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

Usabilidade aprimorada: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 imagens diretamente, os proprietários de recursos precisam atualizar as políticas com um resumo de imagem sempre que autorizam uma nova imagem. Ao usar assinaturas de imagem, a política contém uma impressão digital de chave pública, cuja chave privada correspondente é de propriedade do colaborador/auditor e usada para assinar as imagens auditadas.
Para alguns modelos de segurança, é mais conveniente referenciar uma chave de assinatura de imagem confiável 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 vai causar 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 verificação de atestado e pelo WIP. O serviço de verificaçã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 reforçada:o uso de assinaturas de imagens de contêiner permite delegar um certo nível 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 de contêiner atendem a uma política. O serviço de verificação de atestado 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 por ela. Assim, a camada extra de indireção fornecida pela assinatura de imagens 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 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 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 Confidential Space com suporte a imagens de contêiner assinadas

Neste codelab, mostramos como usar o Confidential Space 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

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)
Conhecimentos básicos sobre o Sigstore cosign
Conhecimento básico do Google Compute Engine ( codelab), VM confidencial, contêineres 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, o Primus Bank será o auditor e o proprietário do recurso, responsável pelo seguinte:

Configurando os recursos necessários com dados de amostra.
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.
Configurando a política de WIP para proteger os dados dos clientes.

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

Configurando os recursos necessários para armazenar o resultado.
Escrever o código da carga de trabalho.
Publicar a imagem da carga de trabalho.
Executar a carga de trabalho no Confidential Space com suporte a imagens de contêiner assinadas.

O Secundus Bank vai desenvolver e publicar uma carga de trabalho que vai consultar dados do cliente armazenados em um bucket do Cloud Storage e pertencentes ao Primus Bank. O Primus Bank vai 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 dessa execução de 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 várias variáveis que você precisa definir com valores adequados para seu projeto do GCP. Os comandos neste codelab pressupõem 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 banco Primus. 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 declaraçõ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 atestado.
$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 ver 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 pelo auditor/colaboradores de dados (por exemplo, o banco primus neste caso).

Configure o seguinte no projeto Secundus:

$SECUNDUS_ARTIFACT_REGISTRY: o Artifact Registry em que 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 com 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 processo a seguir é realizado usando os recursos configurados:

A carga de trabalho solicita um token de acesso geral do Google para o $PRIMUS_SERVICEACCOUNT da 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 da carga de trabalho no token do serviço Attestation Verifier corresponderem à condição de atributo no WIP, ele vai 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 a imagens de contêiner assinadas, o seguinte processo é 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 atestado 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 da 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 do serviço de verificação de atestado corresponderem à condição de atributo no WIP, ele vai 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 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 recursos novos deste 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 do Cosign.

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árias. 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 por colaboradores de dados (banco Primus neste codelab), e o operador da carga de trabalho (banco Secundus neste caso) vai executá-la.

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

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 deste 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 a seguir para definir os nomes de 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 aqui.

Configurar recursos do banco Primus

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

Bucket do Cloud Storage ($PRIMUS_INPUT_STORAGE_BUCKET) para armazenar o arquivo de dados do cliente criptografados 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 identidades 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 Identidade da carga de trabalho.

./setup_primus_bank_resources.sh

Configurar recursos do banco Secundus

Como parte desta etapa, você vai configurar os recursos de nuvem necessários para o banco Secundus. Execute o script a seguir para configurar os recursos do banco Secundus. Como parte dessas etapas, os recursos mencionados 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 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 seguinte script 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.

Essa 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 $SECUNDUS_RESULT_STORAGE_BUCKET do Cloud Storage.

./create_workload_serviceaccount.sh

Criar carga de trabalho

Como parte desta 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 (dos dados do cliente do banco Primus) de um local geográfico fornecido como 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 necessários. Aqui está o código da carga de trabalho usado neste codelab.
Crie um binário Go e um Dockerfile para criar uma imagem Docker do código da carga de trabalho. Aqui está o Dockerfile usado neste codelab.
Crie e publique a imagem Docker no Artifact Registry ($SECUNDUS_ARTIFACT_REGISTRY) de propriedade do banco Secundus.
Conceda 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 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. Por padrão, o Cosign armazena as assinaturas 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 em OCI, como Docker Hub e AWS CodeArtifact, de acordo com sua preferência.

Crie 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=${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. É possível fazer upload de qualquer imagem de contêiner para o repositório de 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 imagens 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 poderosa com vários recursos de assinatura. Para nosso caso de uso, só precisamos que o Cosign assine com um par de chaves. A assinatura sem chave do Cosign 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.
Assine com um par de chaves armazenado em outro lugar (por exemplo, em um KMS).

Gere um par de chaves no Cosign se você não tiver um. Consulte Assinatura 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 de 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> : se refere à solução de KMS que você está usando
<key> : refere-se ao caminho da chave no KMS.

Recupere 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 o Cosign. Faça 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 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 em Suporte do 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 assinar. O formato de IMAGE_REFERENCE pode ser identificado por tag ou 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 [REQUIRED] especifica anotações anexadas ao payload da assinatura. Para imagens de contêiner assinadas do 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 um resumo SHA256.
RSASSA_PKCS1V15_SHA256: algoritmo RSASSA com preenchimento PKCS#1 v1.5 e 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.

Fazer upload de assinaturas para o repositório do Docker

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

4. Autorizar e executar a carga de trabalho

Autorizar carga de trabalho

Como parte desta etapa, vamos configurar o provedor de identidade de 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 é 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 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 dessa etapa, vamos executar a carga de trabalho em uma VM confidencial. Os argumentos obrigatórios do TEE são transmitidos usando a flag de metadados. Os argumentos do 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 deve ser 3, já que esse é o número de pessoas de Seattle listadas no arquivo primus_customer_list.csv.

5. Limpeza

Aqui está 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 imagens ($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 da 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á terminou de explorar, considere excluir o projeto.

Acesse o Console do Cloud Platform.
Selecione o projeto que você quer encerrar e clique em "Excluir" na parte de cima. 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 codelabs semelhantes: