Docker Meetup Tokyo #34
(20200905_修正) p14「(参考) ありそうな質問と回答」の回答内容を一部修正
fujiihda2020/1/16Docker Meetup Tokyo #34 (年明けLT大会)OSの機能から考えるコンテナセキュリティ
View Slide
22@fujiihda掲載内容は個人の見解であり、所属する企業やコミュニティの立場、戦略、意見を代表するものではありません
3@fujiihda
44@fujiihda今日は赤の箇所にフォーカスWhois• 藤井 秀行 (ふじい ひでゆき)– 役割:Infrastructure Engineer /技術系コミュニティ運営等– 仕事:技術調査、製品開発、SRE– 経歴:監視、OS (Linux)、コンテナ– 趣味:セキュリティ技術fujiihda
55@fujiihda# docker container run --cap-add=ALL (以下略)(または --privileged) (以下略)# docker container run --security-opt="seccomp=unconfined"(以下略)# vim /etc/selinux/configSELINUX=disabled(以下略)今日伝えたいこと - よく聞く話Linuxケーパビリティ無効seccomp無効SELinux無効
66@fujiihda# docker container run --cap-add=ALL(または --privileged)(以下略)# docker container run --security-opt="seccomp=unconfined"(以下略)# vim /etc/selinux/configSELINUX=disabled(以下略)Linuxケーパビリティ無効seccomp無効SELinux無効今日伝えたいこと - とりあえず無効ヨクナイ!!
77@fujiihdaコンテナ特有のセキュリティリスクと対策• 米国国立標準技術研究所 (NIST) が“Application Container SecurityGuide” (NIST SP 800-190) という文書で、コンテナ特有のリスクと対策を次の 5 つに分類– イメージリスク:3.1 節– レジストリリスク:3.2 節– オーケストレータリスク:3.3 節– コンテナリスク:3.4 節– ホスト OS リスク:3.5 節参照元:https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf今日は赤の箇所にフォーカス
88@fujiihda(参考) コンテナリスクの内訳• 狭義の意味でのコンテナに関連する次の 5 つ– コンテナランタイムの脆弱性– コンテナからの無制限なネットワークアクセス– コンテナランタイムの脆弱な設定– コンテナ上で動作するアプリケーションの脆弱性– (計画されていない) 不正なコンテナ
99@fujiihda(参考) ホスト OS リスクの内訳• コンテナを動作させるホスト OS に関連する次の 5 つ– ホスト OS 自体に存在する脆弱性– カーネルを共有することに起因するアイソレーションレベルの低さ– ホスト OS のコンポーネントの脆弱性– 不適切なユーザアクセス権限– ホスト OS のファイルシステムの改ざん
1010@fujiihdaコンテナリスクとホスト OS リスクへの対処 (1/2)• 基本対処– ホスト は常に最新にして、なるべく脆弱性のないようにする– コンテナ は最小構成にして、ユーザ権限 / 通信先 / ファイルシステムへのアクセスも必要最低限にする– アプリケーション に脆弱性を作りこまないための努力をする– 環境 は 本番、試験、検証 などの用途に応じて分割して、信用できない状況ではマルチテナントを避け、ログをはじめとする監査に役立つ情報はしっかりと残すあれ?当たり前かも?(コンテナリスクとホスト OSリスクに限定しているため)
1111@fujiihdaコンテナリスクとホスト OS リスクへの対処 (2/2)• 基本対処 + α (思い付いたものだけなのでもっとあるはず)– OS のセキュリティ機能を有効活用• seccomp / Linux ケーパビリティ など– 攻撃時のふるまい検知• Sysdig など– コンテナと親和性の高そうな仕組みの活用• DevSecOps / 静的コード解析 など(個人的には バイナリ解析 / API のファジング)今日は赤の箇所にフォーカス
1212@fujiihdaコンテナ で使える OS のセキュリティ機能の一部• seccomp (今日紹介するのは mode 2 seccomp filter モード)– プロセスが利用できるシステムコールを制限できる– Docker では、コンテナ内のプロセスが実行するシステムコールを制限できる– 定義したシステムコールが呼ばれたときの制御を、許可、拒否、終了などのアクションから選択でき、種類だけでなく、引数との組み合わせも定義可能– 任意のコマンドが実行されたとしても、影響範囲を最小限に抑えることが可能• Linux ケーパビリティ– root 権限を目的別に約 30 個に分割した特権機能群– 必要に応じて付与 / 剥奪今日は赤の箇所にフォーカス
1313@fujiihdaseccomp の使い方のイメージ (簡易版)# vim profile.json{"defaultAction": "SCMP_ACT_ALLOW","syscalls":[{ "name": "chmod", "action": "SCMP_ACT_ERRNO" },{ "name": "fchmodat", "action": "SCMP_ACT_ERRNO" }]}# docker container run --security-opt seccomp=profile.json (以下略)(実行結果省略)アクションの対象のシステムコール名を定義アクションを定義デフォルトアクションを定義
1414@fujiihda(参考) ありそうな質問と回答• Q1:いずれか 1 つでも使えば、攻撃を止められるのでは?• A1:そういうこともあるが、どれか 1 つという考え方ではなく、重ね掛けして多層防御するという考え方をしてほしい。これらの機能は有効化することで、攻撃可能な面を減らすことができる。なお、Dirty CoW をはじめとする Linuxカーネル脆弱性やハードウェア脆弱性など、これらで止めることができない脆弱性も存在する。根本対処であるホストを最新に保つことも忘れないでほしい。• Q2:ベストプラクティスはどれですか?• A2:重ね掛けを基本としてほしいが、使い分けという意味であれば、Linux ケーパビリティと seccomp は目的が違う。Linux ケーパビリティは目的別で指定できる反面、粒度が荒すぎる。一方、seccomp は細かい設定ができるが適切に設定するのは大変で、粒度が細かすぎる。それぞれを必要最低限とすることが好ましいが、無効化してしまうくらいなら、デフォルト設定を試してほしい。なお、Linux ケーパビリティのデフォルトはやや過剰なので、デフォルトから剥奪も検討してほしい。
1515@fujiihdaまとめ• コンテナ特有のセキュリティリスクと対策はNIST SP 800-190 で整理されている• コンテナリスクとホスト OS リスクに限定すれば、セキュリティの基本的な考え方の多くはコンテナでも通用する (ただし、それ以外も含めたときは考慮するべきことが増える)• OS のセキュリティ機能をコンテナで使うときは– 基本的な考え方は多層防御– 求められる要件や粒度に応じて重ね掛けしつつ使い分ける– 無効化よりデフォルト設定