Atelier de programmation sur le SDK d'encryptage des requêtes

1. Présentation

Cet atelier de programmation vous explique comment utiliser le SDK Prompt Encryption pour communiquer de manière sécurisée avec un modèle diffusé dans un environnement d'exécution sécurisé (TEE) sur Google Cloud.

Points abordés

  • Établir un canal chiffré et vérifié par chiffrement entre un client et un serveur d'inférence à distance.
  • Vérification de l'identité du serveur (hachage logiciel, modèle matériel, configuration de lancement) à l'aide de TLS attesté.
  • Garantir la souveraineté des données en conservant les requêtes chiffrées jusqu'à ce qu'elles atteignent l'enclave vérifiée.
  • Utiliser le SDK de chiffrement des requêtes pour interagir avec vLLM exécuté sur Confidential Space.

Prérequis

  • Projet Google Cloud avec facturation activée
  • Le SDK Google Cloud (gcloud) est installé et authentifié.
  • Environnement Python 3.10 ou version ultérieure.
  • Un jeton Hugging Face pour télécharger les modèles Gemma.
  • Connaissance des pare-feu VPC et du quota d'adresses IP externes.
  • Pour créer le SDK en local, vous devez compiler l'extension C _ekm.c. Cette étape échoue si les en-têtes C de Python ne sont pas installés. Installez python3-dev pour résoudre ce problème (par exemple, sudo apt-get install python3-dev pour Debian/Ubuntu).

2. Configurer des ressources cloud

Avant de commencer, assurez-vous d'avoir activé les API requises et configuré votre environnement.

1. Activez les API requises :

gcloud services enable compute.googleapis.com \
    confidentialcomputing.googleapis.com \
    logging.googleapis.com \
    artifactregistry.googleapis.com \
    cloudbuild.googleapis.com

2. Configurer Docker :

gcloud auth configure-docker gcr.io

3. Définir le jeton Hugging Face :

export HF_TOKEN="your_token"

4. Clonez le dépôt :

git clone https://github.com/google/prompt-encryption-sdk && cd prompt-encryption-sdk

3. Scénario

Nous allons utiliser :

  • Client : votre environnement Python local ou une VM standard.
  • Serveur : instance vLLM diffusant un modèle Open Source (par exemple, Gemma) dans un Confidential Space (TDX/SEV-SNP).
  • SDK : bibliothèque Python prompt_encryption_sdk.

4. Étape 0 : Configuration du serveur

Avant que le client puisse valider quoi que ce soit, nous avons besoin d'un serveur exécuté dans Confidential Space. Un script bash fourni gère le provisionnement.

./codelabs/setup.sh --project-id <PROJECT_ID>

Le script setup.sh effectue les opérations suivantes :

  1. Active les API requises (Compute, Informatique confidentielle, Logging, Artifact Registry, Cloud Build).
  2. Crée et transmet l'image Docker (en encapsulant vLLM avec le middleware TLS attesté).
  3. Provisionne un compte de service avec les autorisations nécessaires.
  4. Crée la Confidential VM (instance A3 avec GPU H100 et TDX activé).
  5. Configure la mise en réseau et l'équilibrage de charge (équilibreur de charge réseau passthrough).
  6. Enregistre les sorties (hachage d'image et adresse IP de l'équilibreur de charge) dans des fichiers locaux.

5. Étape 1 : Exécutez le client attesté

Maintenant que le serveur fonctionne de manière sécurisée, établissez une connexion attestée.

python3 -m venv venv
source venv/bin/activate
pip install -r examples/requirements.txt
pip install -e .
./codelabs/run_client.sh <PROJECT_ID>

Le script run_client.sh lit les détails du déploiement et exécute une requête Python à l'aide de ConfidentialSDKClient. Si l'attestation échoue, une erreur AttestationError est générée et l'invite n'est jamais envoyée.

6. Étape 2 : Nettoyage

Pour éviter que des frais ne vous soient facturés, nettoyez les ressources une fois que vous avez terminé.

./codelabs/cleanup.sh --project-id <PROJECT_ID>

7. Options avancées

Que se passe-t-il pendant http.post ?

  1. TCP/TLS : connexion standard établie.
  2. Interception de l'établissement de la liaison : le SDK s'interrompt avant d'envoyer le corps.
  3. RPC AttestConnection : le SDK envoie un nonce au serveur.
  4. Génération de devis : le serveur demande un devis matériel TEE.
  5. Validation : le SDK valide la signature et les règles du devis.
  6. Liaison : le SDK vérifie que le "matériel de clé" exporté du canal correspond à la session liée dans le devis.
  7. Transmission des données : le corps n'est envoyé que si tous les contrôles sont réussis.

8. Dépannage

  • Échec de l'attestation : vérifiez que le image_hash de la règle correspond à celui du conteneur.
  • Connexion refusée : assurez-vous que le serveur est accessible et que le port 8000 est ouvert.
  • Délai d'attente : la génération de devis TEE peut prendre du temps. Assurez-vous que les délais d'attente sont suffisants.

9. Félicitations

Vous avez terminé l'atelier de programmation sur le SDK d'encryptage des requêtes. Vous avez appris à établir un canal chiffré et vérifié de manière cryptographique entre votre client et un serveur d'inférence basé sur TEE.

Étape suivante

  • Explorez les configurations avancées d'AttestationPolicy.
  • Intégrez le SDK à vos applications de production existantes.
  • En savoir plus sur Confidential Space et les modèles de matériel TEE.

Documentation complémentaire