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

JAWS DAYS 2018

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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 β
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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",
    　　　　　　...
    　　　　}
    　　}
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

35. 35
    NO!!
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

43. Deep dive！
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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.
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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 イメージの定期的な解析
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

73. 秘密を守る
    73
    

    View Slide

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

    View Slide

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/
    

    View Slide

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/
    

    View Slide

77. チームで守る
    77
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

81. Join us :)
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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/
    

    View Slide