Codelab de imágenes de contenedor firmadas

1. Descripción general

Este codelab se basa en el codelab de Confidential Space. Se agregó compatibilidad con imágenes de contenedor firmadas, lo que permite autenticar un contenedor con una clave pública certificada en lugar de especificar el resumen de la imagen en la política del grupo de identidades para cargas de trabajo (WIP).

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

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

  • Cuando se usan resúmenes de imágenes directamente, los propietarios de los recursos deben actualizar sus políticas con un resumen de imágenes cada vez que autorizan una imagen nueva. Cuando se usan firmas de imágenes, 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.
  • En algunos modelos de seguridad, hacer referencia a una clave de firma de imágenes de confianza es más conveniente que actualizar una lista de valores de resúmenes de imágenes nuevos.

Sin regresión de seguridad: Este enfoque de firma de contenedor no generará ninguna regresión de seguridad en comparación con el enfoque anterior de resúmenes de imágenes, ya que los límites de confianza siguen siendo los mismos. En el enfoque de firma del contenedor, el propietario del recurso autoriza una clave de verificación especificando la huella digital de la clave pública de confianza en la política de WIP, y el Servicio de Verificación de Certificaciones y el WIP realizan la verificación de autorización. El Servicio de Verificación de Certificaciones verifica que la firma esté asociada a la carga de trabajo en ejecución, y la política de WIP verifica que la política autorice la clave pública que el servicio afirma.

Seguridad sólida: El uso de firmas de imágenes de contenedores permite delegar cierto nivel de confianza en el firmante de la imagen. 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 realizar respaldos 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 comprueba que la política autorice la clave pública que creó la firma. 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 cargas de trabajo se autorizan con una clave de firma. Esto no introduce nuevas vulnerabilidades de seguridad porque los límites de confianza siguen siendo los mismos.

Qué aprenderás

En este codelab, aprenderás a usar la firma de una 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 almacenamiento de firmas
  • Cómo configurar los recursos de nube necesarios para ejecutar Confidential Space
  • Cómo ejecutar la carga de trabajo en un Confidential Space con la compatibilidad de imágenes de contenedor firmadas

En este codelab, se muestra cómo usar Confidential Space para realizar una certificación remota de 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 del recurso, y será responsable de lo siguiente:

  1. Configuración de los recursos necesarios con datos de muestra
  2. Auditar el código de la carga de trabajo
  3. Usa cosign para firmar la imagen de la carga de trabajo.
  4. Subir la firma a un repositorio
  5. Se configura la política de WIP para proteger los datos del cliente.

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

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

El banco Secundus desarrollará y publicará una carga de trabajo que consultará los datos de los clientes almacenados en un bucket de Cloud Storage y que son propiedad del banco Primus. El banco Primus auditará la carga de trabajo, firmará la imagen del contenedor y configurará las políticas de WIP para permitir que las cargas de trabajo aprobadas accedan a sus datos. El resultado de esta ejecución de la carga de trabajo se almacenará en un bucket de Cloud Storage propiedad del banco Secundus.

