Se usó la API de Cloud Translation para traducir esta página.

Codelab de imágenes de contenedor firmadas

1. Descripción general

Este codelab se basa en el codelab de Espacio confidencial. Compatibilidad con imágenes de contenedor firmadas a las que se les da la opción de 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 Workload Identity (WIP).

Qué cambió con la compatibilidad con imágenes de contenedor firmadas en Espacio confidencial:

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 al enfoque de firma de contenedor para los colaboradores o auditores que autorizan una imagen.

Cuando se usan directamente resúmenes de imágenes, los propietarios de recursos deben actualizar sus políticas con un resumen de imágenes cada vez que autoricen 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 pertenece al colaborador o auditor y se usa para firmar las imágenes auditadas.
Para algunos modelos de seguridad, hacer referencia a una clave de firma de imagen confiable es más conveniente que actualizar una lista de valores nuevos de resumen de imagen.

Sin regresión de seguridad: Este enfoque de firma de contenedor no generará ninguna regresión de seguridad con respecto al enfoque de resumen de imágenes anterior porque 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 la clave pública de confianza en la política de WIP. El servicio de verificador de certificación y el WIP realizan la verificación de autorización. El servicio de verificación de certificación comprueba que la firma esté asociada con la carga de trabajo en ejecución, y la política WIP comprueba que la clave pública declarada por el servicio esté autorizada por la política.

Seguridad sólida: El uso de firmas de imágenes de contenedor permite delegar algo de confianza al 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 recomendar qué imágenes de contenedor cumplen con una política. El servicio de verificador de certificación verifica que la firma esté asociada con la carga de trabajo en ejecución, y la política comprueba que la clave pública que creó la firma esté autorizada por la política. De este modo, 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 carga de trabajo se autorizan con una clave de firma. Esto no presenta 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 los registros de OCI para el descubrimiento y el almacenamiento de firmas
Cómo configurar los recursos de nube necesarios para ejecutar Confidential Space
Cómo ejecutar la carga de trabajo en un espacio confidencial con la compatibilidad con la imagen del contenedor firmada

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

Completa el codelab de Confidential Space
Un proyecto de Google Cloud Platform
Un navegador, como Chrome o Firefox
Estar familiarizado con editores de texto estándares de Linux, como Vim, Emacs o nano
Conocimientos básicos sobre el cosign de Sigstore
Conocimiento básico de Google Compute Engine ( codelab), Confidential VM, contenedores y repositorios remotos
Conocimientos básicos de Cloud KMS ( codelab)
Conocimientos básicos de las cuentas de servicio, la federación de identidades para cargas de trabajo y las condiciones de los atributos
Conocimientos básicos de Artifact Registry
Conocimientos básicos de firmas digitales

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:

Configuración de los recursos necesarios con datos de muestra.
Auditar el código de la carga de trabajo
Usa cosign para firmar la imagen de carga de trabajo.
Subir la firma a un repositorio
Configuración de 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:

Se están configurando los recursos necesarios para almacenar el resultado.
Escribir el código de la carga de trabajo
Publicación de la imagen de la carga de trabajo.
Ejecución de la carga de trabajo en Confidential Space con compatibilidad con imágenes de contenedor firmadas.

Secundus Bank desarrollará y publicará una carga de trabajo que consultará datos de clientes almacenados en un bucket de almacenamiento en la nube y que son propiedad de Primus Bank. Primus Bank 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 la ejecución de esta carga de trabajo se almacenará en un bucket de Cloud Storage que es propiedad de Secundus Bank.

Recursos involucrados en una configuración de Confidential Space

En este codelab, se hace referencia a una serie de variables que debes configurar con los valores adecuados para tu proyecto de GCP. En los comandos de este codelab, se supone que se establecieron 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 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 Workload Identity (WIP) que valida las reclamaciones.
$PRIMUS_WIP_PROVIDER: Es el proveedor del grupo de identidades para cargas de trabajo que incluye la condición de autorización para usar para los tokens firmados por el servicio de verificación 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, cuenta con 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: Artifact Registry para almacenar firmas de imágenes de carga de trabajo.
$PRIMUS_SIGNING_KEY: Es la clave de KMS que usan el auditor o los colaboradores de datos para firmar la imagen de la carga de trabajo (p. ej., un banco Primus en este caso).

