Codelab de imágenes de contenedor firmadas

1. Descripción general

Este codelab se basa en el codelab de espacio confidencial. La compatibilidad con imágenes de contenedores firmadas brinda la opción de autenticar un contenedor con una clave pública certificada en lugar de especificar un resumen de imagen en la política del grupo de Workload Identity (WIP).

Qué cambió con la compatibilidad con imágenes de contenedores firmadas en Confidential Space:

Usabilidad mejorada: Con la introducción de la función de imagen de contenedor firmada, ahora podemos pasar de un enfoque de resumen de imágenes de carga de trabajo a un enfoque de firma de contenedor para que los colaboradores o auditores autoricen una imagen.

  • Cuando se usan resúmenes de imágenes directamente, los propietarios de recursos deben actualizar sus políticas con un resumen de imágenes cada vez que autorizan una imagen nueva. Cuando se usan firmas de imagen, la política contiene una huella digital de clave pública, cuya clave privada correspondiente es propiedad del colaborador o auditor y se usa para firmar las imágenes auditadas.
  • Para algunos modelos de seguridad, es más conveniente hacer referencia a una clave de firma de imagen de confianza que actualizar una lista de valores de resumen de imagen nuevos.

Sin regresión de seguridad: Este enfoque de firma de contenedor no traerá ninguna regresión de seguridad sobre el enfoque de resumen de imágenes anterior, ya que los límites de confianza siguen siendo los mismos. En el enfoque de firma de contenedor, el propietario del recurso autoriza una clave de verificación especificando la huella digital de clave pública de confianza en la política de WIP, y el servicio de verificación de certificación y WIP realizan la verificación de autorización. El servicio de verificación de certificación verifica que la firma esté asociada con la carga de trabajo en ejecución, y la política de WIP verifica que la clave pública que declara el servicio esté autorizada por la política.

Seguridad sólida: El uso de firmas de imágenes de contenedores permite delegar cierta confianza al firmante de imágenes. Cuando se especifica la huella digital de la clave pública de un firmante de confianza en la política de certificación, el propietario del recurso autoriza a ese firmante a hacer recomendaciones sobre qué imágenes de contenedor cumplen con una política. El servicio de verificación de certificación verifica que la firma esté asociada con la carga de trabajo en ejecución, y la política verifica que la clave pública que creó la firma esté autorizada por la política. De esta manera, la capa adicional de indirección que proporciona la firma de imágenes mantiene las sólidas garantías de seguridad de Confidential Space.

La única diferencia entre estos enfoques es que el último usa una capa adicional de indirección en la que las imágenes de la carga de trabajo se autorizan con una clave de firma. Esto no introduce ninguna vulnerabilidad de seguridad nueva porque los límites de confianza siguen siendo los mismos.

Qué aprenderás

En este codelab, aprenderás a usar una firma de imagen de contenedor para autorizar el acceso a recursos protegidos:

  • Cómo firmar una imagen de contenedor auditada con cosign
  • Cómo subir firmas de imágenes de contenedor a registros de OCI para el descubrimiento y el almacenamiento de firmas
  • Cómo configurar los recursos de la nube necesarios para ejecutar Confidential Space
  • Cómo ejecutar la carga de trabajo en un espacio confidencial con la compatibilidad con imágenes de contenedores firmadas

En este codelab, se muestra cómo usar Confidential Space para certificar de forma remota una imagen de contenedor firmada por una clave de confianza que se ejecuta en Google Compute Engine.

Requisitos

Roles involucrados en un Confidential Space con una imagen de contenedor firmada

En este codelab, Primus Bank será el auditor y el propietario de los recursos, y será responsable de lo siguiente:

  1. Configura los recursos necesarios con datos de muestra.
  2. Auditar el código de la carga de trabajo
  3. Usar cosign para firmar la imagen de la carga de trabajo
  4. Subir la firma a un repositorio
  5. Configura la política de WIP para proteger los datos de los clientes.

