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 Se...
Search
fujiihda
January 16, 2020
Technology
8
3.1k
OSの機能から考えるコンテナセキュリティ / Considering Container Security
Docker Meetup Tokyo #34
(20200905_修正)
p14「(参考) ありそうな質問と回答」の回答内容を一部修正
fujiihda
January 16, 2020
Tweet
Share
More Decks by fujiihda
See All by fujiihda
TAMとre:Capセキュリティ編 〜拡張脅威検出デモを添えて〜
fujiihda
2
600
攻撃しながら考えるKubernetesセキュリティ / Considering Kubernetes Security While Attacking 2
fujiihda
10
2.6k
感謝の正拳突き(セキュリティ) / Security Muscle Training
fujiihda
4
2.4k
攻撃しながら考えるKubernetesのセキュリティ / Considering Kubernetes Security While Attacking
fujiihda
16
5.7k
1893件以上のカーネルの不具合修正に貢献した再現用プログラムを自動生成するsyzkallerのテスト自動化技術 / syzkaller Kernel VM Kansai 10th
fujiihda
8
1.9k
Linuxカーネルのファジングツールsyzkaller / Linux kernel fuzzing tool syzkaller
fujiihda
2
3.3k
Other Decks in Technology
See All in Technology
Implementing and Evaluating a High-Level Language with WasmGC and the Wasm Component Model: Scala’s Case
tanishiking
0
140
React19.2のuseEffectEventを追う
maguroalternative
2
500
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
20k
なぜAWSを活かしきれないのか?技術と組織への処方箋
nrinetcom
PRO
5
980
プレーリーカードを活用しよう❗❗デジタル名刺交換からはじまるイベント会場交流のススメ
tsukaman
0
180
それでも私が品質保証プロセスを作り続ける理由 #テストラジオ / Why I still continue to create QA process
pineapplecandy
0
130
『バイトル』CTOが語る! AIネイティブ世代と切り拓くモノづくり組織
dip_tech
PRO
1
130
Data Hubグループ 紹介資料
sansan33
PRO
0
2.2k
AWS Control Tower に学ぶ! IAM Identity Center 権限設計の第一歩 / IAM Identity Center with Control Tower
y___u
1
200
Digitization部 紹介資料
sansan33
PRO
1
5.6k
RDS の負荷が高い場合に AWS で取りうる具体策 N 連発/a-series-of-specific-countermeasures-available-on-aws-when-rds-is-under-high-load
emiki
7
4.1k
技育祭2025【秋】 企業ピッチ/登壇資料(高橋 悟生)
hacobu
PRO
0
110
Featured
See All Featured
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.2k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Gamification - CAS2011
davidbonilla
81
5.5k
Music & Morning Musume
bryan
46
6.8k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
61k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.2k
Building Adaptive Systems
keathley
44
2.8k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
Agile that works and the tools we love
rasmusluckow
331
21k
Raft: Consensus for Rubyists
vanstee
140
7.1k
Thoughts on Productivity
jonyablonski
70
4.9k
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 のセキュリティ機能をコンテナで使うときは – 基本的な考え方は多層防御 – 求められる要件や粒度に応じて重ね掛けしつつ使い分ける – 無効化よりデフォルト設定