コンテナを守る技術2018/container-security-20180310

by ryo nakamaru

Slide 1

Slide 1 text

Securing container-based applications コンテナを守る技術 2018 JAWS DAYS Mar 10, 2018 　 Ryo NAKAMARU, JAWS-UG コンテナ支部

Slide 2

Slide 2 text

中丸良 @pottava • AWS Certiﬁed SA, DevOps Engineer - Pro • CTO at SUPINF Inc. / Solutions Architect at Rescale, Inc. • クラサバ ERP → Web → クラウド / Docker → HPC / ML Proﬁle 2

Slide 3

Slide 3 text

中丸良 @pottava • AWS Certiﬁed SA, DevOps Engineer - Pro • CTO at SUPINF Inc. / Solutions Architect at Rescale, Inc. • クラサバ ERP → Web → クラウド / Docker → HPC / ML Proﬁle 3 （今日のセッション概要ページより）

Slide 4

Slide 4 text

コンテナ、みなさん使ってますか？ 4

Slide 5

Slide 5 text

Fortune 100 5 29% 71% Yes No http://redmonk.com/fryan/2017/09/10/cloud-native-technologies-in-the-fortune-100/

Slide 6

Slide 6 text

セキュリティ対策はしていますか？ 6

Slide 7

Slide 7 text

クイズ！ DockerHub 2015 年の状況で正しいものはどれ？ 7 1. リポジトリごとに平均 180 の脆弱性がある 2. 多くのリポジトリは 100 日以上メンテナンスされていない 3. 脆弱な親を持つイメージは当然脆弱性も引き継ぐ

Slide 8

Slide 8 text

答え 8 正解: 全部正しいそして Oﬀicial だから安全というわけでもないこんな結果も ▶ http://dance.csc.ncsu.edu/papers/codaspy17.pdf

Slide 9

Slide 9 text

9 http://dance.csc.ncsu.edu/papers/codaspy17.pdf

Slide 10

Slide 10 text

10 https://quay.io/repository/coreos/clair?tab=tags https://hub.docker.com/r/library/docker/tags/

Slide 11

Slide 11 text

仮にベースのイメージは安全でも 11

Slide 12

Slide 12 text

業者さんから納品されたこれこのまま公開して大丈夫？ 12

Slide 13

Slide 13 text

コンテナ化されたアプリケーション安全に運用できる自信、まだないよ？ 13

Slide 14

Slide 14 text

対策、どこから始めよう？ 14

Slide 15

Slide 15 text

安心のための 3 つの問い 15 1. アプリケーションの詳細な挙動、把握できていますか？ 2. AWS でのセキュアな構成、設計できていますか？ 3. セキュリティポリシーをテストする仕組み、ありますか？

Slide 16

Slide 16 text

1. アプリケーションの詳細な挙動を把握しよう 16

Slide 17

Slide 17 text

これまではホストごとの管理が基本 17 　　EC2 　Classic Web (PHP 5.3) - Port: 80 - RDS, CW Logs を利用　SecurityGroup - TCP: 80 　InstanceRole - CWLogs-Write

Slide 18

Slide 18 text

これまではホストごとの管理が基本 18 　　EC2 　Classic Web (PHP 5.3) - Port: 80 - RDS, CW Logs を利用　REST API (Java 9) - Port: 8080 - DynamoDB 　SecurityGroup - TCP: 80 - TCP: 8080 　InstanceRole - CWLogs-Write - DynamoDB-Read

Slide 19

Slide 19 text

ホストとアプリを適切に管理できる時代に 19 EC2 　SecurityGroup - Allow nothing 　InstanceRole - ECR-Read 　Classic Web (PHP 5.3) - Port: 80 - RDS, CW Logs を利用　REST API (Java 9) - Port: 80 - DynamoDB

Slide 20

Slide 20 text

ホストとアプリを適切に管理できる時代に 20 EC2 　SecurityGroup - TCP 80 　TaskRole - CWLogs-Write 　SecurityGroup - Allow nothing 　InstanceRole - ECR-Read 　SecurityGroup - TCP 80 　TaskRole - DynamoDB-Read 　Classic Web (PHP 5.3) - Port: 80 - RDS, CW Logs を利用　REST API (Java 9) - Port: 80 - DynamoDB

Slide 21

Slide 21 text

No more 最小公倍数的な管理！

Slide 22

Slide 22 text

ここにフォーカスできるよ！

Slide 23

Slide 23 text