Recursos involucrados en la configuración de Confidential Space

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 estas variables ya se configuraron. (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 configuraron las variables de los nombres de recursos, se generarán en función del ID del proyecto de GCP.

Configura lo siguiente en el proyecto de Primus:

  • $PRIMUS_INPUT_STORAGE_BUCKET: Es el bucket que almacena el archivo de datos del cliente.
  • $PRIMUS_WORKLOAD_IDENTITY_POOL: Es el grupo de identidades para cargas de trabajo (WIP) que valida las reivindicaciones.
  • $PRIMUS_WIP_PROVIDER: Es el proveedor del grupo de identidades para cargas de trabajo que incluye la condición de autorización para usar 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 que se almacenan 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: Es el Artifact Registry en el que se almacenan las firmas de imágenes de cargas de trabajo.
  • $PRIMUS_SIGNING_KEY: Es la clave de KMS que usa el auditor o los colaboradores de datos para firmar la imagen de la carga de trabajo (por ejemplo, el banco de Primus en este caso).

Configura lo siguiente en el proyecto Secundus:

  • $SECUNDUS_ARTIFACT_REGISTRY: Es el registro de artefactos en el 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: Es 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 consultará estos datos.

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 desde el WIP. Ofrece un token de servicio del verificador de certificación con reclamos de carga de trabajo y entorno.
  2. Si las declaraciones de medición de la carga de trabajo en el token del servicio de Attestation Verifier coinciden con la condición del atributo en el WIP, se 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 para 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 para imágenes de contenedor firmadas, se lleva a cabo el siguiente proceso con los recursos configurados:

  1. Confidential Space descubre las firmas de contenedor relacionadas con la imagen de la carga de trabajo en ejecución actual y las envía al verificador de certificación. El verificador de certificación verifica la firma y, luego, incluye las firmas válidas en los reclamos de certificación.
  2. La carga de trabajo solicita un token de acceso general de Google para el $PRIMUS_SERVICEACCOUNT desde el WIP. Ofrece un token de servicio del verificador de certificación con reclamos de carga de trabajo y entorno.
  3. Si las reclamaciones de firma del contenedor en el token del servicio de Attestation Verifier coinciden con la condición del atributo en el WIP, se devuelve 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 Cloud necesarios en los proyectos de GCP de los bancos Primus y Secundus. Estos son los recursos nuevos de este codelab:

En el proyecto de Primus, haz lo siguiente:

  • Es la 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 la 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 Cloud necesarios en los proyectos de GCP de 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 necesarios 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>
  • Establece las variables para los nombres de recursos mencionados anteriormente con este comando. 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 recursos.
source config_env.sh
  • Instala cosign siguiendo las instrucciones que se indican aquí.

Configura los recursos bancarios de 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 recursos que se mencionan a continuación:

  • Bucket de Cloud Storage ($PRIMUS_INPUT_STORAGE_BUCKET) para almacenar el archivo de datos del cliente encriptado 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 identidades para cargas de trabajo ($PRIMUS_WORKLOAD_IDENTITY_POOL) para validar las declaraciones en función de las condiciones de atributos configuradas 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 la 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 por parte del banco Secundus.
./setup_secundus_bank_resources.sh

3. Crea y firma la 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 requeridos. Ejecuta el siguiente script 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ía esta cuenta de servicio.

  • Esta cuenta de servicio de cargas 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 almacenamiento en la nube $PRIMUS_INPUT_STORAGE_BUCKET
  • objectAdmin para escribir el resultado de la carga de trabajo en el bucket de almacenamiento en la nube $SECUNDUS_RESULT_STORAGE_BUCKET
./create_workload_serviceaccount.sh

Crear 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 simple basada en CLI escrita en Go que cuenta los clientes (a partir de los datos de clientes del banco Primus) de una ubicación geográfica proporcionada como argumento. Ejecuta la siguiente secuencia de comandos para crear una carga de trabajo en la que se realizan los siguientes pasos:

  • Crea un registro de Artifact Registry($SECUNDUS_ARTIFACT_REGISTRY) propiedad del banco Secundus.
  • Actualiza el código de la carga de trabajo con los nombres de los recursos requeridos. Aquí se encuentra el código de la carga de trabajo que se usa para este codelab.
  • Compila el archivo binario de Go y crea un Dockerfile para compilar una imagen de Docker del código de la carga de trabajo. Aquí se encuentra el Dockerfile que se usa en este codelab.
  • Compila y publica la imagen de Docker en Artifact Registry ($SECUNDUS_ARTIFACT_REGISTRY) propiedad del banco Secundus.
  • Otorga permiso de lectura de $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 de carga de trabajo

Usaremos Cosign para firmar la imagen de la carga de trabajo. De forma predeterminada, Cosign almacenará las firmas en el mismo repo 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. En el caso de 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 visualizador 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 subida 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 múltiples funciones de firma. En nuestro caso de uso, solo necesitamos 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 firmas con un par de claves, tienes dos opciones:

  1. Firma con un par de claves local generado por 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 no tienes uno. Consulta Cómo firmar con claves autoadministradas para obtener más detalles. Aquí especificamos las dos formas (localmente y con el proveedor de KMS) para generar el par de claves y firmar la carga de trabajo. Sigue una de estas formas para firmar el contenedor de 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 lo 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.
  • <key> : Hace referencia a la ruta de acceso a 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 y los algoritmos de firma y clave pública exportados 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 Compatibilidad con KMS de Sigstore. Cuando hagas referencia a una clave generada por Cosign, usa cosign.key en su lugar.
  • $IMAGE_REFERENCE [OBLIGATORIO] especifica qué imagen de contenedor se firmará. El formato de IMAGE_REFERENCE se puede identificar por la etiqueta o el resumen de la 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 contenedor firmadas de Confidential Space, se requiere que los algoritmos de firma y clave pública se adjunten a la carga útil de la firma.
  • dev.cosignproject.cosign/sigalg SOLO acepta tres valores:
  • RSASSA_PSS_SHA256: Algoritmo RSASSA con relleno de PSS y un resumen SHA256.
  • RSASSA_PKCS1V15_SHA256: Algoritmo RSASSA con relleno PKCS#1 v1.5 y 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 cofirmante subirá automáticamente las firmas al COSIGN_REPOSITORY. especificado.

4. Autoriza y ejecuta la carga de trabajo

Autoriza la carga de trabajo

Como parte de este paso, configuraremos el proveedor de identidad para cargas de trabajo en el grupo de identidades para cargas de trabajo ($PRIMUS_WORKLOAD_IDENTITY_POOL). Hay condiciones de atributos configuradas para la identidad de 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 con 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 una Confidential VM. Los argumentos de TEE obligatorios se pasan con la marca de metadatos. Los argumentos para el contenedor de 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 debería ser 3, ya que esa 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 de Primus ($PRIMUS_INPUT_STORAGE_BUCKET).
  • Cuenta de servicio de Primus Bank ($PRIMUS_SERVICEACCOUNT).
  • Registro de artefactos de Primus Bank que contiene firmas de imágenes ($PRIMUS_COSIGN_REPOSITORY).
  • Es el grupo de identidades de cargas de trabajo de Primus Bank ($PRIMUS_WORKLOAD_IDENTITY_POOL).
  • Cuenta de servicio de la carga de trabajo de Secundus Bank ($WORKLOAD_SERVICEACCOUNT).
  • Instancia de procesamiento de carga de trabajo.
  • Bucket de almacenamiento de resultados de Secundus Bank ($SECUNDUS_RESULT_STORAGE_BUCKET).
  • Registro de artefactos de Secundus Bank ($SECUNDUS_ARTIFACT_REGISTRY).
  • VM de carga de trabajo de Secundus Bank ($WORKLOAD_VM).
./cleanup.sh

Si terminaste de explorar, considera borrar tu proyecto.

  • Ve a Cloud Platform Console.
  • Selecciona el proyecto que deseas cerrar y, luego, haz clic en "Borrar" en la parte superior para programar su eliminación.

Felicitaciones

¡Felicitaciones! Completaste el codelab correctamente.

Aprendiste a aprovechar la función de imágenes de contenedor firmadas para mejorar la usabilidad de Confidential Space.

¿Qué sigue?

Consulta algunos de estos codelabs similares…

Lecturas adicionales