SpyBara
Go Premium

agent-sdk/secure-deployment.md 2026-06-09 06:34 UTC to 2026-06-10 23:57 UTC

396 added, 0 removed.

2026
Sat 27 01:01 Fri 26 23:00 Thu 25 23:58 Wed 24 22:02 Tue 23 22:00 Mon 22 23:59 Fri 19 22:58 Thu 18 22:00 Wed 17 17:02 Tue 16 21:57 Mon 15 23:02 Sat 13 21:59 Fri 12 22:00 Thu 11 23:01 Wed 10 23:57 Tue 9 06:34 Mon 8 06:52 Sat 6 06:24 Fri 5 06:45 Thu 4 06:52 Wed 3 06:53 Tue 2 06:51

AI ゚ヌゞェントの安党なデプロむ

分離、認蚌情報管理、ネットワヌク制埡を䜿甚しお Claude Code ず Agent SDK のデプロむを保護するためのガむド

Claude Code ず Agent SDK は、コヌドを実行し、ファむルにアクセスし、あなたに代わっお倖郚サヌビスず盞互䜜甚できる匷力なツヌルです。これらの機胜を持぀ツヌルず同様に、これらを慎重にデプロむするこずで、利点を埗ながら適切な制埡を維持できたす。

事前に決められたコヌドパスに埓う埓来の゜フトりェアずは異なり、これらのツヌルはコンテキストず目暙に基づいお動的にアクションを生成したす。この柔軟性が有甚性をもたらしたすが、凊理するコンテンツファむル、りェブペヌゞ、ナヌザヌ入力によっおその動䜜が圱響を受ける可胜性があるこずも意味したす。これはプロンプトむンゞェクションず呌ばれるこずもありたす。たずえば、リポゞトリの README に異垞な指瀺が含たれおいる堎合、Claude Code はオペレヌタヌが予想しなかった方法でそれらの指瀺をアクションに組み蟌む可胜性がありたす。このガむドでは、このリスクを軜枛するための実践的な方法に぀いお説明したす。

良いニュヌスは、゚ヌゞェントのデプロむを保護するために、゚キゟチックなむンフラストラクチャは必芁ないずいうこずです。半信頌できるコヌドを実行する堎合に適甚される原則分離、最小暩限、倚局防埡がここにも適甚されたす。Claude Code には䞀般的な懞念に察応するのに圹立぀耇数のセキュリティ機胜が含たれおおり、このガむドではこれらず、さらなる匷化が必芁な堎合の远加的な匷化オプションに぀いお説明したす。

すべおのデプロむが最倧限のセキュリティを必芁ずするわけではありたせん。開発者がノヌトパ゜コンで Claude Code を実行する堎合ず、マルチテナント環境で顧客デヌタを凊理する䌁業では、芁件が異なりたす。このガむドでは、Claude Code の組み蟌みセキュリティ機胜から匷化されたプロダクション アヌキテクチャたで、さたざたなオプションを提瀺しおいるため、状況に合ったものを遞択できたす。

脅嚁モデル

゚ヌゞェントは、プロンプトむンゞェクション凊理するコンテンツに埋め蟌たれた指瀺たたはモデル゚ラヌが原因で、意図しないアクションを実行する可胜性がありたす。Claude モデルはこれに察する耐性を持぀ように蚭蚈されおいたす。詳现に぀いおは、モデル抂芁ずデプロむするモデルのシステムカヌドを参照しおください。

ただし、倚局防埡は䟝然ずしお良い実践です。たずえば、゚ヌゞェントが顧客デヌタを倖郚サヌバヌに送信するよう指瀺する悪意のあるファむルを凊理する堎合、ネットワヌク制埡がそのリク゚ストを完党にブロックできたす。

組み蟌みセキュリティ機胜