Secundus Bank será el autor y operador de la carga de trabajo, y será responsable de lo siguiente:

  1. Configura los recursos necesarios para almacenar el resultado.
  2. Escribir el código de la carga de trabajo
  3. Publica la imagen de la carga de trabajo.
  4. Ejecutar la carga de trabajo en Confidential Space con compatibilidad con imágenes de contenedor firmadas

El Secundus Bank desarrollará y publicará una carga de trabajo que consultará los datos de los clientes almacenados en un bucket de almacenamiento en la nube que pertenece al Primus Bank. Primus Bank auditará la carga de trabajo, firmará la imagen del contenedor y configurará las políticas de WIP para permitir el acceso a sus datos por parte de cargas de trabajo aprobadas. El resultado de esta ejecución de la carga de trabajo se almacenará en un bucket de almacenamiento en la nube propiedad del banco Secundus.

Recursos involucrados en la configuración de un espacio confidencial

En este codelab, se hace referencia a varias variables que debes establecer en valores adecuados para tu proyecto de GCP. En los comandos de este codelab, se supone que se configuraron estas variables. (por ejemplo, se puede usar export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket' para establecer el nombre del bucket de almacenamiento de entrada del banco Primus). Si no se establecieron las variables de resource-names, se generará en función del ID de proyecto de GCP.

Configura lo siguiente en el proyecto Primus:

  • $PRIMUS_INPUT_STORAGE_BUCKET: Es el bucket que almacena el archivo de datos del cliente.
  • $PRIMUS_WORKLOAD_IDENTITY_POOL: Es el grupo de Workload Identity (WIP) que valida los reclamos.
  • $PRIMUS_WIP_PROVIDER: Es el proveedor del grupo de Workload Identity que incluye la condición de autorización que se usará para los tokens firmados por el servicio de Verificador de Certificación.
  • $PRIMUS_SERVICEACCOUNT: Es la cuenta de servicio que usa $PRIMUS_WORKLOAD_IDENTITY_POOL para acceder a los recursos protegidos. En este paso, tiene permiso para ver los datos del cliente almacenados en el bucket $PRIMUS_INPUT_STORAGE_BUCKET.
  • $PRIMUS_ENC_KEY: Es la clave de KMS que se usa para encriptar los datos almacenados en $PRIMUS_INPUT_STORAGE_BUCKET.

Recursos nuevos en este codelab:

  • $PRIMUS_COSIGN_REPOSITORY: Artifact Registry para almacenar firmas de imágenes de cargas de trabajo.
  • $PRIMUS_SIGNING_KEY: Es la clave de KMS que usan los auditores o colaboradores de datos para firmar la imagen de la carga de trabajo (p. ej., el banco Primus en este caso).

Configura lo siguiente en el proyecto Secundus:

  • $SECUNDUS_ARTIFACT_REGISTRY: Es el registro de artefactos al que se enviará la imagen de Docker de la carga de trabajo.
  • $WORKLOAD_IMAGE_NAME: Es el nombre de la imagen de Docker de la carga de trabajo.
  • $WORKLOAD_IMAGE_TAG: Es la etiqueta de la imagen de Docker de la carga de trabajo.
  • $WORKLOAD_SERVICEACCOUNT: La cuenta de servicio que tiene permiso para acceder a la VM confidencial que ejecuta la carga de trabajo.
  • $SECUNDUS_RESULT_BUCKET: Es el bucket que almacena los resultados de la carga de trabajo.

Otros recursos:

  • primus_customer_list.csv contiene los datos del cliente. Subiremos estos datos a $PRIMUS_INPUT_STORAGE_BUCKET y crearemos una carga de trabajo que los consultará.

Flujo de trabajo existente

Cuando ejecutas la carga de trabajo en Confidential Space, se lleva a cabo el siguiente proceso con los recursos configurados:

  1. La carga de trabajo solicita un token de acceso general de Google para el $PRIMUS_SERVICEACCOUNT del WIP. Ofrece un token de servicio de verificador de certificación con reclamos de entorno y carga de trabajo.
  2. Si los reclamos de medición de la carga de trabajo en el token de servicio del verificador de certificación coinciden con la condición del atributo en el WIP, muestra el token de acceso para $PRIMUS_SERVICEACCOUNT..
  3. La carga de trabajo usa el token de acceso de la cuenta de servicio asociado con $PRIMUS_SERVICEACCOUNT para acceder a los datos del cliente en el bucket $PRIMUS_INPUT_STORAGE_BUCKET.
  4. La carga de trabajo realiza una operación en esos datos.
  5. La carga de trabajo usa la cuenta de servicio $WORKLOAD_SERVICEACCOUNT para escribir los resultados de esa operación en el bucket $SECUNDUS_RESULT_STORAGE_BUCKET.

Nuevo flujo de trabajo con compatibilidad con contenedores firmados

La compatibilidad con contenedores firmados se integrará en el flujo de trabajo existente, como se destaca a continuación. Cuando ejecutas la carga de trabajo en Confidential Space con compatibilidad con imágenes de contenedores firmadas, se realiza el siguiente proceso con los recursos configurados:

  1. Confidential Space descubre cualquier firma de contenedor relacionada con la imagen de carga de trabajo en ejecución actual y la envía al verificador de certificación. El verificador de certificación verifica la firma y, luego, incluye las firmas válidas en las declaraciones de certificación.
  2. La carga de trabajo solicita un token de acceso general de Google para el $PRIMUS_SERVICEACCOUNT del WIP. Ofrece un token de servicio de verificador de certificación con reclamos de entorno y carga de trabajo.
  3. Si las reclamaciones de firma del contenedor en el token de servicio del verificador de certificación coinciden con la condición del atributo en el WIP, se muestra el token de acceso para $PRIMUS_SERVICEACCOUNT.
  4. La carga de trabajo usa el token de acceso de la cuenta de servicio asociado con $PRIMUS_SERVICEACCOUNT para acceder a los datos del cliente en el bucket $PRIMUS_INPUT_STORAGE_BUCKET.
  5. La carga de trabajo realiza una operación en esos datos.
  6. La carga de trabajo usa $WORKLOAD_SERVICEACCOUNT para escribir los resultados de esa operación en el bucket $SECUNDUS_RESULT_STORAGE_BUCKET.

2. Configura recursos de Cloud

Como parte de la configuración de Confidential Space, primero crearás los recursos de nube necesarios en los proyectos de GCP del banco Primus y Secundus. Estos son los recursos nuevos de este codelab:

En el proyecto Primus, haz lo siguiente:

  • Clave de firma de KMS que se usa para firmar cargas de trabajo de Secundus después de auditar el código.
  • Repositorio de Artifact Registry para almacenar las firmas de Cosign

No hay recursos nuevos en el proyecto Secundus. Una vez que se configuren estos recursos, crearás una cuenta de servicio para la carga de trabajo con los roles y permisos necesarios. Luego, crearás una imagen de carga de trabajo y el auditor, el banco Primus, la firmará. Luego, los colaboradores de datos (el banco Primus en este codelab) autorizarán la carga de trabajo, y el operador de carga de trabajo (el banco Secundus en este caso) la ejecutará.

Como parte de la configuración de Confidential Space, crearás los recursos de nube necesarios en los proyectos de GCP Primus y Secundus.

Antes de comenzar

  • Clona este repositorio con el siguiente comando para obtener las secuencias de comandos necesarias que se usan como parte de este codelab.
git clone https://github.com/GoogleCloudPlatform/confidential-space
  • Cambia el directorio de este codelab.
cd confidential-space/codelabs/signed_container_codelab/scripts
  • Asegúrate de haber configurado los proyectos requeridos como se muestra a continuación.
export PRIMUS_PROJECT_ID=<GCP project id of primus bank>
export SECUNDUS_PROJECT_ID=<GCP project id of secundus bank>
  • Con este comando, establece las variables para los nombres de recursos mencionados anteriormente. Puedes anular los nombres de los recursos con estas variables (p. ej., export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket').
  • Ejecuta la siguiente secuencia de comandos para establecer los nombres de las variables restantes en valores basados en el ID de tu proyecto para los nombres de los recursos.
source config_env.sh
  • Instala cosign siguiendo las instrucciones que se indican aquí.

Configura los recursos del banco Primus

Como parte de este paso, configurarás los recursos de nube necesarios para el banco Primus. Ejecuta la siguiente secuencia de comandos para configurar los recursos del banco Primus. Como parte de estos pasos, se crearán los siguientes recursos:

  • Bucket de almacenamiento en la nube ($PRIMUS_INPUT_STORAGE_BUCKET) para almacenar el archivo de datos de clientes encriptados del banco Primus.
  • Clave de encriptación ($PRIMUS_ENC_KEY) y llavero ($PRIMUS_ENC_KEYRING) en KMS para encriptar el archivo de datos del banco Primus
  • Grupo de Workload Identity ($PRIMUS_WORKLOAD_IDENTITY_POOL) para validar los reclamos en función de las condiciones de los atributos configurados en su proveedor.
  • Cuenta de servicio ($PRIMUS_SERVICEACCOUNT) adjunta al grupo de identidades para cargas de trabajo ($PRIMUS_WORKLOAD_IDENTITY_POOL) mencionado anteriormente con el siguiente acceso de IAM:
  • roles/cloudkms.cryptoKeyDecrypter para desencriptar los datos con la clave de KMS.
  • objectViewer para leer datos del bucket de Cloud Storage
  • roles/iam.workloadIdentityUser para conectar esta cuenta de servicio al grupo de identidades para cargas de trabajo
./setup_primus_bank_resources.sh

Configura los recursos bancarios de Secundus

Como parte de este paso, configurarás los recursos de nube necesarios para el banco Secundus. Ejecuta la siguiente secuencia de comandos para configurar los recursos del banco Secundus. Como parte de estos pasos, se crearán los siguientes recursos:

  • Bucket de Cloud Storage ($SECUNDUS_RESULT_STORAGE_BUCKET) para almacenar el resultado de la ejecución de la carga de trabajo del banco Secundus.
./setup_secundus_bank_resources.sh

3. Crea y firma una carga de trabajo

Crea una cuenta de servicio de carga de trabajo

Ahora, crearás una cuenta de servicio para la carga de trabajo con los roles y permisos necesarios. Ejecuta la siguiente secuencia de comandos para crear una cuenta de servicio de carga de trabajo en el proyecto del banco Secundus. La VM que ejecuta la carga de trabajo usará esta cuenta de servicio.

  • Esta cuenta de servicio de la carga de trabajo ($WORKLOAD_SERVICEACCOUNT) tendrá los siguientes roles:
  • confidentialcomputing.workloadUser para obtener un token de certificación
  • logging.logWriter para escribir registros en Cloud Logging.
  • objectViewer para leer datos del bucket de Cloud Storage $PRIMUS_INPUT_STORAGE_BUCKET.
  • objectAdmin para escribir el resultado de la carga de trabajo en el bucket de Cloud Storage $SECUNDUS_RESULT_STORAGE_BUCKET.
./create_workload_serviceaccount.sh

Crea una carga de trabajo

Como parte de este paso, crearás una imagen de Docker de carga de trabajo. La carga de trabajo que se usa en este codelab es una app de Go simple basada en la CLI que cuenta a los clientes (de los datos de clientes del banco Primus) desde una ubicación geográfica proporcionada en el argumento. Ejecuta la siguiente secuencia de comandos para crear una carga de trabajo en la que se realicen los siguientes pasos:

  • Crea un Artifact Registry($SECUNDUS_ARTIFACT_REGISTRY) que pertenezca al banco Secundus.
  • Actualiza el código de la carga de trabajo con los nombres de los recursos necesarios. Aquí se muestra el código de la carga de trabajo que se usa en este codelab.
  • Compila el binario de Go y crea un Dockerfile para compilar una imagen de Docker del código de la carga de trabajo. Aquí está el Dockerfile que se usa para este codelab.
  • Compila y publica la imagen de Docker en Artifact Registry ($SECUNDUS_ARTIFACT_REGISTRY) que pertenece al banco Secundus.
  • Otorga permiso de lectura a $WORKLOAD_SERVICEACCOUNT para $SECUNDUS_ARTIFACT_REGISTRY. Esto es necesario para que el contenedor de la carga de trabajo extraiga la imagen de Docker de la carga de trabajo de Artifact Registry.
./create_workload.sh

Firma la carga de trabajo

Usaremos Cosign para firmar la imagen de la carga de trabajo. De forma predeterminada, Cosign almacenará las firmas en el mismo repositorio que la imagen que firma. Para especificar un repositorio diferente para las firmas, puedes configurar la variable de entorno COSIGN_REPOSITORY.

Aquí, usaremos Artifact Registry como ejemplo. También puedes elegir otros registros basados en OCI, como Docker Hub o AWS CodeArtifact, según tus preferencias.

  1. Crea un repositorio de Docker de Artifact Registry.
gcloud config set project $PRIMUS_PROJECT_ID

gcloud artifacts repositories create $PRIMUS_COSIGN_REPOSITORY \
  --repository-format=docker --location=${PRIMUS_PROJECT_REPOSITORY_REGION}
  1. Crea un llavero de claves y una clave en KMS para firmar una imagen de carga de trabajo.
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}
  1. Para Artifact Registry, se espera un nombre de imagen completo, como $LOCATION/$PROJECT/$REPOSITORY/$IMAGE_NAME. Puedes subir cualquier imagen de contenedor al repositorio para el almacenamiento de firmas.
export COSIGN_REPOSITORY=us-docker.pkg.dev/${PRIMUS_PROJECT_ID}/${PRIMUS_COSIGN_REPOSITORY}/demo
  1. Otorga el rol de visor en el repositorio $PRIMUS_COSIGN_REPOSITORY a la cuenta de servicio $WORKLOAD_SERVICEACCOUNT. Esto permite que Confidential Space descubra cualquier firma de imagen de contenedor que se haya subido a $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"

Cosign es una herramienta potente con varias funciones de firma. En nuestro caso de uso, solo requerimos que Cosign firme con un par de claves. La firma sin llave de Cosign no es compatible con esta función de imagen de contenedor firmada.

Cuando se firma con un par de claves, hay dos opciones:

  1. Firma con un par de claves local que genera Cosign.
  2. Firmar con un par de claves almacenado en otro lugar (por ejemplo, en un KMS)
  1. Genera un par de claves en Cosign si aún no tienes uno. Consulta Cómo firmar con claves autoadministradas para obtener más detalles. Aquí especificamos ambas formas (localmente y con el proveedor de KMS) de generar el par de claves y firmar la carga de trabajo. Sigue una de estas formas para firmar el contenedor de la carga de trabajo.
// 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

En el comando anterior, reemplaza <provider>://<key> por gcpkms://projects/$PRIMUS_PROJECT_ID/locations/global/keyRings/$PRIMUS_SIGNING_KEYRING/cryptoKeys/$PRIMUS_SIGNING_KEY/cryptoKeyVersions/$PRIMUS_SIGNING_KEYVERSION.

  • <provider> : Se refiere a la solución de KMS que usas.
  • <clave> : Se refiere a la ruta de acceso de la clave en KMS.
  1. Recupera la clave pública para la verificación.
// 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. Firma la carga de trabajo con Cosign. Realiza la codificación en base64 sin relleno en la clave pública.
PUB=$(cat pub.pem | openssl base64)

// Remove spaces and trailing "=" signs.
PUB=$(echo $PUB | tr -d '[:space:]' | sed 's/[=]*$//')
  1. Firma la carga de trabajo con Cosign con la clave pública exportada y los algoritmos de firma adjuntos.
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 [OBLIGATORIO] especifica qué clave de firma se debe usar. Cuando te refieras a una clave administrada por un proveedor de KMS, sigue el formato de URI específico de la compatibilidad de Sigstore con KMS. Cuando te refieras a una clave generada por Cosign, usa cosign.key.
  • $IMAGE_REFERENCE [OBLIGATORIO] especifica qué imagen de contenedor se debe firmar. El formato de IMAGE_REFERENCE se puede identificar por etiqueta o resumen de imagen. Por ejemplo: 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 [OBLIGATORIO] especifica las anotaciones adjuntas a la carga útil de la firma. En el caso de las imágenes de contenedores firmadas de Confidential Space, los algoritmos de clave pública y firma deben adjuntarse a la carga útil de la firma.
  • dev.cosignproject.cosign/sigalg SOLO acepta tres valores:
  • RSASSA_PSS_SHA256: Algoritmo RSASSA con relleno PSS con un resumen SHA256.
  • RSASSA_PKCS1V15_SHA256: Algoritmo RSASSA con relleno PKCS#1 v1.5 con un resumen SHA256.
  • ECDSA_P256_SHA256: ECDSA en la curva P-256 con un resumen SHA256 Este también es el algoritmo de firma predeterminado para los pares de claves generados por Cosign.
  1. Sube firmas al repositorio de Docker

La firma de Cosign subirá automáticamente las firmas a la COSIGN_REPOSITORY. especificada.

4. Autoriza y ejecuta la carga de trabajo

Autoriza la carga de trabajo

Como parte de este paso, configuraremos el proveedor de identidad de la carga de trabajo en el grupo de identidades para cargas de trabajo ($PRIMUS_WORKLOAD_IDENTITY_POOL). Hay condiciones de atributos configuradas para la identidad de la carga de trabajo, como se muestra a continuación. Una de las condiciones es validar la huella digital de la firma de la imagen de la carga de trabajo en función de la huella digital de la clave pública de firma. Con esta condición de atributo, cuando Secundus Bank lanza una nueva imagen de carga de trabajo, Primus Bank audita el código de la carga de trabajo y firma la nueva imagen de carga de trabajo sin necesidad de actualizar la política de WIP con el resumen de la imagen.

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))"

