D07 - リソース保護
脅威シナリオ
ホスト OS によっては CPU 、メモリ、ネットワーク、ディスク I/O に関してコンテナに制限がありません。脅威となるのは、ソフトウェアの障害または攻撃者による意図的なもののいずれか原因でこれらのリソースの一つが不足し、基盤となるホストおよび他のすべてのコンテナの物理リソースに影響を与えることです。
また、docker などにより課せられるデフォルトのセキュリティ対策がコンテナに含まれていても、他のコンテナやホストと物理リソース、つまり主に CPU とメモリを共有します。したがって、他のコンテナがこれらのリソースを大量に使用すると、自分のコンテナにはあまりリソースが残りません。
ネットワークも共有媒体であり、データを読み書きする際にはほとんどの場合、同じリソースを使用しています。
メモリについてはホストの Linux カーネルにいわゆる OOM [1] キラーがあることを理解することが重要です。カーネルのメモリが不足すると OOM キラーが発動します。それからいくつかのアルゴリズム [2] を使用してメモリの "解放" を開始し、ホストとカーネル自体が存続できるようにします。強制終了されるプロセスは必ずしも大量のメモリ消費が原因とは限らず (OOM スコアは [3] を参照) 、ホストの RAM が必要超過することがよくあります [3] 。
どうすれば防ぐことができるのか?
最善はまずコンテナに対してメモリと CPU に適度な上限を設けることです。これらの上限に達すると、コンテナはそれ以上のメモリを割り当てたり、CPU を消費したりできなくなります。
メモリにはハードリミットを設定するための主な変数として -memory
と --memory-swap
の二つがあります。ソフトリミットは指定された値を超える可能性があります。これは --memory-reservation
で設定します。より詳細な説明については docker ドキュメント [4] を参照してください。コンテナ内のプロセスを保護するために --oom-kill-disable
を設定することもできます。コンテナデーモンは OOM スコアが低く、通常は強制終了されません。
どうすれば見つけ出せるのか?
構成:
docker inspect
ライブ:
docker stats
, 構成内容を含むメモリの詳細:
/sys/fs/cgroup/memory/docker/$CONTAINERID/*
参考情報
[1] OOM は Out of Memory Management の略です
[2] https://www.kernel.org/doc/gorman/html/understand/understand016.html
[3] https://lwn.net/Articles/317814/
[4] https://docs.docker.com/config/containers/resource_constraints/
Last updated