アプリの挙動を把握しよう 23 コンテナの各種制限機能も活かせば、挙動が把握できればできる程他への影響なしに、よりセキュアなサービス提供が実現できる • どれくらいのリソースが必要？ • どこと通信する？ • ファイル書き込みはする？どのディレクトリ以下？ • 内部的に使われるシステムコールはどれ？

Slide 24

Slide 24 text

2. AWS ならできるセキュアな構成を知ろう 24

Slide 25

Slide 25 text

ホストまで管理する？ 25 • 社内規定で許可された AWS サービスしか利用できない • ホストにインストールしないといけないものがある ‣ IDS / IPS などセキュリティ製品 ‣ ログ・メトリクス・トレース情報などの収集 • ハードウェアに強く依存するソフトウェアを動かしたい ‣ 特定の CPU アーキテクチャ / GPU ‣ 各種 I/O のために EC2 やカーネルの設定を変えたい

Slide 26

Slide 26 text

ホストまで管理したい？ 26 でもいわゆるコントロールプレインは管理したくない、なら　　　　Amazon ECS / AWS Batch

Slide 27

Slide 27 text

awsvpc モードアプリケーション専用のネットワーク 27 ECS EC2 　SecurityGroup - TCP 80 from ALB α 　SecurityGroup - TCP 80 from ALB β 　REST API コンテナ A - Port: 80 　REST API コンテナ B - Port: 80 ALB α ALB β

Slide 28

Slide 28 text

アプリケーションだけ考えていたいなら AWS Fargate ホストは忘れたい 28

Slide 29

Slide 29 text

awsvpc モード（Fargate）アプリケーション専用のネットワーク 29 ECS 　SecurityGroup - TCP 80 from ALB 　REST API コンテナ - Port: 80 ALB

Slide 30

Slide 30 text

アプリケーションに必要なものの定義 30 　REST API コンテナ - Port 80 番を公開 - auth コンテナと話したい - メモリ 128 MiB 最低限確保 - メモリ 512 MiB 超えたら死 - ファイル書き込み不要 - 標準出力は CW Logs に

Slide 31

Slide 31 text

ECS タスク定義アプリケーションに必要なものの定義 31 　REST API コンテナ - Port 80 番を公開 - auth コンテナと話したい - メモリ 128 MiB 最低限確保 - メモリ 512 MiB 超えたら死 - ファイル書き込み不要 - 標準出力は CW Logs に ▶ 　　{ 　　　　"portMappings": [{ 　　　　　　"ContainerPort": 80 　　　　}], 　　　　"links": ["auth:auth"], 　　　　"memoryReservation": 126, 　　　　"memory": 512, 　　　　"readonlyRootFilesystem": true, 　　　　"logConﬁguration": { 　　　　　　"logDriver": "awslogs", 　　　　　　... 　　　　} 　　}

Slide 32

Slide 32 text

ECS タスク定義 32 • Docker が本来持つセキュリティオプションも数多く使える ‣ readonlyRootFilesystem (--read-only) ‣ mountPoints.readOnly (--volume), volumesFrom.readOnly ‣ ulimits (--ulimit) / memory / cpu (--cpu-shares) ‣ linuxParameters.capabilities (--cap-add / --cap-drop) ‣ dockerSecurityOptions (--security-opt) ←SELinux, AppArmor のみ • 厳密に定義するほど想定していない挙動を抑えることができる • 同居する他のコンテナに影響を与えないためにも

Slide 33

Slide 33 text

タスク定義、IAM Role、awsvpc/SG 併用でアプリのセキュリティにフォーカスできる！

Slide 34

Slide 34 text

アプリケーションの定義はできたこれでもう安全？ 34

Slide 35

Slide 35 text

35 NO!!

Slide 36

Slide 36 text

3. セキュリティポリシーをテストしよう 36

Slide 37

Slide 37 text

37 継続的なチェック大事ですよね

Slide 38

Slide 38 text

継続的にポリシー上問題がないことを確認する 1. 都度テスト　　　　　　 . 38 例）サービス A サービス B feature feature bug ﬁx feature release

Slide 39

Slide 39 text

継続的にポリシー上問題がないことを確認する 1. 都度テスト, 2. 定期テスト 39 例）サービス A サービス B feature feature bug ﬁx 定期診断定期診断 feature release

Slide 40

Slide 40 text

アプリ実行中に攻撃やポリシー違反がないかをモニタ 3. 実行時スキャン 40 　EC2 　コンテナ A 　コンテナ C 　コンテナ B 何らかのサービス - 脅威の判定 - SIEM 収集. - etc.……….. 　監視ツール　監視ツール

Slide 41

Slide 41 text

