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

Transcript

1. Securing container-based applications コンテナを守る技術 2018 JAWS DAYS Mar 10, 2018

   　 Ryo NAKAMARU, JAWS-UG コンテナ支部

2. 中丸 良 @pottava • AWS Certified SA, DevOps Engineer -

   Pro • CTO at SUPINF Inc. / Solutions Architect at Rescale, Inc. • クラサバ ERP → Web → クラウド / Docker → HPC / ML Profile 2

3. 中丸 良 @pottava • AWS Certified SA, DevOps Engineer -

   Pro • CTO at SUPINF Inc. / Solutions Architect at Rescale, Inc. • クラサバ ERP → Web → クラウド / Docker → HPC / ML Profile 3 （今日のセッション概要ページより）

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

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

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

7. クイズ！ DockerHub 2015 年の状況で正しいものはどれ？ 7 1. リポジトリごとに 平均 180 の脆弱性

   がある 2. 多くのリポジトリは 100 日以上 メンテナンスされていない 3. 脆弱な親を持つイメージは当然脆弱性も引き継ぐ

8. 答え 8 正解: 全部正しい そして Official だから安全 というわけでも ない こんな結果も

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

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

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

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

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

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

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

15. 安心のための 3 つの問い 15 1. アプリケーションの詳細な挙動、把握できていますか？ 2. AWS でのセキュアな構成、設計できていますか？ 3.

    セキュリティポリシーをテストする仕組み、ありますか？

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

17. これまではホストごとの管理が基本 17 　　EC2 　Classic Web (PHP 5.3) - Port: 80

    - RDS, CW Logs を利用 　SecurityGroup - TCP: 80 　InstanceRole - CWLogs-Write

18. これまではホストごとの管理が基本 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

19. ホストとアプリを適切に管理できる時代に 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

20. ホストとアプリを適切に管理できる時代に 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

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

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

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

    • 内部的に使われるシステムコールはどれ？

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

25. ホストまで管理する？ 25 • 社内規定で許可された AWS サービスしか利用できない • ホストにインストールしないといけないものがある ‣ IDS

    / IPS などセキュリティ製品 ‣ ログ・メトリクス・トレース情報などの収集 • ハードウェアに強く依存するソフトウェアを動かしたい ‣ 特定の CPU アーキテクチャ / GPU ‣ 各種 I/O のために EC2 やカーネルの設定を変えたい

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

27. 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 β

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

29. awsvpc モード（Fargate） アプリケーション専用のネットワーク 29 ECS 　SecurityGroup - TCP 80 from

    ALB 　REST API コンテナ - Port: 80 ALB

30. アプリケーションに必要なものの定義 30 　REST API コンテナ - Port 80 番を公開 -

    auth コンテナと話したい - メモリ 128 MiB 最低限確保 - メモリ 512 MiB 超えたら死 - ファイル書き込み不要 - 標準出力は CW Logs に

31. 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, 　　　　"logConfiguration": { 　　　　　　"logDriver": "awslogs", 　　　　　　... 　　　　} 　　}

32. 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 のみ • 厳密に定義するほど 想定していない挙動を抑えることができる • 同居する他のコンテナに影響を与えないためにも

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

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

35. 35 NO!!

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

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

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

    feature feature bug fix feature release

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

    B feature feature bug fix 定期診断 定期診断 feature release

40. アプリ実行中に攻撃やポリシー違反がないかをモニタ 3. 実行時スキャン 40 　EC2 　コンテナ A 　コンテナ C 　コンテナ

    B 何らかのサービス - 脅威の判定 - SIEM 収集. - etc.……….. 　監視ツール 　監視ツール

41. 41 継続的なチェック • コードベースが変わる度にポリシーを 都度 チェック（CI） • 新しく発見された脆弱性などの影響を 定期的に チェック

    • アプリケーション 実行中に 攻撃の有無やポリシー違反をチェック ‣ コンテナだけでなくホストもね

42. ここまでのまとめ 42 安心のために • アプリケーションの挙動 を把握しよう • セキュリティを高める AWS の使い方

    を知ろう • ポリシー を定め定期的にチェックしよう

43. Deep dive！

44. コンテナの守り方 44 • コンポーネント編 ‣ ホストとコンテナ ‣ ホスト ‣ Docker

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

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

46. 守りやすい環境を整える 46 セグメントを分け、攻撃対象・感染範囲を限定的に • クラスタを分割 ‣ 役割別・顧客別・ビジネス別・環境別 ‣ リスクはあるか、信頼できるか、外部露出は必要か •

    ネットワークを分割 ‣ ホストとコンテナ ‣ コンテナの各種ネットワークオプション

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

    　コンテナ 　コンテナ 　EC2 　コンテナ 　EC2 　コンテナ vs

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

    　コンテナ 　コンテナ 　EC2 　コンテナ 　EC2 　コンテナ vs

49. 攻撃の侵入口を減らそう 49 IAM Role、SecurityGroup の解放も 必要最小限に EC2 　SecurityGroup - TCP

    80 From ELB 　TaskRole - CWLogs-Write 　SecurityGroup - Allow nothing 　InstanceRole - ECR-Read 　コンテナ - Port: 80 - CW Logs にログ

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