Configura lo siguiente en el proyecto de Secundus:

$SECUNDUS_ARTIFACT_REGISTRY: Es el Artifact Registry 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: La cuenta de servicio que tiene permiso para acceder a la Confidential VM 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:

La carga de trabajo solicita al WIP un token de acceso general de Google para $PRIMUS_SERVICEACCOUNT. Ofrece un token de servicio del verificador de certificación con reclamaciones de cargas de trabajo y de entorno.
Si las reclamaciones de medición de cargas de trabajo en el token de servicio del verificador de certificación coinciden con la condición del atributo en el trabajo en curso, se muestra el token de acceso para $PRIMUS_SERVICEACCOUNT..
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.
La carga de trabajo realiza una operación en esos datos.
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 la compatibilidad de imagen de contenedor firmada, se lleva a cabo el siguiente proceso con los recursos configurados:

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 certificaciones verifica la firma y, además, incluye todas las firmas válidas en los reclamos de certificación.
La carga de trabajo solicita al WIP un token de acceso general de Google para $PRIMUS_SERVICEACCOUNT. Ofrece un token de servicio del verificador de certificación con reclamaciones de cargas de trabajo y de entorno.
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 trabajo en curso, se muestra el token de acceso para $PRIMUS_SERVICEACCOUNT.
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.
La carga de trabajo realiza una operación en esos datos.
La carga de trabajo usa el $WORKLOAD_SERVICEACCOUNT para escribir los resultados de esa operación en el bucket $SECUNDUS_RESULT_STORAGE_BUCKET.

2. Configura recursos en la nube

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

En el proyecto de Primus:

Clave de firma de KMS que se usa para firmar las 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 de Secundus. Una vez que estos recursos estén configurados, 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, Primus Bank, firmará la imagen de carga de trabajo. Luego, la carga de trabajo será autorizada por los colaboradores de datos (Primus Bank en este codelab) y el operador de la carga de trabajo (Secundus Bank 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 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

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>

Configura las variables para los nombres de los 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 variables restantes en valores basados en el ID del proyecto para los nombres de recursos.

$ source config_env.sh

Instala cosign con las instrucciones que se indican aquí.

Configura los recursos de Primus Bank

Como parte de este paso, configurarás los recursos en la nube necesarios para Primus Bank. 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 Cloud Storage ($PRIMUS_INPUT_STORAGE_BUCKET) para almacenar el archivo encriptado de datos de clientes de Primus Bank.
Clave de encriptación ($PRIMUS_ENC_KEY) y llavero de claves ($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 reclamaciones en función de las condiciones de atributos configuradas en el proveedor.
Cuenta de servicio ($PRIMUS_SERVICEACCOUNT) vinculada al grupo de identidades para cargas de trabajo mencionado anteriormente ($PRIMUS_WORKLOAD_IDENTITY_POOL) 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 Workload Identity.

$ ./setup_primus_bank_resources.sh

Configura los recursos del banco de Secundus

Como parte de este paso, configurarás los recursos en la nube necesarios para Secundus Bank. Ejecuta la siguiente secuencia de comandos para configurar los recursos del banco de Secundus. Como parte de este paso, 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

Crear 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 de Secundus Bank. La VM que ejecuta la carga de trabajo usará esta cuenta de servicio.

Esta cuenta de servicio de 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

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

Crear Artifact Registry($SECUNDUS_ARTIFACT_REGISTRY) que es propiedad del 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 para este codelab.
Compila el objeto 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 para este codelab.
Compila y publica la imagen de Docker en Artifact Registry ($SECUNDUS_ARTIFACT_REGISTRY), que es propiedad del banco Secundus.
Otorga a $WORKLOAD_SERVICEACCOUNT permiso de lectura para $SECUNDUS_ARTIFACT_REGISTRY. Esto es necesario para que el contenedor de carga de trabajo extraiga la imagen de Docker de la carga de trabajo desde Artifact Registry.

$ ./create_workload.sh

Firmar 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 en el que se encuentra la imagen que firma. Si quieres especificar un repositorio diferente para firmas, puedes establecer 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.

Crear 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=us

Crear 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=global

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

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

Otorga el rol de visualizador en el repositorio $PRIMUS_COSIGN_REPOSITORY a la cuenta de servicio $WORKLOAD_SERVICEACCOUNT. Esto permite que Confidential Space descubra las firmas de imágenes de contenedor subidas 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 solicitamos que Cosign se firme con un par de claves. La firma sin clave de firma no es compatible con esta función de imagen de contenedor firmada.

Cuando firmas con un par de claves, hay dos opciones:

Firma con un par de claves local generado por Cosign.
Firma con un par de claves almacenado en otro lugar (por ejemplo, en un KMS).

Genera un par de claves en Cosign si no tienes uno. Consulta cómo firmar con claves autoadministradas para obtener más detalles.

// 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 ejemplo anterior, reemplaza <provider>://<key> con 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> Se refiere a la ruta de la clave en KMS.

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

Firma la carga de trabajo con Cosign. Realiza la codificación en base64 unpadded en la clave pública

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

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

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 [REQUIRED] especifica qué clave de firma usar. Cuando hagas referencia a una clave administrada por un proveedor de KMS, sigue el formato de URI específico de la asistencia de 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 debe 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 [REQUIRED] especifica las anotaciones adjuntas a la carga útil de la firma. Para las imágenes de contenedor firmadas de Confidential Space, se debe adjuntar la clave pública y los algoritmos de firma a la carga útil de firma.

dev.cosignproject.cosign/sigalg SOLO acepta tres valores:
RSASSA_PSS_SHA256: Algoritmo de RSASSA con relleno de PSS con resumen SHA256
RSASSA_PKCS1V15_SHA256: Algoritmo de RSASSA con relleno PKCS#1 v1.5 con 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.

Subir firmas al repositorio de Docker

El signo Cosign subirá automáticamente las firmas al COSIGN_REPOSITORY. especificado

4. Autorizar y ejecutar cargas de trabajo

Autorizar carga de trabajo

Como parte de este paso, configuraremos el proveedor de identidades para cargas de trabajo en el grupo de identidades para cargas de trabajo ($PRIMUS_WORKLOAD_IDENTITY_POOL). Hay condiciones de atributos configuradas para Workload Identity, como se muestra a continuación. Una de las condiciones es validar la huella digital de la firma de la imagen de 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 Confidential VM. Los argumentos necesarios del TEE se pasan usando la marca de metadatos. Los argumentos del contenedor de carga de trabajo se pasan con “tee-cmd”. parte de la marca. La carga de trabajo está codificada para publicar su resultado en $SECUNDUS_RESULT_STORAGE_BUCKET.

$ gcloud config set project $SECUNDUS_PROJECT_ID

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

Ver resultados

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 esta es la cantidad de personas de Seattle que aparecen en el archivo primus_customer_list.csv.

5. Realiza una 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 bancaria de Primus ($PRIMUS_SERVICEACCOUNT)
Artifact Registry de Primus Bank, que contiene firmas de imágenes ($PRIMUS_COSIGN_REPOSITORY).
Grupo de identidades para cargas de trabajo de Primus Bank ($PRIMUS_WORKLOAD_IDENTITY_POOL).
Cuenta de servicio de 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).
Artifact Registry de Secundus Bank ($SECUNDUS_ARTIFACT_REGISTRY).

// run the clean up script to delete the resources created as part of this codelab.
$ ./cleanup.sh

Si terminaste de explorar, considera borrar tu proyecto.

Ve a la consola de Google Cloud.
Selecciona el proyecto que deseas cerrar y haz clic en “Borrar”. en la parte superior: esta opción programa la eliminación del proyecto.

Felicitaciones

¡Felicitaciones! Completaste correctamente el codelab.

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

¿Qué sigue?

Echa un vistazo a algunos de estos codelabs similares...