Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
OSの機能から考えるコンテナセキュリティ / Considering Container Security
Search
fujiihda
January 16, 2020
Technology
8
2.7k
OSの機能から考えるコンテナセキュリティ / Considering Container Security
Docker Meetup Tokyo #34
(20200905_修正)
p14「(参考) ありそうな質問と回答」の回答内容を一部修正
fujiihda
January 16, 2020
Tweet
Share
More Decks by fujiihda
See All by fujiihda
攻撃しながら考えるKubernetesセキュリティ / Considering Kubernetes Security While Attacking 2
fujiihda
10
2.3k
感謝の正拳突き(セキュリティ) / Security Muscle Training
fujiihda
4
1.9k
攻撃しながら考えるKubernetesのセキュリティ / Considering Kubernetes Security While Attacking
fujiihda
16
5.5k
1893件以上のカーネルの不具合修正に貢献した再現用プログラムを自動生成するsyzkallerのテスト自動化技術 / syzkaller Kernel VM Kansai 10th
fujiihda
8
1.7k
Linuxカーネルのファジングツールsyzkaller / Linux kernel fuzzing tool syzkaller
fujiihda
2
2.8k
Other Decks in Technology
See All in Technology
検証を通して見えてきたTiDBの性能特性
lycorptech_jp
PRO
6
3.8k
ワールドカフェI /チューターを改良する / World Café I and Improving the Tutors
ks91
PRO
0
120
Azureの基本的な権限管理の勉強会
yhana
0
580
データベース02: データベースの概念
trycycle
0
160
Java EE/Jakarta EEの現状と将来―クラウドネイティブ時代にJava EEは対応できるのか?―
takakiyo
1
160
20240418_Google ColabにLLMが搭載されたようなのでPython x データ分析の勉強方法を考えてみる
doradora09
0
140
ChatworkのSRE部って実は 半分くらいPlatform Engineering部かもしれない
saramune
0
160
DevOpsメトリクスとアウトカムの接続にトライ!開発プロセスを通して計測できるメトリクスの活用方法
ham0215
2
240
開発パフォーマンスを最大化するための開発体制
ham0215
2
430
Google Cloud の AI を支える裏側のインフラを垣間見る!
maroon1st
0
350
非同期推論システムによるコスト削減と信頼性向上
koki_nishihara
0
260
Azure犬駆動開発の記録/GlobalAzureFukuoka2024_20240420
nina01
1
220
Featured
See All Featured
Testing 201, or: Great Expectations
jmmastey
28
6.4k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
9
8.3k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
2
3.4k
Code Review Best Practice
trishagee
55
15k
GraphQLとの向き合い方2022年版
quramy
32
12k
Making Projects Easy
brettharned
108
5.5k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
14
1.5k
Practical Orchestrator
shlominoach
182
9.7k
The World Runs on Bad Software
bkeepers
PRO
61
6.7k
Producing Creativity
orderedlist
PRO
337
39k
BBQ
matthewcrist
80
8.8k
Happy Clients
brianwarren
92
6.4k
Transcript
fujiihda 2020/1/16 Docker Meetup Tokyo #34 (年明けLT大会) OSの機能から考える コンテナセキュリティ
2 2 @fujiihda 掲載内容は個人の見解であり、 所属する企業やコミュニティの立場、 戦略、意見を代表するものではありません
3 @fujiihda
4 4 @fujiihda 今日は赤の箇所 にフォーカス Whois • 藤井 秀行 (ふじい
ひでゆき) – 役割:Infrastructure Engineer / 技術系コミュニティ運営等 – 仕事:技術調査、製品開発、SRE – 経歴:監視、OS (Linux)、コンテナ – 趣味:セキュリティ技術 fujiihda
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 無効
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 無効 今日伝えたいこと - とりあえず無効ヨクナイ!!
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 今日は赤の箇所 にフォーカス
8 8 @fujiihda (参考) コンテナリスクの内訳 • 狭義の意味でのコンテナに関連する次の 5 つ –
コンテナランタイムの脆弱性 – コンテナからの無制限なネットワークアクセス – コンテナランタイムの脆弱な設定 – コンテナ上で動作するアプリケーションの脆弱性 – (計画されていない) 不正なコンテナ
9 9 @fujiihda (参考) ホスト OS リスクの内訳 • コンテナを動作させるホスト OS
に関連する次の 5 つ – ホスト OS 自体に存在する脆弱性 – カーネルを共有することに起因するアイソレーションレベルの低さ – ホスト OS のコンポーネントの脆弱性 – 不適切なユーザアクセス権限 – ホスト OS のファイルシステムの改ざん
10 10 @fujiihda コンテナリスクとホスト OS リスクへの対処 (1/2) • 基本対処 –
ホスト は常に最新にして、なるべく脆弱性のないようにする – コンテナ は最小構成にして、ユーザ権限 / 通信先 / ファイル システムへのアクセスも必要最低限にする – アプリケーション に脆弱性を作りこまないための努力をする – 環境 は 本番、試験、検証 などの用途に応じて分割して、 信用できない状況ではマルチテナントを避け、 ログをはじめとする監査に役立つ情報はしっかりと残す あれ?当たり前かも? (コンテナリスクとホスト OS リスクに限定しているため)
11 11 @fujiihda コンテナリスクとホスト OS リスクへの対処 (2/2) • 基本対処 +
α (思い付いたものだけなのでもっとあるはず) – OS のセキュリティ機能を有効活用 • seccomp / Linux ケーパビリティ など – 攻撃時のふるまい検知 • Sysdig など – コンテナと親和性の高そうな仕組みの活用 • DevSecOps / 静的コード解析 など (個人的には バイナリ解析 / API のファジング) 今日は赤の箇所 にフォーカス
12 12 @fujiihda コンテナ で使える OS のセキュリティ機能の一部 • seccomp (今日紹介するのは
mode 2 seccomp filter モード) – プロセスが利用できるシステムコールを制限できる – Docker では、コンテナ内のプロセスが実行するシステムコールを 制限できる – 定義したシステムコールが呼ばれたときの制御を、許可、拒否、 終了などのアクションから選択でき、種類だけでなく、引数との 組み合わせも定義可能 – 任意のコマンドが実行されたとしても、影響範囲を最小限に抑える ことが可能 • Linux ケーパビリティ – root 権限を目的別に約 30 個に分割した特権機能群 – 必要に応じて付与 / 剥奪 今日は赤の箇所 にフォーカス
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 (以下略) (実行結果省略) アクションの対象の システムコール名を定義 アクションを定義 デフォルトアクション を定義
14 14 @fujiihda (参考) ありそうな質問と回答 • Q1:いずれか 1 つでも使えば、攻撃を止められるのでは? •
A1:そういうこともあるが、どれか 1 つという考え方ではなく、重ね掛けして 多層防御するという考え方をしてほしい。これらの機能は有効化することで、攻 撃可能な面を減らすことができる。なお、Dirty CoW をはじめとする Linux カーネル脆弱性やハードウェア脆弱性など、これらで止めることができない脆弱 性も存在する。根本対処であるホストを最新に保つことも忘れないでほしい。 • Q2:ベストプラクティスはどれですか? • A2:重ね掛けを基本としてほしいが、使い分けという意味であれば、Linux ケー パビリティと seccomp は目的が違う。Linux ケーパビリティは目的別で指定で きる反面、粒度が荒すぎる。一方、seccomp は細かい設定ができるが適切に設 定するのは大変で、粒度が細かすぎる。それぞれを必要最低限とすることが好ま しいが、無効化してしまうくらいなら、デフォルト設定を試してほしい。なお、 Linux ケーパビリティのデフォルトはやや過剰なので、デフォルトから剥奪も検 討してほしい。
15 15 @fujiihda まとめ • コンテナ特有のセキュリティリスクと対策は NIST SP 800-190 で整理されている
• コンテナリスクとホスト OS リスクに限定すれば、 セキュリティの基本的な考え方の多くはコンテナでも 通用する (ただし、それ以外も含めたときは考慮する べきことが増える) • OS のセキュリティ機能をコンテナで使うときは – 基本的な考え方は多層防御 – 求められる要件や粒度に応じて重ね掛けしつつ使い分ける – 無効化よりデフォルト設定