DevOps AgentのSandbox機能(プレビュー)でDuckDBを実行してみた

こんにちは。たかやまです。

AWS DevOps Agentに、調査中にサンドボックス化されたLinux環境でコードを書いて実行できるSandbox機能がプレビュー公開されました。

https://docs.aws.amazon.com/devopsagent/latest/userguide/configuring-integrations-and-knowledge-sandbox.html

これまでDevOps Agentはエージェント自身の推論機能を中心に調査を進めていましたが、Sandboxにより大きなログの解析や複数メトリクスの統計計算など、コード実行が向いている処理はエージェント自身が許可されたツールを元にコード実行を行えるようになります。

今回はこのSandbox機能を使ってDuckDBを使ったCloudTrailログの調査をためしてみたいと思います。

さきにまとめ

• SandboxはDevOps Agentに調査（investigation）中のコード実行環境を提供するプレビュー機能
• Agent Space単位でオプトインする設定であり、デフォルトでは無効
• ネットワークアクセスは明示的なAllowリストで制御し、デフォルトはAWSサービスエンドポイントのみ許可
• サンドボックス内のAWS CLI/boto3呼び出しもエージェント本来の権限スコープに制限され、権限昇格はしない
• プレビュー期間中はus-east-1、us-west-2、ap-northeast-1、eu-west-1の4リージョンのみ対応

Sandboxとは

Sandboxは、AWS DevOps Agentに調査中のコード記述・実行を可能にする、安全で隔離されたLinux環境を提供するプレビュー機能です。

一部の問題は推論だけよりもコードを使う方が速く確実に解決できケースがあります。

Sandbox機能では、エージェントは推論を計算処理で補完できるようになり、大きなログファイルの解析、複数メトリクスにまたがる統計計算、調査中の複数データソースのパース・相関分析などに利用できるようになります。

Sandbox is a preview feature that gives AWS DevOps Agent a secure, isolated Linux environment where it can write and run code during investigations. Some problems are faster and more reliable to solve with code than through reasoning alone. With Sandbox, the agent complements its reasoning with computation—for example, to analyze a large log file, calculate statistics across a set of metrics, or parse and correlate data from multiple sources during an investigation.

日本語訳 :
Sandboxは、AWS DevOps Agentに調査中のコード記述・実行を可能にする、安全で隔離されたLinux環境を提供するプレビュー機能である。一部の問題は推論だけよりもコードを使う方が速く確実に解決できる。Sandboxにより、エージェントは推論を計算処理で補完できる。例えば大きなログファイルの解析、複数メトリクスにまたがる統計計算、調査中の複数データソースのパース・相関分析などに利用する。
https://docs.aws.amazon.com/devopsagent/latest/userguide/configuring-integrations-and-knowledge-sandbox.html

ちなみにプレビュー期間中はエージェントは調査（investigation）時のみ利用可能です。
チャットやカスタムエージェントなど他の機能への対応は近日提供予定となっています。

Note
During preview, the agent uses Sandbox only during investigations. Support for chat, custom agents, and other DevOps Agent capabilities is coming soon.

日本語訳 :
プレビュー期間中、エージェントは調査（investigation）時のみサンドボックスを使用する。チャット、カスタムエージェント、その他のDevOps Agent機能への対応は近日提供予定。
https://docs.aws.amazon.com/devopsagent/latest/userguide/configuring-integrations-and-knowledge-sandbox.html

動作の仕組み

Agent SpaceでSandboxを設定すると、調査ごとに新しいLinux環境が自動プロビジョニングされます。

• 環境内でシェルコマンドの実行、ファイルの読み書きが可能。実行結果はエージェントの分析に読み戻される
• 環境は調査の期間だけ存続し、2つの調査が同じ環境を共有することはない（ephemeral、調査単位でスコープ）
• 環境には接続済みAWSアカウント用のAWSプロファイルが事前設定され、AWS CLIやboto3呼び出しができる。ただし権限はエージェントが元々持つものと同一スコープに制限される
• コマンドラインツールやPython/Node.jsライブラリを使い、ネットワークポリシーで許可されたホスト・パスへHTTPリクエストも送信できる
• スキルもサンドボックスのファイルシステムから読み込まれるようになり、Markdown等の非実行ファイルだけでなく、スキルに同梱された実行可能コードを走らせられるようになる（Sandbox非有効時は非実行ファイルのみ）

これまでSkillsに同梱できるのはMarkdownの指示・リファレンス・データファイルなど非実行ファイルのみでしたが、Sandbox有効化後はスキルに実行可能コードを持たせて、エージェントがサンドボックス内でそれを実行・活用できるようになります。

やってみる

Sandboxの有効化はAgent Space単位で行います。

デフォルトではSandbox設定は未設定であり、明示的にオプトインするまでエージェントはコードを実行しません。

事前インストールパッケージの設定

pipパッケージ（例: requests, pandas）、npmパッケージ（例: axios）を個別に追加できます。

事前インストールしておくことで、実行時にパッケージレジストリへの送信アクセスを許可する必要がなくなります。

今回はDuckDBを使った調査を試してみたいと思うので、DuckDBを事前インストールしておきます。

動作確認

では、実際にSandboxを有効化した状態で調査を実行しSandboxの動作を確認してみます。

チャットからS3バケットのCloudTrailログをDuckDBを使って分析するように指示してみます。