41 継続的なチェック • コードベースが変わる度にポリシーを都度チェック（CI） • 新しく発見された脆弱性などの影響を定期的にチェック • アプリケーション実行中に攻撃の有無やポリシー違反をチェック ‣ コンテナだけでなくホストもね

Slide 42

Slide 42 text

ここまでのまとめ 42 安心のために • アプリケーションの挙動を把握しよう • セキュリティを高める AWS の使い方を知ろう • ポリシーを定め定期的にチェックしよう

Slide 43

Slide 43 text

Deep dive！

Slide 44

Slide 44 text

コンテナの守り方 44 • コンポーネント編 ‣ ホストとコンテナ ‣ ホスト ‣ Docker コンテナ • ライフサイクル編 ‣ Build（ごとの都度テスト）& Ship（後の定期的なスキャン） ‣ Deploy（後の実行時スキャン）

Slide 45

Slide 45 text

[ コンテナの守り方・コンポーネント編 ] ホストとコンテナ

Slide 46

Slide 46 text

守りやすい環境を整える 46 セグメントを分け、攻撃対象・感染範囲を限定的に • クラスタを分割 ‣ 役割別・顧客別・ビジネス別・環境別 ‣ リスクはあるか、信頼できるか、外部露出は必要か • ネットワークを分割 ‣ ホストとコンテナ ‣ コンテナの各種ネットワークオプション

Slide 47

Slide 47 text

スケールアップよりスケールアウト 47 被害を最小限に、全滅を避ける　EC2 　コンテナ　コンテナ　コンテナ　コンテナ　コンテナ　EC2 　コンテナ　コンテナ　EC2 　コンテナ　EC2 　コンテナ vs

Slide 48

Slide 48 text

スケールアップよりスケールアウト 48 被害を最小限に、全滅を避ける　EC2 　コンテナ　コンテナ　コンテナ　コンテナ　コンテナ　EC2 　コンテナ　コンテナ　EC2 　コンテナ　EC2 　コンテナ vs

Slide 49

Slide 49 text

攻撃の侵入口を減らそう 49 IAM Role、SecurityGroup の解放も必要最小限に EC2 　SecurityGroup - TCP 80 From ELB 　TaskRole - CWLogs-Write 　SecurityGroup - Allow nothing 　InstanceRole - ECR-Read 　コンテナ - Port: 80 - CW Logs にログ

Slide 50

Slide 50 text

[ コンテナの守り方・コンポーネント編 ] ホスト

Slide 51

Slide 51 text

51 ホストはこれまで通りに守る • コンテナを使うからといっても。 • インスタンスハードニング、堅牢化 ‣ ホワイトリストの導入（ガイド：NIST 800-167） ‣ パッチ管理、設定変更管理 • セキュリティ製品のインストール ‣ AWS Inspector 有用、ただ他製品との組み合わせも大事

Slide 52

Slide 52 text

Docker ホストとして大丈夫？ 52 github.com/docker/docker-bench-security The Docker Bench for Security is a script that checks for dozens of common best-practices around deploying Docker containers in production.

Slide 53

Slide 53 text

The Docker Bench for Security の自動化 53 https://www.slideshare.net/AmazonWebServices/aws-reinvent-2016-securing-containerbased-applications-con402

Slide 54

Slide 54 text

ECS エージェント 54 事前設定するとコンテナのセキュリティに役立つものも • 特権を持つコンテナの起動を許可しない ‣ ECS_DISABLE_PRIVILEGED=true • コンテナ起動時に dockerSecurityOptions を使いたい時 ‣ ECS_SELINUX_CAPABLE=true ‣ ECS_APPARMOR_CAPABLE=true • etc.

Slide 55

Slide 55 text

[ コンテナの守り方・コンポーネント編 ] Docker コンテナ

Slide 56

Slide 56 text

VirtualMachines 56 ハイパーバイザホスト OS ホスト OS dockerd containerd application A … Containers ゲスト OS Y ゲスト OS Z VM と Docker コンテナ application B application C runc application A runc application B runc application C

Slide 57

Slide 57 text

VirtualMachines 57 ハイパーバイザホスト OS ホスト OS dockerd containerd application A … Containers ゲスト OS Y ゲスト OS Z VM と Docker コンテナ application B application C runc application A runc application B runc application C リソースの分離が VM ほど厳密ではない • Docker コンテナはホストのカーネルで走る • ホストのリソースをほぼ直接利用する ⇨ 各種設定で綿密に縛っていく

Slide 58

Slide 58 text

