Docker daemon attack surfaceを読んだ
Dockerの公式ドキュメントにセキュリティ関連のページがある．
docs.docker.com
Dockerの仕様と，それに起因するセキュリティ上の注意事項がまとめてある感じ．
今回はそのなかのひとつ"Docker daemon attack surface"を読んでわかったことをまとめてみる．
（これから勉強しようという人が書いているので，かなり初歩的だし，ミスリードがあるかもしれない．間違ってたらごめんなさい．）
ここに書いてあることが常に正しいかどうかはわからない．
設定や使用環境によっては気にしないでよいこともあるかもしれない．
それでも基本的な考え方として知っておくことは無駄ではなさそう．
ポイント
とにもかくにも，信頼されたユーザだけがDocker daemonを操作できるようにすること．
Docker daemonとはDockerの機能を実現するdaemonのことで，dockerコマンドの宛先といったところ.
操作コマンドの使用を制限するのは当たり前のことにも思えるが，なぜ大事なのか．
もう少し詳しく
Dockerコンテナはホストとディレクトリを制限なく共有する仕様となっている．
設定次第では，コンテナからホスト側のファイルシステムにアクセスすることも可能となりうる．
例えば外部から任意のコンテナを構築可能なサーバを立ててしまうと，悪意のあるユーザにコンテナの外のホストごとやられ放題となってしまう．
第三者によってC2サーバに使われてしまったり，ボットネットに組み込まれてしまうかもしれない．
そのようなリスクを踏まえ，Docker CLIのREST APIはバージョン0.5.2以降はUNIXソケットを使う仕様になっている．
Docker Engine release notes | Docker Documentation
0.5.2 (2013-08-08)
Builder: Forbid certain paths within docker build ADD
Runtime: Change network range to avoid conflict with EC2 DNS
API: Change daemon to listen on unix socket by default
それまでのTCPソケットによる待ち受けに比べ，従来のUNIX権限チェックを適用することでサーバを守れるため，リスクを減らせるという判断だ．
現在でも設定変更によってREST APIをHTTP経由で叩くことも可能だが，その場合はVPNを張ったり，HTTPSを使うなどでAPI向けの通信を保護したほうがよい．
これ以外にもDockerデーモンは，docker loadやdocker pullなどのイメージ読み込みに対しても脆弱である．
開発者が知らないうちに悪性なイメージを使っていて，それをリリースしてしまう，ということがあるかもしれない．
これに対してはまずバージョン1.3.2でサンドボックス上に展開するような仕様に変更され，さらに1.10.0（下記リンク）からはdocker imageをチェックサムで管理するようにすることで，正規のイメージを保護している．
blog.docker.com
使用しているイメージが意図したものであるかどうかは，IDを見ればよい．
最後に，Dockerを公開する場合は他のサービスと混在させないようにしつつ，必要なサービスはすべてコンテナでまかなうとよい．
（もちろんsshやログ保存系などの管理ツールは入れてもいい，と書いてある．）