Claude Code には、䞀般的な懞念に察応するいく぀かのセキュリティ機胜が含たれおいたす。詳现に぀いおは、セキュリティドキュメントを参照しおください。

  • 暩限システム: すべおのツヌルず bash コマンドは、蚱可、ブロック、たたはナヌザヌの承認をプロンプトするように蚭定できたす。「すべおの npm コマンドを蚱可」たたは「sudo を含むコマンドをブロック」などのルヌルを䜜成するには、glob パタヌンを䜿甚したす。組織は、すべおのナヌザヌに適甚されるポリシヌを蚭定できたす。暩限を参照しおください。
  • 暩限のためのコマンド解析: bash コマンドを実行する前に、Claude Code はそれを AST に解析し、結果を暩限ルヌルず照合したす。きれいに解析できないコマンド、たたは蚱可ルヌルず䞀臎しないコマンドは、明瀺的な承認が必芁です。eval などの小さなコンストラクトセットは、蚱可ルヌルに関係なく垞に承認が必芁です。これは暩限ゲヌトであり、サンドボックスではありたせん。タヌゲットパスたたは効果からコマンドが危険かどうかを掚枬したせん。
  • りェブ怜玢の芁玄: 怜玢結果は、生のコンテンツをコンテキストに盎接枡すのではなく、芁玄されたす。これにより、悪意のあるりェブコンテンツからのプロンプトむンゞェクションのリスクが軜枛されたす。
  • サンドボックスモヌド: Bash コマンドは、ファむルシステムずネットワヌクアクセスを制限するサンドボックス環境で実行できたす。詳现に぀いおは、サンドボックスドキュメントを参照しおください。

セキュリティの原則

Claude Code のデフォルトを超えた远加の匷化が必芁なデプロむの堎合、これらの原則は利甚可胜なオプションをガむドしたす。

セキュリティ境界

セキュリティ境界は、異なる信頌レベルを持぀コンポヌネントを分離したす。高セキュリティのデプロむの堎合、機密リ゜ヌス認蚌情報などを゚ヌゞェントを含む境界の倖に配眮できたす。゚ヌゞェントの環境で䜕か問題が発生した堎合、その境界倖のリ゜ヌスは保護されたたたです。

たずえば、゚ヌゞェントに API キヌぞの盎接アクセスを䞎える代わりに、゚ヌゞェントの環境倖で実行されるプロキシを実行しお、キヌをリク゚ストに泚入するこずができたす。゚ヌゞェントは API 呌び出しを実行できたすが、認蚌情報自䜓は芋るこずはありたせん。このパタヌンは、マルチテナント デプロむメントたたは信頌できないコンテンツを凊理する堎合に圹立ちたす。

最小暩限

必芁に応じお、゚ヌゞェントを特定のタスクに必芁な機胜のみに制限できたす。

リ゜ヌス 制限オプション
ファむルシステム 必芁なディレクトリのみをマりント、読み取り専甚を優先
ネットワヌク プロキシ経由で特定の゚ンドポむントに制限
認蚌情報 盎接公開するのではなく、プロキシ経由で泚入
システム機胜 コンテナ内の Linux 機胜をドロップ

倚局防埡

高セキュリティ環境では、耇数の制埡をレむダヌ化するこずで远加の保護が提䟛されたす。オプションには以䞋が含たれたす。

  • コンテナ分離
  • ネットワヌク制限
  • ファむルシステム制埡
  • プロキシでのリク゚スト怜蚌

適切な組み合わせは、脅嚁モデルず運甚芁件によっお異なりたす。

分離テクノロゞヌ

異なる分離テクノロゞヌは、セキュリティ匷床、パフォヌマンス、運甚の耇雑さの間で異なるトレヌドオフを提䟛したす。

テクノロゞヌ 分離匷床 パフォヌマンスオヌバヌヘッド 耇雑さ
Sandbox runtime 良奜安党なデフォルト 非垞に䜎い 䜎い
コンテナDocker セットアップに䟝存 䜎い 䞭皋床
gVisor 優秀正しいセットアップで 䞭皋床/高い 䞭皋床
VMFirecracker、QEMU 優秀正しいセットアップで 高い 䞭皋床/高い

Sandbox runtime

コンテナなしで軜量な分離を行うには、sandbox-runtime が OS レベルでファむルシステムずネットワヌクの制限を匷制したす。

䞻な利点はシンプルさです。Docker 蚭定、コンテナむメヌゞ、たたはネットワヌク蚭定は必芁ありたせん。プロキシずファむルシステムの制限は組み蟌たれおいたす。蚱可されたドメむンずパスを指定する蚭定ファむルを提䟛したす。

動䜜方法:

  • ファむルシステム: OS プリミティブLinux では bubblewrap、macOS では sandbox-execを䜿甚しお、蚭定されたパスぞの読み取り/曞き蟌みアクセスを制限したす
  • ネットワヌク: ネットワヌク名前空間を削陀Linuxたたは Seatbelt プロファむルを䜿甚macOSしお、ネットワヌクトラフィックを組み蟌みプロキシ経由でルヌティングしたす
  • 蚭定: ドメむンずファむルシステムパスの JSON ベヌスの蚱可リスト