きちんとリソース制約 58 巻き込み事故を防ぐために • ulimits (--ulimit) で利用できる上限を決める • memory を指定して、それを超えたらコンテナを落とす • 必要なリソースを事前に厳密に計測すると安心感しかない ‣ 過剰なリソース利用が起きても他への影響小 ‣ サイジングやスケール戦略も想定しやすい

Slide 59

Slide 59 text

READ ONLY 59 書き込めなくする手段はいくつかある • マウントしたディレクトリ以外の書き込みを禁止 ‣ readonlyRootFilesystem • マウントしたディレクトリを書き込み禁止に ‣ mountPoints.readOnly ‣ volumesFrom.readOnly • AppArmor でパスベースのアクセス制御 ‣ dockerSecurityOptions

Slide 60

Slide 60 text

• システムコールに正しく権限チェックがかかるように • 面倒がらずちゃんと適切なユーザを作りましょう • アプリケーションにあった方法で ‣ Dockerﬁle の USER 命令でデフォルトユーザを変更 ‣ タスク定義の user で実行時のユーザを強制 ‣ entrypoint.sh と gosu の組み合わせ ‣ etc. ルートユーザは使わない 60 AWS アカウント同様に！

Slide 61

Slide 61 text

• 利用するバイナリだけをイメージに入れる ‣ できれば静的リンクしておく（ldd / strace で確認） ‣ 小さい Docker イメージにも貢献 • suid, sgid がセットされたバイナリは Docker イメージで除外 • 後述の SaaS の力を借りれば・・実行ファイルの管理 61 不必要なファイルは削除・無効化　RUN ﬁnd / -perm /6000 -type f -exec chmod a-s {} \; || true

Slide 62

Slide 62 text

• どこと通信するのかをまず把握 ‣ North / South: クラスタ外部とは？ ‣ East / West: クラスタ内部では？ • タスク定義で有用なオプション ‣ links: 同じタスク定義内で通信が必要なとき ‣ networkMode: none、bridge、awsvpc または host ‣ disableNetworking: 該当コンテナのネットワーキングを無効に • これも後述の SaaS を使えば・・通信を制限する 62 通信先、解放ポートも最小限に

Slide 63

Slide 63 text

システムコールを制限する 63 ほんとは seccomp を使いたい • ECS は seccomp 未対応、SELinux と AppArmor は使途違い • linuxParameters.capabilities でドロップドロップ〜 ‣ それぞれの Capability で制御できるシステムコールとにらめっこ ‣ ここで制御できないものはできない • ただ、これ突き詰める必要ある・・？

Slide 64

Slide 64 text

[ コンテナの守り方・ライフサイクル編 ] Build

Slide 65

Slide 65 text

• Static Application Security Testing ツール (OSS / 商用) の利用 ‣ https://www.owasp.org/index.php/Source_Code_Analysis_Tools ‣ https://github.com/mre/awesome-static-analysis ‣ CoreOS の Clair • Docker イメージのポリシーを定義 & チェック ‣ GoogleCloudPlatform/container-structure-test の yaml ‣ Aqua security の Manifesto CI 65 コードの静的解析、Docker イメージの解析・ポリシーテスト

Slide 66

Slide 66 text

GoogleCloudPlatform/container-structure-test 66 コンテナのあるべき姿をポリシーとして定義、テスト可能 ‣ 指定したコマンドに対する出力は正しいか ‣ ファイルは正しい属性で存在するか ‣ ENTRYPOINT や CMD、環境変数、ポートなどメタデータは正しいか　　$ cat << EOF > test.yaml 　　schemaVersion: '2.0.0' 　　fileExistenceTests: 　　 - name: 'binary' 　　 path: '/usr/bin/aws' 　　 shouldExist: true 　　EOF 　　$ docker run --rm --privileged -v /var/run/docker.sock:/var/run/docker.sock \ 　　 -v $(pwd):/config supinf/container-struct-test:0.2 \ 　　 -image supinf/awscli:1.14 /config/test.yaml

Slide 67

Slide 67 text

CI の自動化 67 https://www.slideshare.net/AmazonWebServices/aws-reinvent-2016-securing-containerbased-applications-con402

Slide 68

Slide 68 text

[ コンテナの守り方・ライフサイクル編 ] Ship / Deploy

Slide 69

Slide 69 text

• イメージの静的解析 ‣ coreos/clair ‣ eliasgranderubio/dagda • CI 以降、SaaS を使うことも検討 ‣ aqua: https://www.aquasec.com/partners/aws-container-security-ecs/ ‣ NeuVector: https://neuvector.com/solutions-for-aws-ecs-security/ ‣ Twistlock: https://www.twistlock.com/solutions/amazon-ecs-security/ 新たな脅威への対応 69 Docker イメージの定期的な解析