Sandboxで設定した通り、DuckDbについてはパッケージ 1.4.5 がインストールされ利用可能なことが確認できましたが、その後エージェントがhttpfs拡張のダウンロードで失敗したことを確認できました。

DuckDBはS3を直接読むのに必要なhttpfs拡張が必要となります。
今回は拡張の取得先であるextensions.duckdb.orgをネットワークポリシーに登録していなかったため、接続が拒否されたようです。

_duckdb.IOException: IO Error: Failed to download extension "httpfs" at URL "http://extensions.duckdb.org/v1.4.5/linux_arm64/httpfs.duckdb_extension.gz"
Extension "httpfs" is an existing extension.

For more info, visit https://duckdb.org/docs/stable/extensions/troubleshooting?version=v1.4.5&platform=linux_arm64&extension=httpfs (ERROR Could not establish connection)

なので、Sandbox設定でネットワークポリシーを設定します。今回は検証用に全てのホストを許可するように設定します。

なお、今回は検証がてらネットワーク経由で拡張のダウンロードを試してみましたが、httpfs拡張についてもサンドボックス設定で事前にプリインストールすることが良いと思います。

この状態で再度調査依頼をチャットから実行してみます。
（再試行の中で調査内容は変えています）

次はhttpfs拡張のダウンロードが成功し、DuckDBでS3のCloudTrailログを直接クエリできることを確認できました。

無事、DuckDBを使ってCloudTrailのログ調査のサマリを得ることができました。
私がやっていた作業のログが出ているので調査内容も問題なさそうです。

ただ、今回のケースではエージェント判断で httpfs 拡張 でのクエリではなく、ローカルダウンロード方式で最終的にはクエリをして調査をしたようですね

通常は、DevOps Agentは additional permissions で Athenaの権限を付与してクエリを実行するアプローチが考えられますが、Sandbox機能を利用することでDevOps Agent自身でクエリを実行することができるようになります。

セキュリティモデルと制約

セキュリティモデル

Sandboxのセキュリティモデルは以下の通りです。

• 調査ごとに個別のサンドボックス環境で隔離される。ある調査のコード・データが別の調査と共有されることはない
• DevOps Agentはサンドボックスから出るすべてのトラフィックを検査・フィルタリングし、AWSサービスエンドポイントへのリクエストとネットワークアローリストに一致するホストへのリクエストのみを許可、それ以外はすべて拒否する
• 環境には接続済みAWSアカウント用のAWSプロファイルが事前設定され、AWS CLI/boto3呼び出しに使えるが、権限はエージェントが本来持つ権限と同一スコープに制限される（昇格しない）
• セキュリティ推奨事項として、アローリストは最小限に保つ、広いワイルドカード（**, /**）ではなく厳密なホスト・パスパターンを使う、パッケージレジストリへのアローリストではなく事前インストールで対応する、の3点が明記されている

Sandboxは「読み取り専用・非mutate」の原則そのものを変更するものではなく、その原則の範囲内で「計算・コード実行」という新しい手段を調査に追加するものと位置づけられます。

サンドボックス内のAWS CLI/boto3呼び出しも「エージェントが元々持つ権限と同一スコープ」に制限されると明記されており、Sandbox経由で権限が拡大されるわけではありません。

ただし、サンドボックス環境自体（Linux環境でのシェルコマンド実行）という新しい実行面が追加される点は、従来の「読み取り専用ツール呼び出しのみ」から拡張されたと言えます。

ネットワークポリシー

前述の通り、アローリストが空の場合はAWSサービスエンドポイント以外への送信リクエストがすべて拒否されます。

外部APIやパッケージレジストリにアクセスさせたい場合は、Host pattern・HTTP methods・Path patternsを組み合わせて明示的に許可する必要があります。

権限スコープ

こちらも前述の通り、サンドボックス内のAWSプロファイルはエージェント本来の権限スコープに制限されるため、IAMロールの権限モデル（最小権限、read-only中心）自体はSandbox導入によって変更されません。

クォータ

Sandbox configuration limitsとして以下の上限値が設定されています。

対応リージョン（プレビュー期間中）

プレビュー期間中は以下4リージョンのみ対応です。

同じくプレビュー中の「Release management」機能はus-east-1のみの対応なので、Sandboxの方が対応リージョンが広くなっています。

Sandboxの削除（オプトアウト）

Agent Spaceの「Capabilities」タブ「Sandbox」セクションで「Remove」を選択すると、以降の新規調査に対してサンドボックス環境はプロビジョニングされなくなります。

最後に

今回はDevOps Agentの新機能であるSandboxのプレビュー内容を確認してみました。

これまでエージェントの手段は「読み取り・推論」が中心でしたが、Sandboxによって「調査中にコードを書いて実行する」という新しい手段が加わった形です。ログ解析や複数メトリクスの相関分析など、推論だけでは時間がかかる処理をコード実行で補える点は期待が持てそうです。

一方でネットワークアローリストや権限スコープの制約はしっかり作り込まれており、既存の「読み取り専用・非mutate」というガードレールの原則を崩さない設計になっている点も安心材料でした。

実機での検証やタイムアウト・料金まわりの未確認事項については、追って確認でき次第追記していきたいと思います。

以上、たかやま(@nyan_kotaroo)でした。