Crea y personaliza cargas de trabajo

Un autor de cargas de trabajo crea una carga de trabajo y procesa los datos confidenciales con los que los colaboradores de datos quieren trabajar.

El autor de una carga de trabajo debe reunir los siguientes recursos para crear una carga de trabajo:

• Una aplicación para procesar los datos confidenciales Puedes escribir tu aplicación en el idioma que elijas, siempre y cuando compiles una imagen en contenedor que lo admita.

• Una imagen alojada en contenedores para empaquetar la aplicación con Docker

• Un repositorio en Artifact Registry para almacenar la imagen de Docker.

• Políticas de inicio: Se configuran en la imagen del contenedor y controlan cómo se puede ejecutar una carga de trabajo, además de restringir la capacidad de un operador malicioso de la carga de trabajo.

Para implementar la carga de trabajo, un operador de carga de trabajo ejecuta una Confidential VM basada en la imagen de Confidential Space. Esto recupera la imagen en contenedor de Artifact Registry y la ejecuta.

Los colaboradores de datos deben validar las certificaciones de una carga de trabajo antes de que esta pueda acceder a sus datos.

Antes de comenzar

Escribir una carga de trabajo para Confidential Space es mucho más que escribir código y depurar. También debes hablar con los colaboradores de datos para evaluar sus necesidades, configurar tu entorno, empaquetar tu código en una imagen en contenedores y trabajar con un operador de cargas de trabajo para asegurarte de que todo se implemente correctamente.

Habla con los colaboradores de datos

Antes de comenzar a escribir tu aplicación, debes conversar con tus colaboradores de datos sobre los datos privados con los que quieres trabajar. Estas son algunas preguntas que puedes hacer:

• ¿Cuáles son los IDs de organización involucrados?

• ¿Cuáles son los números de proyecto involucrados?

• ¿Cuáles son los Google Cloud recursos a los que necesito acceder y cuáles son sus IDs y nombres?

• ¿Hay recursos a los que necesito acceder que no administra Google CloudIAM?

• ¿Cómo debe la aplicación comparar y procesar los datos privados?

• ¿En qué formato debería estar el resultado?

• ¿Dónde se debe almacenar el resultado y se debe encriptar?

• ¿Todos los colaboradores de datos ven el mismo resultado o los resultados son únicos para cada uno?

Además, cada colaborador de datos también puede tener requisitos de privacidad únicos que debes cumplir. Es de vital importancia que no se expongan datos privados como resultado de una carga de trabajo.

Crea tu solución de Confidential Space

Es útil configurar dos (o más) proyectos con los permisos adecuados como entorno de prueba, como en Crea tu primer entorno de Confidential Space. Intenta replicar la configuración de los proyectos de los colaboradores de datos lo mejor que puedas. Esto te permite adquirir experiencia con los permisos entre proyectos y recuperar los datos que necesitas de recursos Google Cloud específicos. También puede ayudarte a comprender los roles de operador de carga de trabajo y colaborador de datos y sus responsabilidades.

Durante la fase inicial de desarrollo, es útil observar las siguientes prácticas:

• Cuando trabajes como colaborador de datos, mantén la validación de la certificación al mínimo para acelerar el desarrollo.

• Cuando trabajes como operador de carga de trabajo, usa la imagen de depuración de Confidential Space en lugar de la imagen de producción cuando implementes la carga de trabajo. Esto te brinda más formas de solucionar problemas relacionados con la carga de trabajo.

A medida que tu aplicación madura y su estado se vuelve más predecible, puedes proteger cada vez más tu solución con la validación de certificación y las políticas de lanzamiento, y cambiar a la imagen de Confidential Space de producción.

Después de que tu carga de trabajo funcione correctamente en tu entorno de prueba, puedes cambiar a las pruebas en los proyectos de tus colaboradores de datos con recursos reales, pero datos falsos para que puedas demostrarles cómo funciona todo. En este punto, es posible que comiences a trabajar con un operador de carga de trabajo independiente.

Cuando todo funcione y el resultado sea el esperado, puedes comenzar a realizar pruebas con datos de producción. Una vez que se completan las pruebas y todas las partes aprueban los resultados, la carga de trabajo está lista para entrar en producción.

Ten cuidado con el resultado

Mientras pruebas tu código, puede ser tentador depurar imprimiendo en STDOUT o STDERR. Si decides hacerlo, ten cuidado de no exponer datos privados que otras partes puedan leer accediendo a los registros. Antes de que tu código comience a funcionar en producción, asegúrate de que no genere ningún resultado que no sea estrictamente necesario.

Lo mismo sucede con el resultado final. Solo proporciona un resultado final que no comprometa la privacidad ni la sensibilidad de los datos originales.