51. 51 ホストはこれまで通りに守る • コンテナを使うからといっても。 • インスタンスハードニング、堅牢化 ‣ ホワイトリストの導入（ガイド：NIST 800-167） ‣

    パッチ管理、設定変更管理 • セキュリティ製品のインストール ‣ AWS Inspector 有用、ただ他製品との組み合わせも大事

52. 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.

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

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

    dockerSecurityOptions を使いたい時 ‣ ECS_SELINUX_CAPABLE=true ‣ ECS_APPARMOR_CAPABLE=true • etc.

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

56. 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

57. 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 コンテナは ホストのカーネルで 走る • ホストのリソースをほぼ 直接利用 する ⇨ 各種設定で綿密に縛っていく

58. きちんとリソース制約 58 巻き込み事故を防ぐために • ulimits (--ulimit) で利用できる上限を決める • memory を指定して、それを超えたらコンテナを落とす

    • 必要なリソースを事前に厳密に計測すると安心感しかない ‣ 過剰なリソース利用が起きても 他への影響小 ‣ サイジングやスケール戦略も想定しやすい

59. READ ONLY 59 書き込めなくする手段はいくつかある • マウントしたディレクトリ以外の書き込みを禁止 ‣ readonlyRootFilesystem • マウントしたディレクトリを書き込み禁止に

    ‣ mountPoints.readOnly ‣ volumesFrom.readOnly • AppArmor でパスベースのアクセス制御 ‣ dockerSecurityOptions

60. • システムコールに正しく権限チェックがかかるように • 面倒がらずちゃんと 適切なユーザを作りましょう • アプリケーションにあった方法で ‣ Dockerfile の

    USER 命令でデフォルトユーザを変更 ‣ タスク定義の user で実行時のユーザを強制 ‣ entrypoint.sh と gosu の組み合わせ ‣ etc. ルートユーザは使わない 60 AWS アカウント同様に！

61. • 利用するバイナリ だけ をイメージに入れる ‣ できれば 静的リンク しておく（ldd / strace

    で確認） ‣ 小さい Docker イメージにも貢献 • suid, sgid がセットされたバイナリは Docker イメージで除外 • 後述の SaaS の力を借りれば・・ 実行ファイルの管理 61 不必要なファイルは削除・無効化 　RUN find / -perm /6000 -type f -exec chmod a-s {} \; || true

62. • どこと通信するのかを まず 把握 ‣ North / South: クラスタ外部とは？ ‣

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

63. システムコールを制限する 63 ほんとは seccomp を使いたい • ECS は seccomp 未対応、SELinux

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

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

65. • 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 イメージの解析・ポリシーテスト

66. 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

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

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

69. • イメージの静的解析 ‣ 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 イメージの定期的な解析

70. • ECR のイメージ解析 ‣ 脆弱性が仕込まれていないか ‣ 設定不備、秘密情報の混入はないか • 実行時防御 ‣

    攻撃検知、ポリシー違反のチェック ‣ 実際の挙動からセキュリティポリシーの自動生成 • IAM、KMS と統合されたコンテナレベルの RBAC、秘密情報管理 aqua 70 AWS の各サービスとも統合された商用ツール

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

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

73. 秘密を守る 73

74. 秘密情報の扱い 74 扱う秘密情報は年々増える • ベタ書きや設定ファイルの持ち込みはありえないとしても・・ • 環境変数？ ‣ 12 factor

    apps ですねわかります ‣ でもそれだといろんなところから見えちゃいますよ？ ‣ 一度設定すると消すことも叶わなかったり・・

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

76. 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/

77. チームで守る 77

78. みんなで意識するセキュリティ 78 それぞれがポリシーを作り、チェックされる仕組み作り • 一般的な脆弱性は当然対応するとして • Developers / Ops engineers

    ‣ 厳密に制約されたタスク定義 ‣ IAM Role, SecurityGroup, .. ‣ Docker イメージポリシー（e.g. container-structure-test.yaml ) • Security engineers ‣ SaaS の実行ファイル / Docker イメージ利用制御 ‣ SaaS のネットワークポリシー

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

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

    実行時のスキャン・防御は SaaS も視野に

81. Join us :)

82. JAWS-UG コンテナ支部 82 • AWS でのコンテナ利用事例、ベストプラクティスの知見交換 • 定期的な AWS /

    コンテナ初心者向けハンズオン • 懇親会でも熱くコンテナを語る参加者のみなさん

83. Containerize your app! 83 • クラウド / コンテナ を強みにした受託開発運用、コンサルティング •

    2015 年から Docker の本番運用を開始・豊富な CI / CD 事例 • スピンフ、と読みます・・ We’re hiring!!!

84. Cloud HPC with 84 • クラウド HPC シミュレーションプラットフォームを提供 • スケーラブルなシミュレーションや機械学習を！

    • Singularity でのコンテナ分散実行もサポート We’re hiring!!!

85. ご静聴ありがとうございました 参考文献： • 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/