Slide 70

Slide 70 text

• ECR のイメージ解析 ‣ 脆弱性が仕込まれていないか ‣ 設定不備、秘密情報の混入はないか • 実行時防御 ‣ 攻撃検知、ポリシー違反のチェック ‣ 実際の挙動からセキュリティポリシーの自動生成 • IAM、KMS と統合されたコンテナレベルの RBAC、秘密情報管理 aqua 70 AWS の各サービスとも統合された商用ツール

Slide 71

Slide 71 text

NeuVector 71 実行時脆弱性スキャン & ポリシー違反チェック

Slide 72

Slide 72 text

CD パイプラインの自動化 72 https://www.slideshare.net/AmazonWebServices/aws-reinvent-2016-securing-containerbased-applications-con402

Slide 73

Slide 73 text

秘密を守る 73

Slide 74

Slide 74 text

秘密情報の扱い 74 扱う秘密情報は年々増える • ベタ書きや設定ファイルの持ち込みはありえないとしても・・ • 環境変数？ ‣ 12 factor apps ですねわかります ‣ でもそれだといろんなところから見えちゃいますよ？ ‣ 一度設定すると消すことも叶わなかったり・・

Slide 75

Slide 75 text

2016 年までの秘密 75 S3 に置いたり SaaS を使ったり https://aws.amazon.com/blogs/compute/managing-secrets-for-amazon-ecs-applications-using-parameter-store-and-iam-roles-for-tasks/

Slide 76

Slide 76 text

2017 年からの秘密 76 SSM Parameter Store & KMS & IAM Role https://aws.amazon.com/jp/blogs/news/managing-secrets-for-amazon-ecs-applications-using-parameter-store-and-iam-roles-for-tasks/

Slide 77

Slide 77 text

チームで守る 77

Slide 78

Slide 78 text

みんなで意識するセキュリティ 78 それぞれがポリシーを作り、チェックされる仕組み作り • 一般的な脆弱性は当然対応するとして • Developers / Ops engineers ‣ 厳密に制約されたタスク定義 ‣ IAM Role, SecurityGroup, .. ‣ Docker イメージポリシー（e.g. container-structure-test.yaml ) • Security engineers ‣ SaaS の実行ファイル / Docker イメージ利用制御 ‣ SaaS のネットワークポリシー

Slide 79

Slide 79 text

まとめ 79 コンポーネント編 • ホストとコンテナを論理的に分ける • ホストはこれまで通り管理、コンテナ由来の解放は最小限に • コンテナに与える権限も、アプリケーションを把握し最小に

Slide 80

Slide 80 text

まとめ 80 ライフサイクル編 • 静的解析はソースコードだけでなく Docker イメージにも！ • 依存ライブラリの新たな脅威に反応できるよう定期スキャン • 実行時のスキャン・防御は SaaS も視野に

Slide 81

Slide 81 text

Join us :)

Slide 82

Slide 82 text

JAWS-UG コンテナ支部 82 • AWS でのコンテナ利用事例、ベストプラクティスの知見交換 • 定期的な AWS / コンテナ初心者向けハンズオン • 懇親会でも熱くコンテナを語る参加者のみなさん

Slide 83

Slide 83 text

Containerize your app! 83 • クラウド / コンテナを強みにした受託開発運用、コンサルティング • 2015 年から Docker の本番運用を開始・豊富な CI / CD 事例 • スピンフ、と読みます・・ We’re hiring!!!

Slide 84

Slide 84 text

Cloud HPC with 84 • クラウド HPC シミュレーションプラットフォームを提供 • スケーラブルなシミュレーションや機械学習を！ • Singularity でのコンテナ分散実行もサポート We’re hiring!!!

Slide 85

Slide 85 text

ご静聴ありがとうございました参考文献： • Cloud Native Technologies in the Fortune 100 　　　　　　　　　 http://redmonk.com/fryan/2017/09/10/cloud-native-technologies-in-the-fortune-100/ • A Study of Security Vulnerabilities on Docker Hub　　　　　　　 http://dance.csc.ncsu.edu/papers/codaspy17.pdf • NIST Special Publication 800-167 - Guide to Application Whitelisting 　 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-167.pdf • タスクIAMロールとパラメータストアを利用したAmazon ECSアプリケーションの秘密情報管理　 https://aws.amazon.com/jp/blogs/news/managing-secrets-for-amazon-ecs-applications- using-parameter-store-and-iam-roles-for-tasks/