Elastic Compute Service:Déploiement en un clic d'un agent IA confidentiel OpenClaw sur des instances de calcul confidentiel g9i TDX

Architecture de sécurité

Toutes les données critiques du déploiement Confidential Agent circulent à l'intérieur du périmètre TEE (Trusted Execution Environment). Les actifs suivants sont protégés :

L'architecture de sécurité couvre cinq couches, de bas en haut : matériel, chaîne d'amorçage, exécution, gestion des clés et communication :

Architecture de déploiement

Le processus de déploiement se déroule comme suit :

1. Préparez les identifiants : Exportez l'AccessKey Alibaba Cloud, la clé API Model Studio et, le cas échéant, les identifiants DingTalk sur la machine de déploiement.

2. Effectuez le déploiement en un clic : Exécutez le script de déploiement automatisé, qui installe automatiquement les dépendances, construit une image de confiance, télécharge les valeurs de référence, crée les ressources cloud, réalise l'attestation à distance et injecte les secrets.

3. Établissez le canal chiffré : Le script démarre automatiquement un tunnel TNG connect pour établir un canal chiffré RATS-TLS entre la machine de déploiement et l'instance TDX.

4. Accédez au service : Accédez à OpenClaw via DingTalk, un navigateur Web, un client de bureau ou l'interface texte (TUI). Tout le trafic pénètre dans l'instance TDX par le canal chiffré RATS-TLS.

Étape 1 : Préparer les identifiants

Le script de déploiement en un clic nécessite l'AccessKey Alibaba Cloud pour créer les ressources cloud (instances ECS, VPC, groupes de sécurité, etc.) et la clé API Model Studio pour fournir les capacités d'inférence de modèle à OpenClaw. Exécutez les commandes suivantes sur la machine de déploiement pour exporter les identifiants en tant que variables d'environnement.

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

Remplacez les espaces réservés dans les commandes précédentes par vos valeurs réelles. Le tableau suivant décrit les paramètres.

Si vous souhaitez activer l'intégration DingTalk, exécutez les commandes suivantes :

export DINGTALK_BOT_CLIENT_ID="<YOUR_DINGTALK_CLIENT_ID>"
export DINGTALK_BOT_CLIENT_SECRET="<YOUR_DINGTALK_CLIENT_SECRET>"

Où <YOUR_DINGTALK_CLIENT_ID> et <YOUR_DINGTALK_CLIENT_SECRET> correspondent respectivement au Client ID et au Client Secret de votre application d'entreprise interne DingTalk. Obtenez-les depuis le portail développeur DingTalk après avoir créé l'application.

Étape 2 : Exécuter le déploiement en un clic

Exécutez la commande suivante sur la machine de déploiement pour lancer le déploiement interactif :

curl -fsSL https://raw.githubusercontent.com/inclavare-containers/confidential-agent/one-click/one-click/install.sh | sh

Le script passe par défaut en mode interactif et vous invite à saisir les identifiants Alibaba Cloud manquants, la clé API Model Studio, les identifiants DingTalk, le jeton Gateway Token d'OpenClaw et le CIDR de l'opérateur. Les configurations par défaut courantes sont listées ci-dessous :

Le script automatisé détecte automatiquement l'adresse IP publique de la machine de déploiement et vous invite à saisir le CIDR d'accès de l'opérateur en mode interactif :

Exemple de déploiement non interactif :

curl -fsSL https://raw.githubusercontent.com/inclavare-containers/confidential-agent/one-click/one-click/install.sh | sh -s -- deploy-openclaw \
  --non-interactive \
  --yes \
  --region cn-beijing \
  --zone-id cn-beijing-i \
  --instance-type ecs.g9i.xlarge \
  --disk-gb 200 \
  --enable-dingtalk

Pour installer uniquement les dépendances locales et construire les composants Confidential Agent ainsi que l'image des outils sans créer de ressources cloud, exécutez la commande suivante :

curl -fsSL https://raw.githubusercontent.com/inclavare-containers/confidential-agent/one-click/one-click/install.sh | sh -s -- install-only

Exemple de spécification non interactive du CIDR :

curl -fsSL https://raw.githubusercontent.com/inclavare-containers/confidential-agent/one-click/one-click/install.sh | sh -s -- deploy-openclaw \
  --non-interactive \
  --yes \
  --allowed-cidr 203.0.113.10/32