Compila una imagen alojada en contenedores con Docker

Las aplicaciones deben empaquetarse en una imagen en contenedores compilada por Docker y almacenada en Artifact Registry. Cuando se implementa una carga de trabajo, la imagen de Docker se extrae del repositorio de Artifact Registry por la imagen de Confidential Space, se ejecuta y la aplicación puede comenzar a trabajar en los recursos del proyecto adecuados.

Cuando compiles tu imagen de Docker, ten en cuenta lo siguiente:

• Funciones adicionales de Linux

• Límites de disco y memoria

• Tokens de OIDC vencidos

• Recursos no administrados por Google Cloud IAM

• Puertos de entrada

• Políticas de lanzamiento

• Ejecuciones de múltiples cargas de trabajo

• Cgroups con espacio de nombres

• Imágenes de contenedor reproducibles

• Imágenes de contenedor firmadas

Funciones adicionales de Linux

La carga de trabajo de Confidential Space se ejecuta en un contenedor de Linux con containerd. Este contenedor se ejecuta con capacidades predeterminadas de Linux.

Para agregar capacidades, puedes usar tee-added-capabilities.

Límites de disco y memoria

Confidential Space cambia automáticamente el tamaño de la partición con estado del disco de arranque cuando se usan tamaños de disco de arranque más grandes. El tamaño de la partición es aproximadamente el tamaño del disco de arranque menos 5 GB.

Como parte de las protecciones del sistema de archivos de integridad de Confidential Space, Confidential Space almacena etiquetas de integridad del disco en la memoria. Esto usa aproximadamente un 1% de sobrecarga de memoria por cada byte de disco. Por ejemplo, un disco de 100 GB requiere 1 GB de memoria, y un disco de 10 TB requiere 100 GB de memoria.

Asegúrate de mantenerte dentro de los límites de memoria de la VM. La memoria de intercambio está inhabilitada en las VMs de Confidential Space, lo que significa que el uso excesivo de memoria puede causar fallas en la carga de trabajo. Asegúrate de que la selección de la máquina admita el uso de memoria de tu carga de trabajo, además de la sobrecarga de integridad del disco.

Tokens de OIDC vencidos

Cuando se inicia tu carga de trabajo, se pone a disposición un token de OIDC para que lo consuma. Contiene reclamos de certificación verificados sobre la VM de tu carga de trabajo y se almacena en el contenedor de la carga de trabajo en /run/container_launcher/attestation_verifier_claims_token. El token vence después de 60 minutos.

Si el token vence, se intenta una actualización en segundo plano con una retirada exponencial hasta que se realiza correctamente. Si falla una actualización (debido a problemas de red, una interrupción del servicio de certificación o cualquier otro motivo), el código de tu carga de trabajo debe poder controlar esa falla.

Tu carga de trabajo podría controlar una falla en la actualización del token de una de las siguientes maneras:

• Ignora el token vencido, suponiendo que ya no es necesario después del uso inicial.

• Espera a que el token vencido se actualice correctamente.

• Sal de la carga de trabajo.

Activaciones de memoria temporal en memoria

Confidential Space admite la adición de espacios de trabajo en memoria. Esto usa la memoria disponible en la VM de Confidential Space. Debido a que el espacio de trabajo usa la memoria de la Confidential VM, tiene las mismas propiedades de integridad y confidencialidad que la Confidential VM.

Puedes usar tee-dev-shm-size para aumentar el tamaño del punto de montaje de la memoria compartida /dev/shm para la carga de trabajo. El tamaño de /dev/shm se especifica en KB.

Puedes usar tee-mount para especificar activaciones de tmpfs en el contenedor en ejecución con configuraciones separadas por punto y coma. type y source siempre son tmpfs. El objeto destination es el punto de montaje, que interactúa con la política de lanzamiento de tee.launch_policy.allow_mount_destinations. De manera opcional, puedes especificar el tamaño de tmpfs en bytes. El tamaño predeterminado es el 50% de la memoria de la VM.

Puertos de entrada

De forma predeterminada, las VMs de Confidential Space operan con una regla de firewall para bloquear todos los puertos entrantes. Cuando usas una versión de imagen de Confidential Space de 230600 o posterior, puedes especificar puertos entrantes para que se mantengan abiertos en Dockerfile cuando compiles la imagen de carga de trabajo.

Para abrir puertos, agrega la palabra clave EXPOSE a tu Dockerfile, junto con el número de puerto que quieres mantener abierto y un protocolo opcional de tcp o udp. Si no especificas el protocolo para un puerto, se permiten TCP y UDP. Este es un ejemplo de Dockerfile que expone los puertos entrantes:

FROM alpine:latest
EXPOSE 80
EXPOSE 443/tcp
EXPOSE 81/udp
WORKDIR /test
COPY salary /test
ENTRYPOINT ["/test/salary"]
CMD []

Según la imagen base que uses, es posible que algunos puertos ya estén expuestos. Tu Dockerfile solo expone puertos adicionales; no puede bloquear puertos que ya abrió la imagen base.

Los operadores de la carga de trabajo deben asegurarse de que los puertos expuestos estén abiertos en su firewall de VPC antes de ejecutar la carga de trabajo. El autor de la carga de trabajo puede proporcionar los números de puerto o extraerlos de la información de la imagen de Docker.

Los puertos expuestos se registran en la consola y se redireccionan a Cloud Logging cuando se usa la variable de metadatos tee-container-log-redirect.

Políticas de inicio

Las políticas de lanzamiento anulan las variables de metadatos de VM que establecen los operadores de cargas de trabajo para restringir las acciones maliciosas. El autor de una carga de trabajo puede establecer políticas con una etiqueta como parte de la compilación de su imagen de contenedor.

Por ejemplo, en un Dockerfile:

LABEL "tee.launch_policy.allow_cmd_override"="true"

En un archivo BUILD de Bazel, haz lo siguiente:

container_image(
    ...
    labels={"tee.launch_policy.allow_cmd_override":"true"}
    ...
)

Las políticas de lanzamiento disponibles se encuentran en la siguiente tabla:

Ejecuciones de múltiples cargas de trabajo

Para garantizar un entorno limpio, se debe reiniciar una VM para reiniciar una carga de trabajo. Esto encripta el disco de la VM con una clave efímera para abordar el vector de ataque de modificar una imagen de carga de trabajo en el disco después de que se descargó y midió.

Esto también agrega sobrecargas, como el tiempo de inicio y la extracción de la imagen de carga de trabajo, a cada ejecución de carga de trabajo. Si estas sobrecargas afectan demasiado el rendimiento de tu carga de trabajo, puedes codificar el reinicio de una carga de trabajo en la misma carga de trabajo, a costa de aumentar el perfil de riesgo.

cgroups con espacio de nombres

De forma predeterminada, la carga de trabajo de Confidential Space se ejecuta sin un montaje de cgroup.

Para administrar los cgroups dentro del contenedor de la carga de trabajo, puedes usar tee-cgroup-ns. Esto creará un punto de activación en /sys/fs/cgroup en el sistema de archivos del contenedor.

Imágenes de contenedor reproducibles

Compilar una imagen de contenedor de forma reproducible puede ayudar a aumentar la confianza entre las partes. Puedes compilar imágenes reproducibles con Bazel.

Recursos no administrados por Google Cloud IAM

Para acceder a los recursos que no administra Google Cloud IAM, tu carga de trabajo debe especificar un público personalizado.

Para obtener más información, consulta Cómo acceder a recursos que no administra Google Cloud IAM.

Imágenes de contenedor firmadas

Puedes firmar una imagen de contenedor con una clave pública que un colaborador de datos puede usar para la certificación en lugar de especificar un resumen de la imagen en su política de WIP.

Esto significa que los colaboradores de datos no necesitan actualizar sus políticas de WIP cada vez que se actualiza una carga de trabajo, y la carga de trabajo puede seguir accediendo a los recursos protegidos sin interrupciones.

Puedes usar Sigstore Cosign para firmar la imagen del contenedor. Para garantizar que Confidential Space pueda recuperar las firmas, los operadores de cargas de trabajo deben agregar la información de la firma a la variable de metadatos tee-signed-image-repos antes de implementar la carga de trabajo.

Durante el tiempo de ejecución, las firmas se envían al servicio de certificación de Confidential Space para su verificación. El servicio de certificación devuelve un token de reclamos de certificación que contiene los reclamos de firma verificados. Este es un ejemplo de un reclamo de firma:

"image_signatures": [
  {
    "key_id": "hexadecimal-sha256-fingerprint-public-key1",
    "signature": "base64-encoded-signature",
    "signature_algorithm": "RSASSA_PSS_SHA256"
  },
  {
    "key_id": "hexadecimal-sha256-fingerprint-public-key2",
    "signature": "base64-encoded-signature",
    "signature_algorithm": "RSASSA_PSS_SHA256",
  },
  {
    "key_id": "hexadecimal-sha256-fingerprint-public-key3",
    "signature": "base64-encoded-signature",
    "signature_algorithm": "RSASSA_PSS_SHA256",
  }
],

Para configurar la firma de imágenes de contenedor, consulta el Codelab de imágenes de contenedor firmadas.