Une charge de travail est créée par un auteur de charge de travail et traite les données confidentielles avec lesquelles les collaborateurs de données souhaitent travailler.
Pour créer une charge de travail, l'auteur de la charge de travail doit rassembler les ressources suivantes :
Une application permettant de traiter les données confidentielles. Vous pouvez écrire votre application dans la langue de votre choix, à condition de créer une image conteneurisée compatible.
Une image conteneurisée pour empaqueter l'application à l'aide de Docker.
Un dépôt dans Artifact Registry pour stocker l'image Docker.
Les stratégies de lancement définies sur l'image de conteneur contrôlent la façon dont une charge de travail peut être exécutée et limitent les capacités d'un opérateur de charge de travail malveillant.
Pour déployer la charge de travail, une Confidential VM est exécutée par un opérateur de charge de travail en fonction de l'image Confidential Space. Cette commande récupère l'image conteneurisée depuis Artifact Registry et l'exécute.
Les collaborateurs de données doivent valider les attestations d'une charge de travail avant de pouvoir accéder à leurs données.
Avant de commencer
Écrire une charge de travail pour Confidential Space ne se limite pas à écrire du code et à le déboguer. Vous devez également discuter avec les collaborateurs de données pour évaluer leurs besoins, configurer votre environnement, empaqueter votre code dans une image conteneurisée et travailler avec un opérateur de charge de travail pour vous assurer que tout est déployé correctement.
Discuter avec les collaborateurs de données
Avant de commencer à écrire votre application, vous devez discuter avec vos collaborateurs de données privées sur lesquelles ils souhaitent que vous travailliez. Voici quelques exemples de questions que vous pouvez poser :
Quels sont les ID d'organisation concernés ?
Quels sont les numéros de projet concernés ?
Quelles sont les ressources Google Cloud auxquelles je dois accéder, et quels sont leurs ID et leurs noms ?
Dois-je accéder à des ressources qui ne sont pas gérées par Google CloudIAM ?
Comment l'application doit-elle comparer et traiter les données privées ?
Dans quel format la sortie doit-elle être ?
Où le résultat doit-il être stocké et doit-il être chiffré ?
Tous les collaborateurs de données voient-ils le même résultat ou les résultats sont-ils uniques pour chacun ?
De plus, chaque collaborateur de données peut avoir des exigences de confidentialité uniques que vous devez respecter. Il est essentiel qu'aucune donnée privée ne soit exposée à la suite d'une charge de travail.
Créer votre solution Confidential Space
Il est utile de configurer deux projets (ou plus) avec les autorisations appropriées comme environnement de test, comme dans Créer votre premier environnement Confidential Space. Essayez de reproduire au mieux les configurations de projet des collaborateurs pour les données. Cela vous permet d'acquérir de l'expérience avec les autorisations inter-projets et de récupérer les données dont vous avez besoin à partir de ressources Google Cloud spécifiques. Vous pouvez également vous familiariser avec les rôles d'opérateur de charge de travail et de collaborateur de données et leurs responsabilités.
Lors de la phase de création initiale, il est utile d'observer les pratiques suivantes :
Lorsque vous travaillez en tant que collaborateur de données, limitez la validation de l'attestation pour accélérer le développement.
Lorsque vous travaillez en tant qu'opérateur de charge de travail, utilisez l'image de débogage Confidential Space au lieu de l'image de production lorsque vous déployez la charge de travail. Vous disposez ainsi de plus de moyens pour résoudre les problèmes liés à la charge de travail.
À mesure que votre application évolue et que son état devient plus prévisible, vous pouvez sécuriser de plus en plus votre solution avec la validation de l'attestation et les règles de lancement, et passer à l'image Confidential Space de production.
Une fois que votre charge de travail fonctionne correctement dans votre environnement de test, vous pouvez passer aux tests dans les projets de vos collaborateurs de données avec de vraies ressources, mais de fausses données. Vous pourrez ainsi leur montrer comment tout fonctionne. À ce stade, vous pouvez commencer à travailler avec un opérateur de charge de travail indépendant.
Lorsque tout fonctionne et que le résultat est celui attendu, vous pouvez commencer à tester les données de production. Une fois les tests terminés et les résultats approuvés par toutes les parties, la charge de travail est prête à être mise en production.
Faites attention aux résultats
Lors du test de votre code, il peut être tentant de déboguer en imprimant sur STDOUT ou STDERR. Si vous choisissez de le faire, veillez à ne pas exposer de données privées que d'autres parties pourraient lire en accédant aux journaux. Avant que votre code ne commence à fonctionner en production, assurez-vous qu'il ne génère rien d'autre que ce qui est strictement nécessaire.
Il en va de même pour le résultat final. Ne fournissez qu'un résultat final qui ne compromet pas la confidentialité ni la sensibilité des données d'origine.
Créer une image conteneurisée avec Docker
Les applications doivent être empaquetées dans une image conteneurisée créée par Docker et stockée dans Artifact Registry. Lorsqu'une charge de travail est déployée, l'image Docker est extraite du dépôt Artifact Registry par l'image Confidential Space, exécutée, et l'application peut commencer à travailler sur les ressources de projet appropriées.
Lorsque vous créez votre image Docker, tenez compte des points suivants :
Fonctionnalités Linux supplémentaires
La charge de travail Confidential Space s'exécute dans un conteneur Linux à l'aide de containerd. Ce conteneur s'exécute à l'aide des fonctionnalités Linux par défaut.
Pour ajouter des fonctionnalités, vous pouvez utiliser tee-added-capabilities.
Limites de disque et de mémoire
Confidential Space redimensionne automatiquement la partition avec état du disque de démarrage lorsque vous utilisez des disques de démarrage plus grands. La taille de la partition est à peu près égale à la taille du disque de démarrage moins 5 Go.
Dans le cadre des protections du système de fichiers d'intégrité de Confidential Space, Confidential Space stocke les tags d'intégrité du disque en mémoire. Cela utilise environ 1 % de mémoire supplémentaire pour chaque octet de disque. Par exemple, un disque de 100 Go nécessite 1 Go de mémoire, et un disque de 10 To nécessite 100 Go de mémoire.
Veillez à respecter les limites de mémoire de la VM. La mémoire d'échange est désactivée sur les VM Confidential Space, ce qui signifie qu'une utilisation excessive de la mémoire peut planter la charge de travail. Assurez-vous que la machine sélectionnée est compatible avec l'utilisation de la mémoire de votre charge de travail, en plus de la marge d'intégrité du disque.
Jetons OIDC expirés
Un jeton OIDC est mis à la disposition de votre charge de travail au démarrage. Il contient des revendications d'attestation validées sur la VM de votre charge de travail et il est stocké dans le conteneur de charge de travail à l'emplacement /run/container_launcher/attestation_verifier_claims_token. Le jeton expire au bout de 60 minutes.
Si le jeton expire, une actualisation est effectuée en arrière-plan avec un intervalle exponentiel entre les tentatives jusqu'à ce que la requête aboutisse. Si une actualisation échoue (en raison de problèmes réseau, d'une interruption du service d'attestation ou pour toute autre raison), votre code de charge de travail doit pouvoir gérer cette défaillance.
Votre charge de travail peut gérer l'échec de l'actualisation des jetons de l'une des manières suivantes :
Ignorer le jeton expiré, en supposant qu'il n'est plus requis après l'utilisation initiale.
Attendre que le jeton arrivé à expiration soit actualisé.
Quitter la charge de travail.
Montages de scratch en mémoire
Confidential Space permet d'ajouter des espaces de travail temporaires en mémoire. Cette option utilise la mémoire disponible dans la VM Confidential Space. Comme l'espace de travail utilise la mémoire de la Confidential VM, il possède les mêmes propriétés d'intégrité et de confidentialité que la Confidential VM.
Vous pouvez utiliser tee-dev-shm-size pour augmenter la taille du point de montage de la mémoire partagée /dev/shm pour la charge de travail.
La taille de /dev/shm est spécifiée en Ko.
Vous pouvez utiliser tee-mount pour spécifier les montages tmpfs dans le conteneur en cours d'exécution à l'aide de configurations séparées par des points-virgules. Les valeurs type et source sont toujours tmpfs. destination est le point de montage, qui interagit avec la règle de lancement tee.launch_policy.allow_mount_destinations. Vous pouvez éventuellement spécifier la taille tmpfs en octets. La taille par défaut est de 50 % de la mémoire de la VM.
Ports entrants
Par défaut, les VM Confidential Space utilisent une règle de pare-feu qui bloque tous les ports entrants. Lorsque vous utilisez une image Confidential Space version 230600 ou ultérieure, vous pouvez spécifier des ports entrants à garder ouverts dans Dockerfile lors de la création de votre image de charge de travail.
Pour ouvrir des ports, ajoutez le mot-clé EXPOSE à votre fichier Dockerfile, ainsi que le numéro de port à laisser ouvert et un protocole facultatif de tcp ou udp. Si vous ne spécifiez pas le protocole pour un port, TCP et UDP sont tous les deux autorisés. Voici un exemple de Dockerfile qui expose des ports entrants :
FROM alpine:latest
EXPOSE 80
EXPOSE 443/tcp
EXPOSE 81/udp
WORKDIR /test
COPY salary /test
ENTRYPOINT ["/test/salary"]
CMD []
Selon l'image de base que vous utilisez, certains ports peuvent déjà être exposés. Votre Dockerfile n'expose que des ports supplémentaires. Il ne peut pas bloquer les ports déjà ouverts par l'image de base.
Avant d'exécuter la charge de travail, les opérateurs de charge de travail doivent s'assurer que les ports exposés sont ouverts dans leur pare-feu VPC. Les numéros de port peuvent être fournis par l'auteur de la charge de travail ou extraits des informations sur l'image Docker.
Les ports exposés sont consignés dans la console et redirigés vers Cloud Logging lorsque vous utilisez la variable de métadonnées tee-container-log-redirect.
Règles de lancement
Les règles de lancement remplacent les variables de métadonnées de VM définies par les opérateurs de charge de travail pour limiter les actions malveillantes. Un auteur de charge de travail peut définir des stratégies avec un libellé lors de la création de son image de conteneur.
Par exemple, dans un Dockerfile :
LABEL "tee.launch_policy.allow_cmd_override"="true"
Dans un fichier BUILD Bazel :
container_image(
...
labels={"tee.launch_policy.allow_cmd_override":"true"}
...
)
Les règles de lancement disponibles sont listées dans le tableau suivant :
| Règle | Type | Description |
|---|---|---|
|
Interagit avec :
|
Valeur booléenne (false par défaut) |
Détermine si l'opérateur de charge de travail peut ajouter des fonctionnalités Linux supplémentaires au conteneur de charge de travail. |
|
Interagit avec :
|
Valeur booléenne (false par défaut) |
Détermine si le conteneur de charge de travail est autorisé à inclure un montage cgroup avec espace de noms à l'adresse /sys/fs/cgroup.
|
|
Interagit avec :
|
Valeur booléenne (false par défaut) |
Détermine si le
CMD spécifié dans le Dockerfile du conteneur de charge de travail peut être remplacé par un opérateur de charge de travail avec la valeur de métadonnées
tee-cmd.
|
|
Interagit avec :
|
Chaîne séparée par des virgules |
Chaîne de noms de variable d'environnement autorisés, séparés par une virgule, qui peuvent être définis par un opérateur de charge de travail avec des valeurs de métadonnées
tee-env-ENVIRONMENT_VARIABLE_NAME.
|
|
Interagit avec :
|
Chaîne séparée par des deux-points |
Chaîne de répertoires d'installation autorisés, séparés par un deux-points, que l'opérateur de charge de travail est autorisé à installer à l'aide de Par exemple : |
|
Interagit avec :
|
Chaîne définie |
Détermine le fonctionnement de la journalisation si
Les valeurs valides sont les suivantes :
|
|
Interagit avec :
|
Chaîne définie |
Détermine le fonctionnement de la surveillance de l'utilisation de la mémoire de la charge de travail si
Les valeurs valides sont les suivantes :
|
Exécutions multiples de charge de travail
Pour garantir un environnement propre, une VM doit redémarrer avant de redémarrer une charge de travail. Cela chiffre le disque de la VM avec une clé éphémère, afin de traiter le vecteur d'attaque de la modification d'une image de charge de travail sur le disque après son téléchargement et son évaluation.
Cela augmente également les frais généraux, tels que le temps de démarrage et l'extraction de l'image de charge de travail à chaque exécution de charge de travail. Si ces surcharges affectent trop les performances de votre charge de travail, vous pouvez coder un redémarrage de charge de travail dans la charge de travail elle-même, au prix d'une augmentation de votre profil de risque.
Groupes de contrôle avec espace de noms
La charge de travail Confidential Space s'exécute sans montage cgroup par défaut.
Pour gérer les cgroups dans le conteneur de charge de travail, vous pouvez utiliser tee-cgroup-ns. Cela crée un point de montage à /sys/fs/cgroup dans le système de fichiers du conteneur.
Images de conteneurs reproductibles
Créer une image de conteneur de manière reproductible permet de renforcer la confiance entre les parties. Vous pouvez créer des images reproductibles avec Bazel.
Ressources non gérées par Google Cloud IAM
Pour accéder aux ressources non gérées par Google Cloud IAM, votre charge de travail doit spécifier une audience personnalisée.
Pour en savoir plus, consultez Accéder aux ressources non gérées par Google Cloud IAM.
Images de conteneurs signées
Vous pouvez signer une image de conteneur avec une clé publique, qu'un collaborateur de données peut ensuite utiliser pour l'attestation au lieu de spécifier un résumé d'image dans sa règle WIP.
Cela signifie que les collaborateurs de données n'ont pas besoin de mettre à jour leurs règles de protection des informations professionnelles chaque fois qu'une charge de travail est mise à jour. La charge de travail peut ainsi continuer à accéder aux ressources protégées sans interruption.
Vous pouvez utiliser Sigstore Cosign pour signer l'image de conteneur. Pour s'assurer que Confidential Space peut récupérer les signatures, les opérateurs de charge de travail doivent ajouter les informations de signature à la variable de métadonnées tee-signed-image-repos avant de déployer la charge de travail.
Lors de l'exécution, les signatures sont envoyées au service d'attestation Confidential Space pour vérification. Le service d'attestation renvoie un jeton de revendications d'attestation contenant les revendications de signature validées. Voici un exemple de réclamation pour signature :
"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",
}
],
Pour configurer la signature d'images de conteneurs, consultez l'atelier de programmation sur les images de conteneurs signées.