Ejecutar carga de trabajo

Como parte de este paso, ejecutaremos la carga de trabajo en Confidential VM. Los argumentos de TEE obligatorios se pasan con la marca de metadatos. Los argumentos del contenedor de la carga de trabajo se pasan con la parte "tee-cmd" de la marca. La carga de trabajo está codificada para publicar su resultado en $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

En el proyecto Secundus, consulta los resultados de la carga de trabajo.

gcloud config set project $SECUNDUS_PROJECT_ID

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

El resultado debe ser 3, ya que esta es la cantidad de personas de Seattle que aparecen en el archivo primus_customer_list.csv.

5. Limpieza

Aquí se encuentra la secuencia de comandos que se puede usar para limpiar los recursos que creamos como parte de este codelab. Como parte de esta limpieza, se borrarán los siguientes recursos:

  • Bucket de almacenamiento de entrada del banco Primus ($PRIMUS_INPUT_STORAGE_BUCKET).
  • Cuenta de servicio del banco Primus ($PRIMUS_SERVICEACCOUNT).
  • Es el registro de artefactos de Primus Bank que contiene firmas de imágenes ($PRIMUS_COSIGN_REPOSITORY).
  • Grupo de identidad de cargas de trabajo de Primus Bank ($PRIMUS_WORKLOAD_IDENTITY_POOL).
  • Cuenta de servicio de carga de trabajo del Banco Secundus ($WORKLOAD_SERVICEACCOUNT).
  • Instancia de procesamiento de cargas de trabajo
  • Bucket de almacenamiento de resultados del Banco Secundus ($SECUNDUS_RESULT_STORAGE_BUCKET).
  • Registro de artefactos del Banco Secundus ($SECUNDUS_ARTIFACT_REGISTRY).
  • VM de carga de trabajo del Banco Secundus ($WORKLOAD_VM).
./cleanup.sh

Si ya terminaste de explorar, considera borrar tu proyecto.

  • Ve a la consola de Cloud Platform.
  • Selecciona el proyecto que deseas cerrar y, luego, haz clic en "Borrar" en la parte superior. De esta forma, se programará la eliminación del proyecto.

Felicitaciones

¡Felicitaciones! Completaste el codelab correctamente.

Aprendiste a aprovechar la función de imagen de contenedor firmada para mejorar la usabilidad de Confidential Space.

¿Qué sigue?

Consulta algunos de estos codelabs similares…

Lecturas adicionales