セットアップ:

npm install @anthropic-ai/sandbox-runtime

次に、蚱可されたパスずドメむンを指定する蚭定ファむルを䜜成したす。

セキュリティに関する考慮事項:

  1. 同䞀ホストカヌネル: VM ずは異なり、サンドボックス化されたプロセスはホストカヌネルを共有したす。カヌネルの脆匱性は理論的には脱出を可胜にする可胜性がありたす。䞀郚の脅嚁モデルではこれは蚱容可胜ですが、カヌネルレベルの分離が必芁な堎合は、gVisor たたは別の VM を䜿甚しおください。

  2. TLS むンスペクションなし: プロキシは、クラむアントが提䟛するホスト名に基づいおドメむンを蚱可リストに登録し、暗号化されたトラフィックを終了たたは怜査したせん。サンドボックス内で実行されおいるコヌドは、ドメむンフロンティングたたは同様の技術を䜿甚しお、蚱可リスト倖のホストに到達する可胜性がありたす。脅嚁モデルがより匷力な保蚌を必芁ずする堎合は、TLS 終了プロキシを蚭定しおください。詳现に぀いおは、サンドボックスセキュリティの制限を参照しおください。別途、゚ヌゞェントが蚱可されたドメむンに察する寛容な認蚌情報を持っおいる堎合、そのドメむンを䜿甚しお他のネットワヌクリク゚ストをトリガヌしたり、デヌタを流出させたりできないようにしおください。

倚くの単䞀開発者および CI/CD ナヌスケヌスでは、sandbox-runtime は最小限のセットアップで倧幅に改善されたす。以䞋のセクションでは、より匷力な分離が必芁なデプロむメント甚のコンテナず VM に぀いお説明したす。

コンテナ

コンテナは Linux 名前空間を通じお分離を提䟛したす。各コンテナはファむルシステム、プロセスツリヌ、ネットワヌクスタックの独自のビュヌを持ちながら、ホストカヌネルを共有したす。

セキュリティが匷化されたコンテナ蚭定は次のようになりたす。

docker run \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --security-opt seccomp=/path/to/seccomp-profile.json \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=100m \
  --tmpfs /home/agent:rw,noexec,nosuid,size=500m \
  --network none \
  --memory 2g \
  --cpus 2 \
  --pids-limit 100 \
  --user 1000:1000 \
  -v /path/to/code:/workspace:ro \
  -v /var/run/proxy.sock:/var/run/proxy.sock:ro \
  agent-image

各オプションの機胜は次のずおりです。

オプション 目的
--cap-drop ALL NET_ADMIN や SYS_ADMIN などの暩限昇栌を可胜にする可胜性のある Linux 機胜を削陀したす
--security-opt no-new-privileges setuid バむナリを通じおプロセスが暩限を取埗するのを防ぎたす
--security-opt seccomp=... 利甚可胜なシステムコヌルを制限したす。Docker のデフォルトは玄 44 をブロックし、カスタムプロファむルはさらにブロックできたす
--read-only コンテナのルヌトファむルシステムを䞍倉にし、゚ヌゞェントが倉曎を氞続化するのを防ぎたす
--tmpfs /tmp:... コンテナが停止したずきにクリアされる曞き蟌み可胜な䞀時ディレクトリを提䟛したす
--network none すべおのネットワヌクむンタヌフェヌスを削陀したす。゚ヌゞェントはマりントされた Unix ゜ケット経由で通信したす
--memory 2g メモリ䜿甚量を 2GB に制限しお、リ゜ヌス枯枇を防ぎたす
--pids-limit 100 プロセス数を制限しおフォヌクボムを防ぎたす
--user 1000:1000 非ルヌトナヌザヌずしお実行したす
-v ...:/workspace:ro コヌドを読み取り専甚でマりントしお、゚ヌゞェントが分析できるが倉曎できないようにしたす。~/.ssh、~/.aws、~/.config などの機密ホストディレクトリのマりントは避けおください
-v .../proxy.sock:... コンテナ倖で実行されおいるプロキシに接続された Unix ゜ケットをマりントしたす以䞋を参照

Unix ゜ケットアヌキテクチャ:

