Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

fujiihda
January 16, 2020

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

Docker Meetup Tokyo #34

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

fujiihda

January 16, 2020
Tweet

More Decks by fujiihda

Other Decks in Technology

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