Un autor de cargas de trabajo crea una carga de trabajo y procesa los datos confidenciales con los que los colaboradores de datos desean trabajar.
Un autor de cargas 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 cualquier idioma que elijas, siempre que compiles una imagen contenedorizada que la 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 establecidas en la imagen del contenedor que controlan cómo se puede ejecutar una carga de trabajo y limitan la capacidad de un operador de carga de trabajo malicioso.
Para implementar la carga de trabajo, un operador de carga de trabajo ejecuta una VM confidencial según la imagen de Confidential Space. Esto recupera la imagen contenedorizada de Artifact Registry y la ejecuta.
Los colaboradores de datos deben validar las certificaciones de una carga de trabajo para que pueda acceder a sus datos.
Antes de comenzar
Escribir una carga de trabajo para Confidential Space es más que solo código y depuración. También debes hablar con los colaboradores de datos para evaluar sus necesidades, configurar tu entorno, empaquetar tu código en una imagen contenedorizada 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 solicitud, debes conversar con tus colaboradores de datos sobre los datos privados en los que quieren que trabajes. Estas son algunas preguntas que puedes hacer:
¿Cuáles son los IDs de la organización involucrados?
¿Cuáles son los números de proyecto involucrados?
¿A qué recursos de Google Cloud necesito acceder y cuáles son sus IDs y nombres?
¿Hay recursos a los que necesito acceder que no administra la IAM de Google Cloud?
¿Cómo debe la aplicación comparar y procesar los datos privados?
¿En qué formato debe estar el resultado?
¿Dónde se debe almacenar el resultado y si debe estar encriptado?
¿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.
Compila tu solución de Confidential Space
Es útil configurar dos (o más) proyectos con los permisos adecuados como un 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 obtener experiencia con los permisos entre proyectos y recuperar los datos que necesitas de recursos específicos de Google Cloud . También puedes obtener una apreciación de los roles de operador de cargas de trabajo y colaborador de datos y sus responsabilidades.
Durante la fase inicial de compilación, es útil observar las siguientes prácticas:
Cuando trabajes como colaborador de datos, mantén la validación de certificación al mínimo por motivos de velocidad de desarrollo.
Cuando trabajes como operador de cargas de trabajo, usa la imagen de depuración de Confidential Space en lugar de la de producción cuando implementes la carga de trabajo. Esto te brinda más formas de solucionar problemas de la carga de trabajo.
A medida que tu aplicación madure y su estado se vuelva más predecible, podrás 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 con datos falsos para que puedas demostrarles cómo funciona todo. En este momento, puedes comenzar a trabajar con un operador de cargas de trabajo independiente.
Cuando todo funcione y el resultado sea el esperado, puedes comenzar a realizar pruebas con los datos de producción. Una vez que se completen las pruebas y todas las partes aprueben los resultados, la carga de trabajo estará lista para implementarse 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 podrían leer si acceden a los registros. Antes de que tu código comience a trabajar en producción, asegúrate de que no genere nada que no sea estrictamente necesario.
Lo mismo sucede con el resultado final. Solo proporciona un resultado final que no comprometa la privacidad y 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, que se almacena en Artifact Registry. Cuando se implementa una carga de trabajo, la imagen de Confidential Space extrae la imagen de Docker del repositorio de Artifact Registry, la 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:
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, este servicio almacena etiquetas de integridad del disco en la memoria. Esto usa aproximadamente el 1% de la sobrecarga de memoria para 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 máquina que selecciones admita el uso de memoria de tu carga de trabajo, además de la sobrecarga de integridad del disco.
Tokens de OIDC vencidos
Se pone a disposición un token de OIDC para que lo consuma tu carga de trabajo cuando se inicie. 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 vence el token, se intentará una actualización en segundo plano con la retirada exponencial hasta que se realice correctamente. Si una actualización falla (debido a problemas de red, una interrupción del servicio de certificación o cualquier otro motivo), el código de la carga de trabajo debe poder controlar esa falla.
Tu carga de trabajo podría controlar una falla de actualización de 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 scratch en memoria
Confidential Space admite la adición de espacios en blanco en la memoria. Esto usa la memoria disponible en la VM de Confidential Space. Debido a que el espacio en blanco usa la memoria de la VM confidencial, tiene las mismas propiedades de integridad y confidencialidad que la VM confidencial.
Puedes usar tee-dev-shm-size para aumentar el tamaño del activador de 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. destination es el punto de activación, que interactúa con la política de inicio 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 entrantes
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 con imágenes de Confidential Space de 230,600 o más, 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 los 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 acceden a 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 configurar 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:
| Política | Tipo | Descripción |
|---|---|---|
|
Interactúa con lo siguiente:
|
Booleano (el valor predeterminado es false) |
Determina si un operador de carga de trabajo puede anular el
CMD especificado en el Dockerfile del contenedor de carga de trabajo con el valor de metadatos
tee-cmd.
|
|
Interactúa con lo siguiente:
|
Cadena separada por comas |
Es una cadena separada por comas de nombres de variable de entorno permitidos que un operador de cargas de trabajo puede establecer con valores de metadatos
tee-env-ENVIRONMENT_VARIABLE_NAME.
|
|
Interactúa con lo siguiente:
|
Cadena separada por dos puntos |
Es una cadena separada por dos puntos de directorios de activación permitidos a los que el operador de carga de trabajo puede activar con Por ejemplo: |
|
Interactúa con lo siguiente:
|
Cadena definida |
Determina cómo funciona el registro si un operador de carga de trabajo establece
Los valores válidos son los siguientes:
|
|
Interactúa con lo siguiente:
|
Cadena definida |
Determina cómo funciona la supervisión del uso de memoria de la carga de trabajo si un operador de carga de trabajo establece
Los valores válidos son los siguientes:
|
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 modificación de 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.
Imágenes de contenedor reproducibles
La compilación de una imagen de contenedor de forma reproducible puede ayudar a aumentar la confianza entre las partes. Puedes compilar imágenes reproducibles con Bazel.
Recursos que no administra la IAM de Google Cloud
Para acceder a los recursos que no administra la IAM de Google Cloud , tu carga de trabajo debe especificar un público personalizado.
Para obtener más información, consulta Recursos de acceso que no administra la IAM de Google Cloud .
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 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 muestra 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.