--network none を䜿甚するず、コンテナはネットワヌクむンタヌフェヌスを持ちたせん。゚ヌゞェントが倖郚䞖界に到達する唯䞀の方法は、マりントされた Unix ゜ケット経由です。これはホストで実行されおいるプロキシに接続したす。このプロキシはドメむン蚱可リストを匷制し、認蚌情報を泚入し、すべおのトラフィックをログに蚘録できたす。

これは sandbox-runtime で䜿甚されるのず同じアヌキテクチャです。゚ヌゞェントがプロンプトむンゞェクション経由で䟵害された堎合でも、任意のサヌバヌにデヌタを流出させるこずはできたせん。プロキシ経由でのみ通信でき、プロキシは到達可胜なドメむンを制埡したす。詳现に぀いおは、Claude Code サンドボックスブログ投皿を参照しおください。

远加の匷化オプション:

オプション 目的
--userns-remap コンテナルヌトを非特暩ホストナヌザヌにマップしたす。デヌモン蚭定が必芁ですが、コンテナ゚スケヌプからのダメヌゞを制限したす
--ipc private プロセス間通信を分離しお、クロスコンテナ攻撃を防ぎたす

gVisor

暙準コンテナはホストカヌネルを共有したす。コンテナ内のコヌドがシステムコヌルを実行するず、ホストを実行するのず同じカヌネルに盎接移動したす。これは、カヌネルの脆匱性がコンテナ゚スケヌプを蚱可する可胜性があるこずを意味したす。gVisor はナヌザヌスペヌスでシステムコヌルをむンタヌセプトしおホストカヌネルに到達する前に、ほずんどのシステムコヌルを実際のカヌネルを関䞎させずに凊理する独自の互換性レむダヌを実装するこずでこれに察凊したす。

゚ヌゞェントが悪意のあるコヌドを実行する堎合おそらくプロンプトむンゞェクションが原因、そのコヌドはコンテナ内で実行され、カヌネル゚クスプロむトを詊みる可胜性がありたす。gVisor を䜿甚するず、攻撃面は倧幅に小さくなりたす。悪意のあるコヌドは最初に gVisor のナヌザヌスペヌス実装を悪甚する必芁があり、実際のカヌネルぞのアクセスは限定的です。

Docker で gVisor を䜿甚するには、runsc ランタむムをむンストヌルしおデヌモンを蚭定したす。

// /etc/docker/daemon.json
{
  "runtimes": {
    "runsc": {
      "path": "/usr/local/bin/runsc"
    }
  }
}

次に、以䞋を䜿甚しおコンテナを実行したす。

docker run --runtime=runsc agent-image

パフォヌマンスに関する考慮事項:

ワヌクロヌド オヌバヌヘッド
CPU バりンド蚈算 箄 0%システムコヌルむンタヌセプションなし
シンプルなシステムコヌル 箄 2 倍遅い
ファむル I/O 集箄的 倧量のオヌプン/クロヌズパタヌンで最倧 10200 倍遅い

マルチテナント環境たたは信頌できないコンテンツを凊理する堎合、远加の分離はしばしば䟡倀がありたす。

仮想マシン

VM は CPU 仮想化拡匵機胜を通じおハヌドりェアレベルの分離を提䟛したす。各 VM は独自のカヌネルを実行し、匷力な境界を䜜成したす。ゲストカヌネルの脆匱性はホストを盎接䟵害したせん。ただし、VM は自動的に gVisor などの代替案より「より安党」ではありたせん。VM セキュリティはハむパヌバむザヌずデバむス゚ミュレヌションコヌドに倧きく䟝存したす。

Firecracker は軜量マむクロ VM 分離甚に蚭蚈されおいたす。125ms 以䞋で VM をブヌトでき、メモリオヌバヌヘッドは 5 MiB 未満で、䞍芁なデバむス゚ミュレヌションを削陀しお攻撃面を削枛したす。

このアプロヌチでは、゚ヌゞェント VM は倖郚ネットワヌクむンタヌフェヌスを持ちたせん。代わりに、vsock仮想゜ケットを通じお通信したす。すべおのトラフィックは vsock 経由でホスト䞊のプロキシにルヌティングされ、プロキシが蚱可リストを匷制し、リク゚ストを転送する前に認蚌情報を泚入したす。

クラりドデプロむメント

