コンテナのランタイムセキュリティ

ランタイムコンテナセキュリティへようこそ。安全なイメージを構築することは重要ですが、コンテナが実行中になった後はどうすればよいのでしょうか。

このレッスンでは、アプリケーションが実行中である間に保護するためのベストプラクティスを学び、脆弱性や攻撃による被害を抑える方法を扱います。

基本的なセキュリティ概念に最小権限の原則があります。これは、エンティティ（コンテナやユーザーなど）に対して、その機能を実行するために絶対に必要な権限だけを付与し、それ以上の権限は与えないという考え方です。

これを適用すると攻撃対象領域が縮小し、コンテナが侵害された場合の影響を抑えられます。

デフォルトでは、Dockerコンテナ内のプロセスは、コンテナ内で完全な管理者権限を持つ root ユーザーとして実行されます。

• リスク: 攻撃者がroot権限を持つコンテナを制御すると、Dockerデーモンやカーネルの脆弱性を悪用して、ホストシステム上のroot権限を取得できる可能性があります。
• ベストプラクティス: コンテナ内のプロセスは必ずroot以外のユーザーとして実行してください。

docker run の --user フラグを使うと、コンテナ内のプロセスに使用するユーザーを名前またはUIDで指定できます。ここでは、Alpineコンテナ内で id コマンドをユーザー 1000 として実行します。

ユーザー 1000 が存在しない場合でも、DockerはそのUIDを使用します。

従来のLinuxシステムでは、rootユーザーの権限は「すべてか、何もないか」のどちらかでした。Linux capabilitiesは、強力なroot権限を、より小さく独立した単位に分割します。

これにより、プロセスは完全なroot権限を持たなくても、必要な特定のroot相当の権限（低いポートへのバインドやrawネットワークアクセスなど）だけを持てるようになります。

Dockerコンテナは、デフォルトで多数のcapabilitiesを持って実行されます。--cap-drop を使って不要なcapabilitiesを削除し、コンテナで実行できる操作をさらに制限できます。

ここでは NET_RAW capabilityを削除します。NET_RAW を必要とする ping コマンドは失敗するため、制限の効果を確認できます。

コンテナはホストのカーネルとリソースを共有します。あるコンテナがリソースを制限なく使用すると、他のコンテナやホスト自体でサービス拒否（DoS）が発生する可能性があります。

• CPU制限: コンテナがCPUサイクルを独占するのを防ぎます。
• メモリ制限: コンテナが使用可能なRAMをすべて消費するのを防ぎ、システムの不安定化を抑えます。

docker run を使うと、CPUとメモリに直接制限を設定できます。この例では、メモリを128MB、CPU使用率を0.5（CPUコア1個の半分）に制限しています。

これにより、コンテナが適切に動作し、他のプロセスのリソースを奪わないようにできます。

多くのアプリケーションでは、起動後にルートファイルシステムへ書き込む必要はありません。ファイルシステムを読み取り専用にすると、次のような大きなセキュリティ上のメリットがあります。

• 改ざんを防止する: 攻撃者は既存のファイルを変更したり、新たな悪意のあるファイルを書き込んだりできません。
• 永続化を制限する: 行われた変更は一時的なもので、コンテナの再起動時に失われます。
• 不変性を適用する: コンテナを使い捨てにし、設定を外部で管理する設計を促進します。

コンテナの実行時に --read-only フラグを使用してください。明示的にマウントしたボリューム以外のコンテナファイルシステムに書き込もうとすると、失敗します。

この読み取り専用コンテナ内でファイルを作成してみてください。

ランタイムでコンテナを保護するための適切なプラクティスは、次のうちどれでしょうか。

よくできました。実行中のコンテナのセキュリティを強化する方法を学びました。

• 最小権限: 必要な権限だけを付与します。
• root以外のユーザー: root としてプロセスを実行しないようにします。
• Capabilities: 不要なLinux capabilitiesを削除します。
• リソース制限: CPUとメモリの使用量を制御します。
• 読み取り専用: ファイルシステムを不変にして、書き込みを防ぎます。

これらのプラクティスにより、攻撃対象領域と、侵害された場合の影響を大幅に縮小できます。引き続き練習してください。