RayのgVisorサンドボックス、network="public"の通信範囲とAPIキーの扱い

外部APIを呼ぶ生成コードを試すなら、network="public"へ切り替える前に、許可する接続先とコードへ渡す情報を決めます。渡したコードとデータだけで処理できる場合は、既定のnetwork="none"を維持して試せます。Ray 2.58.0のgVisor連携は試験版で、通信の許可と情報の扱いを利用側で設計する必要があります。 [2] [3] [6]

外部接続が必要な処理かを先に分ける

原記事の論点サンドボックス API → ネットワークの設定

確認に使った資料Ray 2.58.0：Ray Sandboxes／Ray 2.58.0：gVisorバックエンドの実装／Ray開発版：Networking and DNS（2026年9月8日確認） — Networking and DNS・publicの実装 [2] [4] [5]

サンドボックス内から外部へアクセスしない処理では、noneで外向き通信を止めたまま、コード実行と結果回収を試します。外部APIへの接続が必要ならpublicが選択肢になりますが、この名前は「公開インターネットだけに接続を限定する」という意味ではありません。 [2] [3] [4]

2.58.0の実装はpublicをgVisorのホストネットワーク設定へ渡します。内部サービスを遮断する設定とはみなせないため、特定のAPIだけを許可したい場合は、ワーカーノードやクラスタ側で設ける通信制御も確認します。 [4] [6]

採用版を確認する理由もここにあります。2026年9月8日のmaster版は、pastaで専用のネットワーク空間をノードへ接続する別の構成です。それでも他のRayノードや内部サービスに到達し得ると明記されており、開発版の準備手順を2.58.0にも使えるとは判断せず、採用版に合わせて確認します。 [4] [5]

接続テストでは、必要なAPIへ通信できることと、禁止した通信が拒否されることを、管理下の検証先で別々に確かめます。APIの呼び出し成功だけでは、宛先制限が働いているとは判断できません。拒否を確認できない場合は、接続先を限定した構成として扱わず、外側の制御を見直します。 [4] [5] [6]

APIキーを渡す前に、入力と出力の経路を確認する

原記事の論点サンドボックス API → 環境変数と作業ディレクトリの設定／ネットワークの設定 ／ gVisor を選ぶ理由 → 生成コードを信頼できないものとして扱いgVisorで追加の隔離を設ける

確認に使った資料Ray 2.58.0：SandboxRuntimeの実装／Ray 2.58.0：gVisorバックエンドの実装／gVisor：Security Model — S3：env／S4：stdout返却／S7：許可されたファイルへのアクセス [3] [4] [6]

gVisorは実行コードとホストの間に隔離を追加しますが、コードが読める環境変数やファイルとして渡したキーを、そのコードから隠す機能ではありません。まず認証に必要な情報を特定し、何を渡すかを通信設定と分けて決めます。 [3] [6]

例えば、環境変数で受け取った値をコードが標準出力へ書けば、実行結果を受け取る側にも値が返ります。noneで外向き通信を止めても、標準出力やファイルをRay経由で回収する経路は残ります。通信を止めたことだけで、出力に秘密が含まれないとは判断できません。 [2] [3] [4] [6]

組み込み前の確認には、秘密ではない識別用の値を使う方法があります。コードがその値を出力した場合に、結果を受け取る画面・ログ・保存先のどこへ流れるかを追い、誰が読めるかを確認します。実際のキーを渡す判断は、必要な接続先の制御と、入力・出力の扱いを確認してから行います。この確認で任意のコードの安全性を保証できるわけではありません。 [3] [4] [6]