OSの機能から考えるコンテナセキュリティ / Considering Container Security

Docker Meetup Tokyo #34

(20200905_修正)
p14「(参考) ありそうな質問と回答」の回答内容を一部修正

Transcript

1. fujiihda
   2020/1/16
   Docker Meetup Tokyo #34 (年明けLT大会)
   OSの機能から考える
   コンテナセキュリティ
   

   View Slide

2. 2
   2
   @fujiihda
   掲載内容は個人の見解であり、
   所属する企業やコミュニティの立場、
   戦略、意見を代表するものではありません
   

   View Slide

3. 3
   @fujiihda
   

   View Slide

4. 4
   4
   @fujiihda
   今日は赤の箇所
   にフォーカス
   Whois
   • 藤井 秀行 (ふじい ひでゆき)
   – 役割：Infrastructure Engineer /
   技術系コミュニティ運営等
   – 仕事：技術調査、製品開発、SRE
   – 経歴：監視、OS (Linux)、コンテナ
   – 趣味：セキュリティ技術
   fujiihda
   

   View Slide

5. 5
   5
   @fujiihda
   # docker container run --cap-add=ALL (以下略)
   (または --privileged) (以下略)
   # docker container run --security-opt="seccomp=unconfined"
   (以下略)
   # vim /etc/selinux/config
   SELINUX=disabled
   (以下略)
   今日伝えたいこと - よく聞く話
   Linuxケー
   パビリティ
   無効
   seccomp
   無効
   SELinux
   無効
   

   View Slide

6. 6
   6
   @fujiihda
   # docker container run --cap-add=ALL
   (または --privileged)
   (以下略)
   # docker container run --security-opt="seccomp=unconfined"
   (以下略)
   # vim /etc/selinux/config
   SELINUX=disabled
   (以下略)
   Linuxケー
   パビリティ
   無効
   seccomp
   無効
   SELinux
   無効
   今日伝えたいこと - とりあえず無効ヨクナイ！！
   

   View Slide

7. 7
   7
   @fujiihda
   コンテナ特有のセキュリティリスクと対策
   • 米国国立標準技術研究所 (NIST) が
   “Application Container Security
   Guide” (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
   今日は赤の箇所
   にフォーカス
   

   View Slide

8. 8
   8
   @fujiihda
   (参考) コンテナリスクの内訳
   • 狭義の意味でのコンテナに関連する次の 5 つ
   – コンテナランタイムの脆弱性
   – コンテナからの無制限なネットワークアクセス
   – コンテナランタイムの脆弱な設定
   – コンテナ上で動作するアプリケーションの脆弱性
   – (計画されていない) 不正なコンテナ
   

   View Slide

9. 9
   9
   @fujiihda
   (参考) ホスト OS リスクの内訳
   • コンテナを動作させるホスト OS に関連する次の 5 つ
   – ホスト OS 自体に存在する脆弱性
   – カーネルを共有することに起因するアイソレーションレベルの低さ
   – ホスト OS のコンポーネントの脆弱性
   – 不適切なユーザアクセス権限
   – ホスト OS のファイルシステムの改ざん
   

   View Slide

10. 10
    10
    @fujiihda
    コンテナリスクとホスト OS リスクへの対処 (1/2)
    • 基本対処
    – ホスト は常に最新にして、なるべく脆弱性のないようにする
    – コンテナ は最小構成にして、ユーザ権限 / 通信先 / ファイル
    システムへのアクセスも必要最低限にする
    – アプリケーション に脆弱性を作りこまないための努力をする
    – 環境 は 本番、試験、検証 などの用途に応じて分割して、
    信用できない状況ではマルチテナントを避け、
    ログをはじめとする監査に役立つ情報はしっかりと残す
    あれ？当たり前かも？
    (コンテナリスクとホスト OS
    リスクに限定しているため)
    

    View Slide

11. 11
    11
    @fujiihda
    コンテナリスクとホスト OS リスクへの対処 (2/2)
    • 基本対処 + α (思い付いたものだけなのでもっとあるはず)
    – OS のセキュリティ機能を有効活用
    • seccomp / Linux ケーパビリティ など
    – 攻撃時のふるまい検知
    • Sysdig など
    – コンテナと親和性の高そうな仕組みの活用
    • DevSecOps / 静的コード解析 など
    (個人的には バイナリ解析 / API のファジング)
    今日は赤の箇所
    にフォーカス
    

    View Slide

12. 12
    12
    @fujiihda
    コンテナ で使える OS のセキュリティ機能の一部
    • seccomp (今日紹介するのは mode 2 seccomp filter モード)
    – プロセスが利用できるシステムコールを制限できる
    – Docker では、コンテナ内のプロセスが実行するシステムコールを
    制限できる
    – 定義したシステムコールが呼ばれたときの制御を、許可、拒否、
    終了などのアクションから選択でき、種類だけでなく、引数との
    組み合わせも定義可能
    – 任意のコマンドが実行されたとしても、影響範囲を最小限に抑える
    ことが可能
    • Linux ケーパビリティ
    – root 権限を目的別に約 30 個に分割した特権機能群
    – 必要に応じて付与 / 剥奪
    今日は赤の箇所
    にフォーカス
    

    View Slide

13. 13
    13
    @fujiihda
    seccomp の使い方のイメージ (簡易版)
    # 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 (以下略)
    (実行結果省略)
    アクションの対象の
    システムコール名を定義
    アクションを定義
    デフォルトアクション
    を定義
    

    View Slide

14. 14
    14
    @fujiihda
    (参考) ありそうな質問と回答
    • Q1：いずれか 1 つでも使えば、攻撃を止められるのでは？
    • A1：そういうこともあるが、どれか 1 つという考え方ではなく、重ね掛けして
    多層防御するという考え方をしてほしい。これらの機能は有効化することで、攻
    撃可能な面を減らすことができる。なお、Dirty CoW をはじめとする Linux
    カーネル脆弱性やハードウェア脆弱性など、これらで止めることができない脆弱
    性も存在する。根本対処であるホストを最新に保つことも忘れないでほしい。
    • Q2：ベストプラクティスはどれですか？
    • A2：重ね掛けを基本としてほしいが、使い分けという意味であれば、Linux ケー
    パビリティと seccomp は目的が違う。Linux ケーパビリティは目的別で指定で
    きる反面、粒度が荒すぎる。一方、seccomp は細かい設定ができるが適切に設
    定するのは大変で、粒度が細かすぎる。それぞれを必要最低限とすることが好ま
    しいが、無効化してしまうくらいなら、デフォルト設定を試してほしい。なお、
    Linux ケーパビリティのデフォルトはやや過剰なので、デフォルトから剥奪も検
    討してほしい。
    

    View Slide

15. 15
    15
    @fujiihda
    まとめ
    • コンテナ特有のセキュリティリスクと対策は
    NIST SP 800-190 で整理されている
    • コンテナリスクとホスト OS リスクに限定すれば、
    セキュリティの基本的な考え方の多くはコンテナでも
    通用する (ただし、それ以外も含めたときは考慮する
    べきことが増える)
    • OS のセキュリティ機能をコンテナで使うときは
    – 基本的な考え方は多層防御
    – 求められる要件や粒度に応じて重ね掛けしつつ使い分ける
    – 無効化よりデフォルト設定
    

    View Slide