Elastic Compute Service:Déployer un agent IA OpenClaw confidentiel sur des instances de calcul confidentiel hétérogènes

Architecture de sécurité

Toutes les données critiques du déploiement Confidential Agent restent confinées à l'intérieur de la limite du TEE. Les trois catégories d'actifs suivantes sont strictement protégées :

L'architecture de sécurité repose sur cinq couches, de bas en haut : matériel, chaîne de démarrage, runtime, gestion des clés et communication :

Flux de déploiement

1. Audit du code source : le responsable du déploiement audite le code source métier pour confirmer l'absence de code malveillant ou de portes dérobées.

2. Génération des artefacts de build et publication des valeurs de référence logicielles : construisez une image OS légère contenant uniquement le service OpenClaw à partir du code source audité, puis téléchargez la signature SLSA des artefacts de build dans le journal de transparence Rekor afin de publier les valeurs de référence logicielles.

3. Création d'une instance confidentielle : créez une instance de calcul confidentiel gn8v-tee en utilisant l'image construite.

4. Audit par attestation à distance et téléchargement des ressources confidentielles : le responsable du déploiement utilise l'outil de déploiement pour effectuer une attestation à distance sur l'instance afin de vérifier qu'elle s'exécute sur du matériel TDX authentique. Après vérification, les ressources confidentielles telles que les clés de chiffrement du disque et les identifiants du bot DingTalk sont automatiquement téléchargées.

5. Accès à OpenClaw : les utilisateurs peuvent accéder directement à OpenClaw via un navigateur web, un client de bureau ou un terminal TUI, ou indirectement via des plateformes de messagerie instantanée comme DingTalk.

6. Audit par attestation à distance et transmission chiffrée : avant d'établir une connexion, le client de passerelle approuvée récupère les valeurs de référence logicielles depuis Rekor et les valeurs de référence matérielles depuis Intel PCCS et RIM/OCSP. Une fois la vérification par attestation à distance terminée, un canal chiffré RATS-TLS est établi. Toutes les communications sont chiffrées de bout en bout.

Étape 1 : Construire une image de confiance contenant OpenClaw et le moteur d'inférence vLLM

Effectuez les tâches suivantes sur la machine de déploiement (une instance Alibaba Cloud Linux 3) : téléchargez le code source, installez les dépendances, générez les clés, configurez les ressources cloud et construisez l'image de confiance.

1. Connectez-vous à une instance ECS.

   1. Accédez à Console ECS - Instances. Dans le coin supérieur gauche, sélectionnez la région et le groupe de ressources correspondant à l'instance cible.

   2. Accédez à la page de détails de l'instance cible. Cliquez sur Connect et sélectionnez Workbench. Définissez la méthode de connexion sur Terminal Connection, saisissez votre nom d'utilisateur et votre mot de passe, puis connectez-vous au terminal graphique.

2. Téléchargez le code source du projet.

   cd ~/
   git clone https://github.com/inclavare-containers/confidential-agent
   cd confidential-agent

3. Installez toutes les dépendances logicielles requises.

   make install-deps

   Cette commande installe Docker, Terraform, Go, Python, cosign, rekor-cli et d'autres outils nécessaires à la construction et au déploiement.

4. Générez les clés de chiffrement et les fichiers de configuration requis pour le déploiement.

   make generate-secrets

   Une fois les clés générées, modifiez le fichier secrets/openclaw-vllm.json et remplacez les espaces réservés par des valeurs réelles, telles que les identifiants de l'application DingTalk et les configurations du modèle. Le tableau suivant décrit les espaces réservés :

   Espace réservé	Description	Comment l'obtenir
   <DINGTALK_BOT_CLIENT_ID>	ClientId du bot DingTalk	Consultez la documentation DingTalk Bot + OpenClaw. Créez une application dans le Portail développeur DingTalk pour obtenir la valeur.
   <DINGTALK_BOT_CLIENT_SECRET>	ClientSecret du bot DingTalk	Idem ci-dessus. Obtenez la valeur depuis la page de détails de l'application.