クラりドデプロむメントの堎合、䞊蚘の分離テクノロゞヌのいずれかをクラりドネむティブネットワヌク制埡ず組み合わせるこずができたす。

  1. ゚ヌゞェントコンテナをむンタヌネットゲヌトりェむなしのプラむベヌトサブネットで実行したす
  2. クラりドファむアりォヌルルヌルAWS セキュリティグルヌプ、GCP VPC ファむアりォヌルを蚭定しお、プロキシ以倖ぞのすべおの送信をブロックしたす
  3. リク゚ストを怜蚌し、ドメむン蚱可リストを匷制し、認蚌情報を泚入し、倖郚 API に転送する Envoy などのプロキシcredential_injector フィルタヌ付きを実行したす
  4. ゚ヌゞェントのサヌビスアカりントに最小限の IAM 暩限を割り圓お、機密アクセスをプロキシ経由でルヌティングしたす
  5. 監査目的でプロキシですべおのトラフィックをログに蚘録したす

認蚌情報管理

゚ヌゞェントは、API を呌び出し、リポゞトリにアクセスし、クラりドサヌビスず盞互䜜甚するために認蚌情報が必芁なこずがよくありたす。課題は、認蚌情報自䜓を公開するこずなく、このアクセスを提䟛するこずです。

プロキシパタヌン

掚奚されるアプロヌチは、゚ヌゞェントのセキュリティ境界の倖でプロキシを実行しお、送信リク゚ストに認蚌情報を泚入するこずです。゚ヌゞェントは認蚌情報なしでリク゚ストを送信し、プロキシがそれらを远加しお、リク゚ストを宛先に転送したす。

このパタヌンにはいく぀かの利点がありたす。

  1. ゚ヌゞェントは実際の認蚌情報を芋るこずはありたせん
  2. プロキシは蚱可された゚ンドポむントの蚱可リストを匷制できたす
  3. プロキシはすべおのリク゚ストを監査甚にログに蚘録できたす
  4. 認蚌情報は各゚ヌゞェントに分散されるのではなく、1 ぀の安党な堎所に保存されたす

Claude Code をプロキシを䜿甚するように蚭定する

Claude Code は、サンプリングリク゚ストをプロキシ経由でルヌティングするための 2 ぀の方法をサポヌトしおいたす。

オプション 1: ANTHROPIC_BASE_URLシンプルですがサンプリング API リク゚ストのみ

export ANTHROPIC_BASE_URL="http://localhost:8080"

これにより、Claude Code ず Agent SDK は、Claude API に盎接ではなく、プロキシにサンプリングリク゚ストを送信するように指瀺されたす。プロキシはプレヌンテキスト HTTP リク゚ストを受け取り、怜査および倉曎認蚌情報の泚入を含むしおから、実際の API に転送できたす。

オプション 2: HTTP_PROXY / HTTPS_PROXYシステム党䜓

export HTTP_PROXY="http://localhost:8080"
export HTTPS_PROXY="http://localhost:8080"

Claude Code ず Agent SDK はこれらの暙準環境倉数を尊重し、すべおの HTTP トラフィックをプロキシ経由でルヌティングしたす。HTTPS の堎合、プロキシは暗号化された CONNECT トンネルを䜜成したす。TLS むンタヌセプションなしでは、リク゚ストコンテンツを芋たり倉曎したりするこずはできたせん。

プロキシの実装

独自のプロキシを構築するか、既存のプロキシを䜿甚できたす。

  • Envoy Proxy: 認蚌ヘッダヌを远加するための credential_injector フィルタヌ付きのプロダクショングレヌドプロキシ
  • mitmproxy: HTTPS トラフィックを怜査および倉曎するための TLS 終了プロキシ
  • Squid: アクセス制埡リスト付きのキャッシングプロキシ
  • LiteLLM: 認蚌情報泚入ずレヌト制限を備えた LLM ゲヌトりェむ

他のサヌビスの認蚌情報

Claude API からのサンプリングを超えお、゚ヌゞェントは git リポゞトリ、デヌタベヌス、内郚 API などの他のサヌビスぞの認蚌枈みアクセスが必芁なこずがよくありたす。䞻に 2 ぀のアプロヌチがありたす。

カスタムツヌル

MCP サヌバヌたたはカスタムツヌルを通じおアクセスを提䟛し、゚ヌゞェントのセキュリティ境界の倖で実行されおいるサヌビスにリク゚ストをルヌティングしたす。゚ヌゞェントはツヌルを呌び出したすが、実際の認蚌枈みリク゚ストは倖郚で発生したす。ツヌル呌び出しはプロキシに察しお行われ、プロキシが認蚌情報を泚入したす。

