Elastic Compute Service:g9i TDX コンフィデンシャルコンピューティングインスタンスでの OpenClaw コンフィデンシャル AI エージェントのワンクリック構築

セキュリティアーキテクチャ

コンフィデンシャル エージェントのデプロイでは、すべてのコアデータが TEE (信頼された実行環境) の境界内で処理されます。以下の資産が保護されます：

セキュリティアーキテクチャは、下から上に、ハードウェア、ブートチェーン、ランタイム、キー管理、通信の 5 つのレイヤーをカバーしています：

デプロイメントアーキテクチャ

デプロイメントプロセスは以下の通りです：

1. 認証情報の準備：デプロイマシンで Alibaba Cloud AccessKey、Model Studio API キー、および (オプション) DingTalk 認証情報をエクスポートします。

2. ワンクリックデプロイメント：ワンクリックデプロイメントスクリプトを実行します。これにより、依存関係のインストール、信頼できるイメージの構築、参照値のアップロード、クラウドリソースの作成、リモートアテステーションの実行、シークレットのインジェクトが自動的に行われます。

3. 暗号化チャネルの確立：スクリプトは TNG 接続トンネルを自動的に開始し、デプロイマシンと TDX インスタンスの間に RATS-TLS 暗号化チャネルを確立します。

4. サービスへのアクセス：DingTalk、Web、デスクトップクライアント、または TUI を通じて OpenClaw にアクセスします。すべてのトラフィックは、RATS-TLS 暗号化チャネルを通じて TDX インスタンスに入ります。

ステップ 1：認証情報の準備

ワンクリックデプロイ スクリプトでは、クラウドリソース (Elastic Compute Service (ECS) インスタンス、Virtual Private Cloud (VPC)、セキュリティグループなど) を作成するための Alibaba Cloud AccessKey と、OpenClaw にモデル推論機能を提供するための Model Studio API キーが必要です。デプロイマシンで次のコマンドを実行し、認証情報を環境変数としてエクスポートします。

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

上記のコマンド内のプレースホルダーは、実際の値に置き換えてください。次の表にパラメーターを示します。

DingTalk 統合を有効にする場合は、次のコマンドを実行します：

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

<YOUR_DINGTALK_CLIENT_ID> と <YOUR_DINGTALK_CLIENT_SECRET> は、DingTalk 企業内部アプリケーションの Client ID と Client Secret です。アプリケーションを作成した後、DingTalk Developer Portal から取得します。

ステップ 2：ワンクリックデプロイの実行

デプロイマシンで次のコマンドを実行し、インタラクティブモードでのデプロイを開始します：

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

スクリプトはデフォルトでインタラクティブモードで起動し、不足している Alibaba Cloud 認証情報、Model Studio API キー、DingTalk 認証情報、OpenClaw Gateway Token、オペレーター CIDR の入力を求めます。主なデフォルト構成は次のとおりです：

ワンクリック スクリプトはデプロイマシンのパブリック IP を自動検出し、インタラクティブモードでオペレーターのアクセス CIDR の入力を求めます：

非インタラクティブデプロイの例：

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

クラウドリソースを作成せずに、ローカル依存関係のインストールと、コンフィデンシャル エージェントのコンポーネントおよびツールイメージのビルドのみを行うには、次のコマンドを実行します：

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

非インタラクティブで 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

ステップ 3：デプロイの待機と確認

スクリプトは次の処理を自動的に実行します：

1. デプロイマシンの依存関係をインストールします。

2. confidential-agent、confidential-agentd、cai-pep をビルドし、confidential-agent を /usr/local/bin にインストールします。

3. confidential-agent-tools:latest をビルドし、イメージ内のバージョンに一致する OpenClaw CLI をデプロイマシンにインストールします。

4. FDE、dm-verity、UKI を有効化した OpenClaw の信頼できるイメージをビルドします。

5. イメージの参照値を Rekor 透明性ログにアップロードします。

6. Alibaba Cloud リソースを作成し、TDX ECS インスタンスを起動します。

7. リモートアテステーションに合格した後、OpenClaw の設定、Model Studio API キー、DingTalk 認証情報、Gateway Token をインジェクトします。

8. ローカルの TNG connect トンネルを起動し、Web 到達性チェック、Gateway WebSocket プローブ、チャットプローブを実行します。チャットプローブでは、Model Studio API の実際の応答を使用して、エンドツーエンドの可用性を確認します。

デプロイが成功すると、スクリプトは次のような情報を出力します：

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>"

ステップ 4：OpenClaw サービスへのアクセス

サービスの準備ができたら、次の 4 つの方法で OpenClaw にアクセスできます。すべてのトラフィックは TNG RATS-TLS チャネルを介して TDX インスタンスに入ります。

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>

ステップ 5 (オプション)：リソースの解放

サービスが不要になったら、デプロイマシンで次のコマンドを実行し、クラウドリソースを解放します：

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

信頼できる実行環境の検証

OpenClaw には、tdx-remote-attestation スキルが組み込まれています。セキュリティ関連の質問を受けると、リモートアテステーションを自動的にトリガーし、現在の実行環境のセキュリティ状態を検証します。