5. Configurez le fichier de variables Terraform.

   Remarque

   Terraform est un outil open source d'Infrastructure as Code (IaC) qui automatise la création, la modification et la gestion des versions des ressources et services cloud sur Alibaba Cloud via des fichiers de configuration déclaratifs. Dans cette solution, Terraform automatise le déploiement des instances confidentielles.

   cp terraform/terraform.tfvars.example terraform/terraform.tfvars

   Modifiez le fichier terraform/terraform.tfvars et configurez les paramètres clés comme indiqué dans le tableau suivant.

   Paramètre	Valeur recommandée	Description
   zone_id	"cn-beijing-l"	Une zone compatible avec la famille d'instances gn8v-tee
   vpc_cidr	"10.0.0.0/16"	Bloc CIDR VPC
   vswitch_cidr	"10.0.1.0/24"	Bloc CIDR vSwitch
   security_group_allowed_cidr	Le bloc CIDR IP de l'environnement client qui doit accéder au service OpenClaw	Plage d'adresses IP sources autorisée par le groupe de sécurité

   Important

   La valeur par défaut de security_group_allowed_cidr est 0.0.0.0/0. Dans les environnements de production, vous devez modifier cette valeur pour spécifier un bloc CIDR IP précis et n'autoriser que les adresses IP sources requises.

6. Exportez vos identifiants d'accès Alibaba Cloud pour permettre à Terraform de créer les ressources cloud.

   export ALICLOUD_ACCESS_KEY="<YOUR_ACCESS_KEY>"
   export ALICLOUD_SECRET_KEY="<YOUR_SECRET_KEY>"

   Remarque

   Nous vous recommandons d'utiliser un rôle RAM ou des identifiants temporaires (STS) pour éviter le stockage à long terme des paires de clés AccessKey. Pour savoir comment créer une paire de clés AccessKey, consultez la rubrique Créer une paire de clés AccessKey.

7. Construisez une image de confiance contenant OpenClaw et le moteur d'inférence vLLM.

   make build PROFILE=openclaw-vllm

   Remarque

   La première construction implique des étapes telles que l'installation des pilotes GPU. Veuillez patienter.

   Une fois la construction terminée, les deux images suivantes sont générées :

   Type d'image	Description
   Image de production	Version renforcée en sécurité avec serveur SSH supprimé et ne conservant que le runtime minimal, destinée au déploiement en production
   Image de débogage	Conserve l'accès SSH et les outils de débogage, réservée au dépannage

   Pendant le processus de construction, les valeurs de référence de l'image sont également téléchargées dans le journal de transparence Rekor. Un fichier de métadonnées .rekor-meta.json est généré pour la vérification lors du déploiement.

Étape 2 : Déployer l'image de confiance sur une instance

Déployez l'image de confiance sur une instance gn8v-tee et établissez un canal chiffré de bout en bout via TNG.

1. Sur la machine de déploiement, exécutez la commande suivante pour créer une instance gn8v-tee à l'aide de l'image de confiance. Une fois l'instance créée, une attestation à distance est effectuée sur l'instance et les ressources confidentielles sont téléchargées.

   make deploy PROFILE=openclaw-vllm RV_MODE=rekor

   Le tableau suivant décrit les paramètres clés :

   Paramètre	Description
   PROFILE=openclaw-vllm	Le profil de déploiement à utiliser
   RV_MODE=rekor	Vérifie les valeurs de référence de l'image via le journal de transparence Rekor pendant le déploiement

   Le déploiement crée les ressources suivantes dans le cloud :

   • Bucket OSS : un espace de stockage privé utilisé pour télécharger et héberger l'image VM de confiance (.qcow2).

   • Image personnalisée ECS : importée depuis le fichier image OSS vers la bibliothèque d'images personnalisées Alibaba Cloud ECS.

   • Instance de calcul confidentiel GPU ECS : une instance de calcul confidentiel ecs.gn8v-tee.4xlarge associée au groupe de sécurité et au vSwitch. Les paramètres de démarrage UKI incluent la configuration du défi d'attestation à distance.

   • Groupe de sécurité : ouvre les ports SSH (22) et TNG (18789), en n'autorisant l'accès qu'à partir du bloc CIDR spécifié.

   Remarque

   Par défaut, l'image de débogage est déployée. Pour déployer l'image de production (sans accès SSH), spécifiez manuellement le fichier image.

   Important

   Pendant le déploiement, l'image est téléchargée vers OSS et les modèles sont téléchargés depuis ModelScope, ce qui nécessite un accès Internet et engendre des frais de trafic.