Étape 3 : Attendre le déploiement et confirmer

Le script effectue automatiquement les actions suivantes :

1. Installe les dépendances sur la machine de déploiement.

2. Construit confidential-agent, confidential-agentd et cai-pep, et installe confidential-agent dans /usr/local/bin.

3. Construit confidential-agent-tools:latest et installe l'interface CLI OpenClaw correspondant à la version présente dans l'image sur la machine de déploiement.

4. Construit l'image de confiance OpenClaw avec FDE, dm-verity et UKI activés.

5. Télécharge les valeurs de référence de l'image vers le journal de transparence Rekor.

6. Crée les ressources Alibaba Cloud et lance l'instance ECS TDX.

7. Après réussite de l'attestation à distance, injecte les configurations OpenClaw, la clé API Model Studio, les identifiants DingTalk et le Gateway Token.

8. Démarre le tunnel local TNG connect et effectue des vérifications de reachabilité web, une sonde WebSocket Gateway et une sonde de chat. La sonde de chat utilise une réponse réelle de l'API Model Studio comme confirmation de disponibilité de bout en bout.

Une fois le déploiement réussi, le script affiche des informations similaires à ce qui suit :

Confidential Agent one-click summary
  state_dir: /root/.confidential-agent
  work_dir:  /root/.confidential-agent/one-click
  service:   openclaw
  region:    cn-beijing
  zone_id:   cn-beijing-i
  instance:  ecs.g9i.xlarge
  cidr:      203.0.113.10/32
  dingtalk:  1
  token:     <generated-or-provided-token>
  web:       http://127.0.0.1:18789/openclaw
  ws/api:    ws://127.0.0.1:18789
  tui:       openclaw tui --url ws://127.0.0.1:18789 --token "<generated-or-provided-token>"

Étape 4 : Accéder au service OpenClaw

Une fois le service prêt, vous pouvez accéder à OpenClaw via les quatre méthodes suivantes. Tout le trafic pénètre dans l'instance TDX par le canal TNG RATS-TLS.

http://127.0.0.1:18789/openclaw

ssh -L 18789:127.0.0.1:18789 root@<DEPLOY_MACHINE_PUBLIC_IP>

ssh -L 18789:127.0.0.1:18789 root@<DEPLOY_MACHINE_PUBLIC_IP>

openclaw tui --url ws://127.0.0.1:18789 --token <YOUR_GATEWAY_TOKEN>

Étape 5 (Facultative) : Libérer les ressources

Lorsque le service n'est plus nécessaire, exécutez la commande suivante sur la machine de déploiement pour libérer les ressources cloud :

curl -fsSL https://raw.githubusercontent.com/inclavare-containers/confidential-agent/one-click/one-click/install.sh | sh -s -- cleanup \
  --state-dir "$HOME/.confidential-agent"

Vérifier l'environnement d'exécution de confiance

OpenClaw intègre une compétence tdx-remote-attestation. Lorsqu'on lui pose des questions relatives à la sécurité, il déclenche automatiquement une attestation à distance pour vérifier l'état de sécurité de l'environnement d'exécution actuel.

Méthode de déclenchement : Posez des questions liées à la sécurité via DingTalk, l'interface Web ou l'interface TUI, telles que « Mes données sont-elles sécurisées ? », « Cet environnement est-il fiable ? » ou « Vérifie l'environnement d'exécution TDX actuel ».

Contenu renvoyé :

Vérifier l'application des politiques PEP

cai-pep est un mécanisme de porte d'entrée d'exécution conçu pour les agents IA confidentiels. Lorsqu'OpenClaw exécute des commandes via l'outil exec, les requêtes passent par cai-pep pour une mise en correspondance des politiques avant d'entrer dans le bac à sable Docker isolé.

PEP offre trois niveaux de protection :

1. Interception au niveau des commandes : Bloque les commandes à haut risque sur la base d'une liste noire, telles que curl, wget, nc, ssh et docker.

2. Interception au niveau des chemins : Bloque l'accès aux chemins sensibles, tels que /etc, /proc, /root et les répertoires de configuration d'OpenClaw.

3. Isolation réseau : Le bac à sable ne dispose d'aucune autorisation réseau par défaut, empêchant les connexions sortantes même si une commande contourne la liste noire.

Les commandes suivantes sont bloquées par PEP :