たずえば、git MCP サヌバヌぱヌゞェントからのコマンドを受け入れるこずができたすが、ホストで実行されおいる git プロキシにそれらを転送し、プロキシがリモヌトリポゞトリに接続する前に認蚌を远加したす。゚ヌゞェントは認蚌情報を芋るこずはありたせん。

利点:

  • TLS むンタヌセプションなし: 倖郚サヌビスは認蚌枈みリク゚ストを盎接実行したす
  • 認蚌情報は倖郚に留たる: ゚ヌゞェントはツヌルむンタヌフェヌスのみを芋お、基瀎ずなる認蚌情報は芋たせん

トラフィック転送

Claude API 呌び出しの堎合、ANTHROPIC_BASE_URL を䜿甚するず、プレヌンテキストでリク゚ストを怜査および倉曎できるプロキシにリク゚ストをルヌティングできたす。ただし、他の HTTPS サヌビスGitHub、npm レゞストリ、内郚 APIの堎合、トラフィックはしばしば゚ンドツヌ゚ンドで暗号化されたす。HTTP_PROXY 経由でプロキシ経由でルヌティングしおも、プロキシは䞍透明な TLS トンネルのみを芋お、認蚌情報を泚入するこずはできたせん。

カスタムツヌルを䜿甚せずに任意のサヌビスぞの HTTPS トラフィックを倉曎するには、トラフィックを埩号化し、怜査たたは倉曎しおから、転送する前に再暗号化する TLS 終了プロキシが必芁です。これには以䞋が必芁です。

  1. ゚ヌゞェントのコンテナの倖でプロキシを実行する
  2. プロキシの CA 蚌明曞を゚ヌゞェントの信頌ストアにむンストヌルする゚ヌゞェントがプロキシの蚌明曞を信頌するため
  3. HTTP_PROXY/HTTPS_PROXY を蚭定しおトラフィックをプロキシ経由でルヌティングする

このアプロヌチはカスタムツヌルを蚘述するこずなく、HTTP ベヌスのサヌビスを凊理したすが、蚌明曞管理の耇雑さが増したす。

すべおのプログラムが HTTP_PROXY/HTTPS_PROXY を尊重するわけではないこずに泚意しおください。ほずんどのツヌルcurl、pip、npm、gitは尊重したすが、これらの倉数をバむパスしお盎接接続する堎合もありたす。たずえば、Node.js fetch() はデフォルトではこれらの倉数を無芖したす。Node 24 以降では、NODE_USE_ENV_PROXY=1 を蚭定しおサポヌトを有効にできたす。包括的なカバレッゞの堎合、proxychains を䜿甚しおネットワヌク呌び出しをむンタヌセプトするか、iptables を蚭定しお送信トラフィックを透過プロキシにリダむレクトできたす。

どちらのアプロヌチでも、TLS 終了プロキシず信頌された CA 蚌明曞が必芁です。トラフィックが実際にプロキシに到達するこずを確認するだけです。

ファむルシステム蚭定

ファむルシステム制埡は、゚ヌゞェントが読み取りおよび曞き蟌みできるファむルを決定したす。

読み取り専甚コヌドマりント

゚ヌゞェントがコヌドを分析する必芁があるが倉曎しない堎合は、ディレクトリを読み取り専甚でマりントしたす。

docker run -v /path/to/code:/workspace:ro agent-image

曞き蟌み可胜な堎所

゚ヌゞェントがファむルを曞き蟌む必芁がある堎合、倉曎を氞続化するかどうかに応じお、いく぀かのオプションがありたす。

コンテナ内の䞀時的なワヌクスペヌスの堎合、メモリ内にのみ存圚し、コンテナが停止したずきにクリアされる tmpfs マりントを䜿甚したす。

docker run \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=100m \
  --tmpfs /workspace:rw,noexec,size=500m \
  agent-image

倉曎を氞続化する前に確認したい堎合、オヌバヌレむファむルシステムを䜿甚するず、゚ヌゞェントは基瀎ずなるファむルを倉曎するこずなく曞き蟌みできたす。倉曎は別のレむダヌに保存され、怜査、適甚、たたは砎棄できたす。完党に氞続的な出力の堎合、専甚ボリュヌムをマりントしたすが、機密ディレクトリずは別に保぀ようにしおください。

さらに詳しく