2. Démarrez le client TNG sur la machine de déploiement pour établir un canal chiffré RATS-TLS entre la machine de déploiement et l'instance gn8v-tee dans le cloud.

   make connect-tng

   Après une connexion réussie, la sortie affiche les URL HTTP et WebSocket ainsi que le jeton d'accès pour OpenClaw. Toutes les communications ultérieures sont protégées par le chiffrement RATS-TLS.

3. Vérifiez si le service OpenClaw est prêt via le tunnel TNG.

   curl -s http://localhost:18789/health

   Une fois qu'un statut sain est retourné, vous pouvez procéder à l'accès au service.

Étape 3 : Accéder au service OpenClaw protégé par le calcul confidentiel

Une fois le service prêt, accédez à OpenClaw via l'une des quatre méthodes suivantes.

ssh -L 18789:127.0.0.1:18789 root@<deployment machine IP>

ssh -L 18789:127.0.0.1:18789 root@<deployment machine IP>

npm install -g openclaw@latest --registry=https://registry.npmmirror.com

openclaw tui --url ws://localhost:18789 --token <gateway-token>

make destroy PROFILE=openclaw-vllm

Vérifier la fiabilité de l'environnement d'exécution

OpenClaw intègre une compétence tdx-remote-attestation qui déclenche automatiquement une attestation à distance lorsque des questions liées à la sécurité sont posées, permettant ainsi de vérifier l'état de sécurité de l'environnement d'exécution actuel.

Comment déclencher : posez des questions relatives à la sécurité dans DingTalk, l'interface Web ou l'interface TUI, par exemple « Mes données sont-elles sécurisées ? » ou « Cet environnement est-il fiable ? ».

Contenu retourné :

Vérifier l'application de la politique PEP

PEP (Policy Enforcement Point) est un mécanisme de filtrage au moment de l'exécution pour les agents IA confidentiels. Lorsqu'un agent tel qu'OpenClaw exécute une commande via l'outil exec, la requête passe d'abord par cai-pep pour la mise en correspondance des politiques, puis s'exécute dans un bac à sable Docker isolé (mode réseau none). Des politiques configurables imposent des restrictions obligatoires sur les outils disponibles pour l'agent, prévenant ainsi les risques de sécurité liés à l'injection de prompt malveillante.

PEP offre trois niveaux de protection :

1. Blocage au niveau des commandes : rejette les commandes à haut risque sur la base d'une liste de blocage, telles que curl, wget, nc, ssh et docker.

2. Blocage au niveau des chemins : empêche l'accès aux chemins sensibles, tels que /etc, /proc, /root et /home/openclaw/.openclaw.

3. Isolation réseau : le bac à sable n'a aucun accès réseau. Même si une commande contourne la liste de blocage, elle ne peut pas établir de connexions sortantes.

Le fichier de politique par défaut se trouve à l'emplacement ~/confidential-agent/image/customize/files/cai-pep-default-policy.json sur la machine de déploiement. Vous pouvez modifier la liste de blocage des commandes, la liste de blocage des chemins et les limites de ressources avant de construire l'image.

Si un agent est compromis par une injection de prompt malveillante et qu'un attaquant tente d'établir un shell inversé ou de télécharger une charge utile malveillante, PEP bloque automatiquement ces opérations à haut risque :

Vérifier l'intégrité de la chaîne d'approvisionnement

Le déploiement utilise par défaut le journal de transparence Rekor pour stocker les valeurs de référence des images. Lors de l'attestation à distance, les valeurs de référence sont automatiquement récupérées depuis Rekor pour vérification. Vous pouvez auditer les entrées du journal Rekor pour vérifier l'intégrité de la chaîne d'approvisionnement en utilisant les méthodes suivantes.

cat ~/confidential-agent/image/output/slsa-output-cai-openclaw-vllm-debug-*/rekor-v1-upload.txt

Created entry at index 1205944956, available at: https://rekor.sigstore.dev/api/v1/log/entries/<uuid>

rekor-cli verify --log-index 1205944956 --rekor_server https://rekor.sigstore.dev

Computed Root Hash: 1291abcee27148a4c00241ba8719f798ce060e8a5ccc8b18249017c25c6d0090
Expected Root Hash: 1291abcee27148a4c00241ba8719f798ce060e8a5ccc8b18249017c25c6d0090

rekor-cli loginfo --rekor_server https://rekor.sigstore.dev

Verification Successful!