トリガー方法：DingTalk、Web、または TUI で、「Is my data safe?」、「Is this environment trusted?」、「Verify the current TDX execution environment.」などのセキュリティ関連の質問をします。

応答内容：

PEP ポリシーの適用の検証

cai-pep は、機密 AI エージェント向けに設計されたランタイムゲートメカニズムです。OpenClaw が exec ツールを介してコマンドを実行する際、リクエストは隔離された Docker サンドボックスに入る前に cai-pep を通過し、ポリシーと照合されます。

PEP は 3 つの保護レイヤーを提供します：

1. コマンドレベルのインターセプト：curl、wget、nc、ssh、docker など、ブロックリストに基づいて高リスクのコマンドをブロックします。

2. パスレベルのインターセプト：/etc、/proc、/root、OpenClaw の設定ディレクトリなど、機密性の高いパスへのアクセスをブロックします。

3. ネットワーク分離：サンドボックスにはデフォルトでネットワーク権限がないため、コマンドがブロックリストを回避した場合でも、アウトバウンド接続を防止します。

次のコマンドは PEP によってブロックされます：

例えば、エージェントが次のコマンドを実行してクラウドメタデータサービスにアクセスしようとした場合：

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

PEP は curl がコマンドブロックリストに含まれていることを識別し、リクエストを即座に拒否して拒否メッセージを返すことで、認証情報の漏洩を防止します。

サプライチェーンの整合性の検証

デプロイプロセスでは、デフォルトで Rekor 透明性ログを使用してイメージ参照値を保存します。リモートアテステーション中に、システムは検証のために Rekor からログエントリを自動的に取得します。次の方法で Rekor のログエントリを監査し、サプライチェーンの整合性を検証できます。

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!

セキュリティグループルール

セキュリティグループルールは、ワンクリックデプロイ中に自動的に作成されます。後から変更する必要がある場合は、次のポートを保持してください：

Model Studio API キーとクォータ

Model Studio API キーによって、インスタンスで使用可能なモデルとクォータが決まります。推奨事項は次のとおりです：

1. 必要最小限のクォータが設定された API キーを使用してください。プライマリアカウントキーの使用は避けてください。

2. インジェクション後に定期的にローテーションするには、secrets/gateway.token を削除し、DASHSCOPE_API_KEY を再エクスポートして、ワンクリックスクリプトを再実行します。

3. Model Studio コンソールのアクセス監査機能を使用して、異常な呼び出し量に対するアラートを設定してください。

peering 'ops' already exists with a different CIDR

原因：現在の状態ディレクトリに、異なる CIDR を持つオペレーターピアリングがすでに存在します。

解決策：既存のピアリングに一致する --allowed-cidr を渡すか、インタラクティブモードで置き換えを確認するか、非インタラクティブモードで --yes を追加します。

Shelter is required または SLSA generator is required

原因：デプロイマシンに Shelter がインストールされていないか、Rekor モードで SLSA ジェネレーターが見つかりません。

解決策：

• hack/ ディレクトリに shelter-*.rpm が存在することを確認するか、--shelter-rpm で RPM パスを指定してください。

• Shelter RPM を再インストールし、/usr/libexec/shelter/slsa/slsa-generator が存在することを確認してください。

• ローカル開発およびテスト専用として、--reference-values sample を使用して Rekor プロセスをスキップしてください。

Web ポートにアクセスできない

原因とトラブルシューティング：

1. connect.log を確認してください： tail -F "$HOME/.confidential-agent/one-click/connect.log"。

2. ECS インスタンスのセキュリティグループが ops および deployer オペレーターピアリングを許可していることを確認してください。

3. デプロイマシンのパブリック IP が変更された場合は、ワンクリック スクリプトを再実行するか、peering remove deployer を実行して、新しい IP で新しい deployer ピアリングを追加してください。

チャットプローブが失敗する

原因：このソリューションでは推論は Model Studio API によって実行されるため、チャットプローブの失敗は、通常、Model Studio 側の設定に起因します。

解決策：

1. DASHSCOPE_API_KEY が正しく、アクティブであることを確認してください。

2. Model Studio コンソールで、選択したモデルが利用可能で、料金の未払いがないことを確認してください。

3. デバッグ SSH 経由でゲストにログインし、OpenClaw ゲートウェイログを確認してください。

DingTalk が応答しない

原因とトラブルシューティング：

1. デプロイメント中に --enable-dingtalk が渡されたか、インタラクティブモードで DingTalk が有効化されたことを確認してください。

2. ゲストの openclaw status で DingTalk チャネルが ON と表示されているかどうかを確認してください。

3. journalctl -u cai-openclaw-gateway.service -n 200 --no-pager で dingtalk 接続エラーを確認してください。HTTP 401 が表示される場合は、DingTalk の クライアント ID と クライアントシークレット が DingTalk オープンプラットフォームのものと一致していることを確認してください。

4. DingTalk アプリケーションがメッセージの送受信に必要な権限を持っていることを確認してください。

cai-pep がすべてのツールコールを拒否する

原因：PEP ポリシー設定が正しくないか、サービスが正しく起動していません。

解決策：デバッグイメージでデプロイした後、SSH 経由で TDX インスタンスにログインし、cai-pep ログで具体的なインターセプトの理由を確認してください。

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