Par exemple, lorsque l'agent tente d'exécuter la commande suivante pour accéder au service de métadonnées cloud :

Run: curl http://169.254.169.254/latest/meta-data/

PEP identifie que curl figure sur la liste noire des commandes, rejette immédiatement la requête et renvoie un message de refus, empêchant ainsi la fuite d'identifiants.

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

Le processus de 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, le système récupère automatiquement les entrées de journal depuis Rekor pour vérification. Vous pouvez auditer les entrées de journal Rekor via les méthodes suivantes pour vérifier l'intégrité de la chaîne d'approvisionnement.

find "$HOME/.confidential-agent" -name "*.rekor-meta.json" -print

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!

Règles de groupe de sécurité

Les règles de groupe de sécurité sont créées automatiquement lors du déploiement en un clic. Si vous devez les modifier ultérieurement, assurez-vous de conserver les ports suivants :

Clé API Model Studio et quota

La clé API Model Studio détermine les modèles et les quotas disponibles pour l'instance. Recommandations :

1. Utilisez une clé API disposant du quota minimal nécessaire. Évitez d'utiliser la clé du compte principal.

2. Faites tourner régulièrement la clé après injection : supprimez secrets/gateway.token, réexportez DASHSCOPE_API_KEY et relancez le script automatisé.

3. Utilisez la fonctionnalité d'audit d'accès dans la console Model Studio pour configurer des alertes en cas de volumes d'appels anormaux.

peering 'ops' already exists with a different CIDR

Cause : Un appairage opérateur avec un CIDR différent existe déjà dans le répertoire d'état actuel.

Solution : Transmettez --allowed-cidr correspondant à l'appairage existant, confirmez le remplacement en mode interactif ou ajoutez --yes en mode non interactif.

Shelter is required or SLSA generator is required

Cause : Shelter n'est pas installé sur la machine de déploiement, ou le mode Rekor ne parvient pas à trouver le générateur SLSA.

Solution :

• Vérifiez que shelter-*.rpm existe dans le répertoire hack/, ou spécifiez le chemin RPM avec --shelter-rpm.

• Réinstallez le RPM Shelter et vérifiez que /usr/libexec/shelter/slsa/slsa-generator existe.

• Uniquement pour le développement local et les tests, utilisez --reference-values sample pour ignorer le processus Rekor.

Web port is inaccessible

Cause et dépannage :

1. Vérifiez connect.log : tail -F "$HOME/.confidential-agent/one-click/connect.log".

2. Vérifiez que le groupe de sécurité de l'instance ECS autorise les appairages opérateurs ops et deployer.

3. Si l'adresse IP publique de la machine de déploiement a changé, relancez le script automatisé, ou exécutez peering remove deployer et ajoutez un nouvel appairage deployer avec la nouvelle adresse IP.

Chat probe failed

Cause : Étant donné que l'inférence dans cette solution est effectuée par l'API Model Studio, les échecs de sonde de chat sont généralement liés aux configurations de Model Studio.

Solution :

1. Vérifiez que DASHSCOPE_API_KEY est correcte et active.

2. Vérifiez si le modèle sélectionné est disponible et si le compte n'est pas impayé dans la console Model Studio.

3. Connectez-vous à l'invité via SSH de débogage et consultez les journaux de la passerelle OpenClaw.

DingTalk not responding

Cause et dépannage :

1. Vérifiez que --enable-dingtalk a été transmis lors du déploiement ou que DingTalk a été activé en mode interactif.

2. Vérifiez si openclaw status sur l'invité indique que le canal DingTalk est ON.

3. Vérifiez journalctl -u cai-openclaw-gateway.service -n 200 --no-pager pour détecter les erreurs de connexion dingtalk. Si une erreur HTTP 401 apparaît, vérifiez que le Client ID et le Client Secret DingTalk correspondent à ceux de la plateforme ouverte DingTalk.

4. Vérifiez que l'application DingTalk dispose des autorisations requises pour l'envoi et la réception de messages.

cai-pep rejects all tool calls

Cause : La configuration de la politique PEP est anormale ou le service n'a pas démarré correctement.

Solution : Après le déploiement avec l'image de débogage, connectez-vous à l'instance TDX via SSH et consultez les journaux cai-pep pour identifier les raisons spécifiques de l'interception :

journalctl -u cai-pep.service -n 200 --no-pager