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
2.9k
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.4k
感謝の正拳突き(セキュリティ) / Security Muscle Training
fujiihda
4
2k
攻撃しながら考えるKubernetesのセキュリティ / Considering Kubernetes Security While Attacking
fujiihda
16
5.6k
1893件以上のカーネルの不具合修正に貢献した再現用プログラムを自動生成するsyzkallerのテスト自動化技術 / syzkaller Kernel VM Kansai 10th
fujiihda
8
1.7k
Linuxカーネルのファジングツールsyzkaller / Linux kernel fuzzing tool syzkaller
fujiihda
2
3k
Other Decks in Technology
See All in Technology
Our Journey from in-House CD System to Open Source
ffjlabo
0
100
手軽に始める? おうちサーバーのすゝめ
nyagasan
0
180
Oracle Database 23ai 新機能 #3 Oracle Globally Distributed Database(GDD)
oracle4engineer
PRO
1
160
目標設定と習慣化で今よりも一歩生産性を上げる
sansantech
PRO
7
2.3k
株式会社M2X エンジニアチーム紹介資料
m2xsoftware
0
320
HolidayJp.jl を作りました
mrkn
0
110
技術ブログや登壇資料を秒で作るコツ伝授します
minorun365
PRO
16
4.4k
「名前解決」から振り返るAmazon VPC
yuki_ink
0
320
Oracle Exadata Database Service(Dedicated Infrastructure):サービス概要のご紹介
oracle4engineer
PRO
0
9.3k
LLMに日本語テキストを学習させる意義
ksaito
13
3.4k
リクルートのデータマネジメント組織に 求められてきたコト
recruitengineers
PRO
4
340
Dive Deep in Cloud Run: Automatic Base Image update
aoto
PRO
0
900
Featured
See All Featured
Making the Leap to Tech Lead
cromwellryan
128
8.8k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
38
9.1k
Intergalactic Javascript Robots from Outer Space
tanoku
268
26k
How to name files
jennybc
75
97k
Learning to Love Humans: Emotional Interface Design
aarron
270
40k
RailsConf 2023
tenderlove
26
790
The Art of Programming - Codeland 2020
erikaheidi
48
13k
Adopting Sorbet at Scale
ufuk
72
8.9k
We Have a Design System, Now What?
morganepeng
48
7.1k
Build your cross-platform service in a week with App Engine
jlugia
228
18k
Atom: Resistance is Futile
akmur
261
25k
Writing Fast Ruby
sferik
623
60k
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 のセキュリティ機能をコンテナで使うときは – 基本的な考え方は多層防御 – 求められる要件や粒度に応じて重ね掛けしつつ使い分ける – 無効化よりデフォルト設定