コンテナのホストマシンでは、最新の安定版のOSとパッチを稼働させるとよい。仮想マシン（VM）と違って、Docker環境では各コンテナがホストOSのリソースとファイルを共有する。これはセキュリティ問題がDocker環境全体に波及する可能性があることを意味する。企業のITチームにとってOSの管理は難しくない。だが、慎重なアプローチが必要だ。Dockerをホストするシステムの更新に取り組む前に、全てのドキュメントを確認すべきだ。このプロセスに役立つのが仮想スナップショットで、変更ログとロールバックが利用できる。

　アプリケーションのセキュリティは、階層構造においてその下位に位置するコンポーネントのセキュリティに左右される。従って、下位に位置するホストのセキュリティ設定を調べるとよい。デフォルト構成の場合、OSに対して管理者レベルのアクセス権を有するユーザーがコンテナを操作できる。管理者は、その環境のセキュリティレベルを高めるため、リモートログイン時に暗号鍵を使用すべきだ。ファイアウォールを導入し、アクセスを信頼できるネットワークのみに制限することも大切だ。攻撃を受ける領域は最小限に抑えよう。

　監査は、セキュリティと密接な関係がある。情報が必要な状況に至るまでシステムの監査を引き延ばしてはいけない。情報は記録されていなければ利用できない。強力なログ監視と管理のプロセスを採用すべきだ。そのプロセスを専用のログストレージホストで実行させ、制限付きのアクセスを設定するとよい。

　同様に、DockerのホストシステムではDockerコンテナのみを実行すべきだ。ホストが実行するサービスはできるだけ少なくする。Docker以外のサービスは、必要に応じてコンテナに変換して抽象化させ、ホストOSや他のコンテナと分離する。

セキュアなDocker環境の作成

　管理者は、単純な手順でコンテナの操作を安定させられる。Dockerコンテナを配置する/var/lib/dockerディレクトリを、パーティション分割した状態にするとよい。パーティションを分けておけば、Docker環境内でストレージ領域に問題が生じても、OSはクラッシュしない。そのホストにある全てのコンテナを取り出せる。論理ボリューム管理を使用すれば、ストレージの割り当てが容易になる。ストレージのパーティション分割を仮想化し、リソースを複数のワークロード間で効率的に共有できる。

　セキュアなDocker設定は、イメージのセキュリティにも左右される。この場合のイメージとは、コンテナの実行に必要なコード、依存関係、ライブラリの静的パッケージを指す。全てのDockerイメージが十分な信頼性を持つわけではない。Dockerイメージを自社で構築し、そのイメージに含まるべきものが何なのか開発者とユーザーが分かるようにすることが大切だ。これにより、セキュリティの懸念（や被害妄想）が緩和される。

　イメージのカスタムが自社の得意分野ではない場合や、その必要がない場合は、公式ビルドのみを使用するとよい。例えば、公式リポジトリから「Ubuntu Docker」イメージをダウンロードできる。非公式ビルドが不適切とは限らない。だが、ユーザーの想定や必要な信頼性を満たさない可能性がある。サードパーティー製のイメージには、意図的に不正を働くものや悪意を含むものもある。

　Dockerイメージの信頼要件を利用して、誤ったコンテナイメージや悪意のあるコンテナイメージの侵入を回避することが可能だ。信頼できるイメージは、Dockerの公式リポジトリなど、検証済みソースから取得できる。こうしたイメージは、環境をきめ細かく制御するために構築されている。信頼性チェックの有効範囲をグローバルにし、危険性を含む可能性のあるイメージが混入するのを防ぐとよい。

　基本的なDockerセキュリティの多くの側面は、結局はPCの適切なウイルス予防策であり、常識的なセキュリティ対策でもある。つまり、仮想的な出入り口を強化し、最低限のサービスとアプリケーションのみを実行し、アクセス権が必要なユーザーにのみホストへのアクセスを限定する。ダウンロードするものに対しても常に注意を払う必要がある。