クラウドネイティブ時代のセキュリティの考え方とIstioによる実装 / cloud native security and istio

Transcript

1. クラウドネイティブ時代の セキュリティの考え方とIstioによる実装 2019年7月23日 三好 俊介 (s.miyoshi@jp.fujitsu.com) 富士通株式会社 Copyright 2019 FUJITSU LIMITED 0
2. 目次 ◼クラウドネイティブ時代のセキュリティ ◼ イメージ図 ◼ Zero Trust Network ◼Istio ◼ Istioの概要 ◼ 可視化について ◼ アクセス制御の方法 ◼ デモ ◼まとめ Copyright 2019 FUJITSU LIMITED 1
3. Who am I ? ◼富士通株式会社 三好俊介 ◼最近の仕事 ◼ インフラ基盤の構築・運用 ◼ (Backend/Frontend)アプリケーションの開発 ◼コンテナ技術に関して ◼ Kubernetes v1.5, Istio v0.4くらいから参戦 （現在はKubernetes v1.14, Istio v1.2） ◼ Certified Kubernetes Administrator • 2017年9月に取得 Copyright 2019 FUJITSU LIMITED 2 何でも屋
4. Copyright 2019 FUJITSU LIMITED 3 クラウドネイティブ
5. クラウドネイティブの定義 ◼CNCF Cloud Native Definition v1.0 ◼ 要約 • クラウドを前提とした環境で • 変化に強いスケーラブルなアプリの構築、実行の能力を • 組織にもたらす技術 ◼技術要素 ◼ コンテナ、マイクロサービスなど Copyright 2019 FUJITSU LIMITED 4 参考: https://github.com/cncf/toc/blob/master/DEFINITION.md#%E6%97%A5%E6%9C%AC%E8%AA%9E%E7%89%88
6. Copyright 2019 FUJITSU LIMITED 5 クラウドネイティブな世界
7. 私が思うクラウドネイティブな世界 ◼クラウドネイティブな世界 ◼ 人だけでなくもの(サービス・デバイスにも権限を与えられる) ◼ 会社の中、外という概念はない ※ 働き方改革という潮流が後押ししてくれている • リモートワークなど Copyright 2019 FUJITSU LIMITED 6 適切な人・ものに適切な権限を与えられ、 その権限があればいつでもどこからでもアクセスできる世界
8. クラウドネイティブな世界のイメージ図 Copyright 2019 FUJITSU LIMITED 7 PC in 自宅 PC in 会社 認証サーバ Webサーバ DB GW GW クラウド × × Webはok 正統なユーザ && 権限あり？ 抜け道はなし 証明書 証明書
9. クラウドネイティブ世界のセキュリティ ◼Zero Trust Network ◼ 2010年に提唱された新しいセキュリティモデル ◼ コンセプト: 何も信じるな、必ず疑ってかかれ • 社内ネットワークだからと言って本当に信頼できるのか？ • 特権VPNでアクセスしてきたからといって本当に管理者か？ ◼実現に必要なこと ◼ 誰と通信しているのか(通信相手の認証) ◼ 通信路の安全性(通信路の暗号化) Copyright 2019 FUJITSU LIMITED 8
10. 事例紹介 ◼BeyondCorp(Google) ◼ Googleで7年の知見をもとに設計された新しいセキュリティモデル ◼ VPNを使用しなくても すべての従業員が どこからでも仕事が可能 ◼ すべてのリソースへの アクセスは必ず認証、 認可、暗号化される Copyright 2019 FUJITSU LIMITED 9 参考: https://cloud.google.com/beyondcorp/?hl=ja , https://www.atmarkit.co.jp/ait/articles/1808/16/news015.html
11. 事例紹介 ◼BeyondCorp(Google) ◼ Googleで7年の知見をもとに設計された新しいセキュリティモデル ◼ VPNを使用しなくても すべての従業員が どこからでも仕事が可能 ◼ すべてのリソースへの アクセスは必ず認証、 認可、暗号化される Copyright 2019 FUJITSU LIMITED 10 参考: https://cloud.google.com/beyondcorp/?hl=ja , https://www.atmarkit.co.jp/ait/articles/1808/16/news015.html Googleのような超巨大企業でもできている → 夢物語ではない
12. 導入の手順 ◼Googleはどのようにしていったのか 1. 可視化 ◼ いつだれがどこにアクセスしてきたのか？ → 現状を把握できていないのに縛るのはダメ ◼ セキュリティを上げるからUXは落ちますっていうのは最悪 → デジタルツインのような環境で徹底的なシミュレーション 2. 制御 ◼ 完全に動作を把握できたら考えていくべし → 先に制御するとトラブル時の原因究明が非常に困難 Copyright 2019 FUJITSU LIMITED 11
13. 前半のまとめ ◼クラウドネイティブな世界とは？ ◼ 適切な人に適切な権限を与えられ、 その権限があればいつでもどこからでもアクセスできる世界 ◼クラウドネイティブな世界のセキュリティモデル ◼ Zero Trust Network • コンセプト: 何も信じるな、必ず疑ってかかれ • 必要条件: 通信する相手の認証と通信路の暗号化 Copyright 2019 FUJITSU LIMITED 12
14. Istio Copyright 2019 FUJITSU LIMITED 13
15. クラウドネイティブとIstio ◼Istioとは ◼ クラウドネイティブなアプリの運用を楽にしてくれるインフラ技術 ◼どんなことができるのか ◼ サービス間のつながりの可視化と制御 ◼ Zero Trust Networkを実現 Copyright 2019 FUJITSU LIMITED 14
16. Istioの機能 ◼Istioのコア機能 ◼ Traffic Management → ルーティングなどのトラフィック制御 ◼ Observability → 通信内容やトラフィック状況などの監視 ◼ Security → 認証やアクセス制限、暗号化 Copyright 2019 FUJITSU LIMITED 15 Istioのいいところ ・アプリケーションの変更なしで導入できる ・証明書の管理なしでセキュアな通信が可能
17. Istioのコンポーネント Copyright 2019 FUJITSU LIMITED 16 16 Control Plane Pilot Mixer Citadel Envoy アプリケーションX Pod Data Plane Service X Service Y https, gRPC, … TLS証明書 の管理 Policy Check Telemetry収集 Envoyの 設定の送信 Envoy アプリケーションY Pod
18. Istioの全体イメージ図 Copyright 2019 FUJITSU LIMITED 17 サービス A サービス B サービス C サービス D サービス E Istio Control Plane Envoy間通信の監視と制御 Envoy(Istio Data Plane) エッジプロキシ 各サービス間の通信を肩代わり
19. Istioでできること ◼クラウドネイティブへの道のり 1. 可視化(Observability) ◼ Istioのコア機能 2. 制御 ◼ Istio RBAC Copyright 2019 FUJITSU LIMITED 18
20. Istioによる可視化 ◼何を可視化できるのか ◼ サービスとサービスのつながり • どのサービスが通信しているか • どういう状態なのか(アクセス数、サービスの負荷など) Copyright 2019 FUJITSU LIMITED 19
21. Istioでの可視化の例(Prometheus) Copyright 2019 FUJITSU LIMITED 20
22. Istioでの可視化の例(Service Mesh) ◼kialiとは？ ◼ Service Meshの可視化プロジェクト ◼ URL: https://www.kiali.io/ Copyright 2019 FUJITSU LIMITED 21 可視化できるもの ・どのサービスがつがっているか ・サービスの状態はどうか
23. Istioでの可視化の例(分散トレーシング) Copyright 2019 FUJITSU LIMITED 22
24. 可視化のアイデア ◼可視化のアイデア ◼ IstioではすべてのサービスにEnvoyが付属 ◼ Envoyからデータを取得すれば現状がわかる ◼Envoyから情報を取得する Copyright 2019 FUJITSU LIMITED 23 Mixer Adapter Prometheus ・・・ App X Envoy App Y Envoy Zipkin
25. (余談)Mixer Adapterは自作できる ◼Mixer Adapterとは？ ◼ Mixerから収集した情報を独自のBackendコンポーネントに送信するための Adapter → 任意のサービスにIstioからの情報を送信できる ◼自作にあたって ◼ AdapterとBackendはgRPCで通信 ◼ まだ開発途中 Copyright 2019 FUJITSU LIMITED 24 参考: https://github.com/istio/istio/wiki/Mixer-Out-Of-Process-Adapter-Dev-Guide
26. Istioで制御 ◼制御の基本 ◼ Default: all deny ◼ 必要な人やサービスに必要な分だけ権限を与える Copyright 2019 FUJITSU LIMITED 25 ユーザA Webサーバ DB GW × 管理機関 証明書 基本はDeny Webサーバならok
27. Istioで制御(続き) ◼Istioにおける制御モデル Copyright 2019 FUJITSU LIMITED 26 Webサーバ DB Envoy 管理機関 Citadel 証明書 Envoyで認証認可 Kubernetes Cluster Envoy 証明書の管理 ・発行や失効処理など
28. Istio RBACの設定例(1) ◼Istio RBACをenableにする Copyright 2019 FUJITSU LIMITED 27 enable-istio-rbac.yaml apiVersion: "rbac.istio.io/v1alpha1" kind: ClusterRbacConfig metadata: name: default spec: mode: 'ON_WITH_EXCLUSION' exclusion: namespaces: ["istio-system","kube-system"] 名前はdefault固定 ・ON_WITH_EXCLUSIONか ON_WITH_INCLUSIONをおすすめ ・少なくともsystem関係の通信は 通るようにしたほうがいい
29. Istio RBACの設定例(2) ◼Serviceに対するRoleを作成 Copyright 2019 FUJITSU LIMITED 28 service-role.yaml apiVersion: "rbac.istio.io/v1alpha1" kind: ServiceRole metadata: name: myservicerole namespace: default spec: rules: - services: ["service.default.svc.cluster.local"] methods: ["GET", "POST"] 対象となるサービス ※公式にはexact matchだけでなく、 prefixやsuffixもサポートとあるがなぜか動かず・・・ *.svc.cluster.localは動く constraintsでさらに細かな情報も設定可能 (例) version1のみに適用など 参考: https://istio.io/docs/reference/config/authorization/istio.rbac.v1alpha1/
30. Istio RBACの設定例(3) ◼作成したRoleをKubernetesのService Accountに適用 Copyright 2019 FUJITSU LIMITED 29 service-role-binding.yaml apiVersion: "rbac.istio.io/v1alpha1" kind: ServiceRoleBinding metadata: name: myservicerolebinding namespace: default spec: subjects: - user: "cluster.local/ns/default/sa/myserviceaccount" # - user: "*" roleRef: kind: ServiceRole name: "myservicerole" Roleの適用先 Kubernetesの場合はサービスアカウント(正式名称) 外部公開サービスなどは"*"とする 参考: https://istio.io/docs/concepts/security/#authorization-policy
31. ちょっと裏側の話 ◼Istioはどうやって通信を制御しているのか ◼ Envoyのパラメータとして設定 Kubernetes CRDをapply後、Pilotが変更を検知し、それをEnvoyに伝える ◼Istio RBACのデバッグ方法 ◼ 対象PodのEnvoyのConfig情報を見る ◼ envoy.filters.http.rbacの部分を参照 Copyright 2019 FUJITSU LIMITED 30 参考: https://istio.io/docs/ops/security/debugging-authorization/ $ kubectl exec <pod-name> -c istio-proxy -- curl localhost:15000/config_dump -s > config_dump $ less condig_dump --pattern="envoy.filters.http.rbac" { "name": "envoy.filters.http.rbac", "config": { "rules": { "policies": { "myservicerole": { ・・・
32. デモ ◼デモの内容 ◼ kiali + Istioでどのように可視化できるのか ◼ Istio RBACで制御する方法 ◼デモアプリケーション ◼ GitHub: https://github.com/sh-miyoshi/istio-sample Copyright 2019 FUJITSU LIMITED 31
33. Istio導入における注意点 Copyright 2019 FUJITSU LIMITED 32
34. Istioのインストールについて ◼インストールは大変 ◼ コンポーネント多過ぎ ◼ オンプレだとネットワーク大変 → 最初はクラウドプロバイダーで検証がおすすめ ◼ GKEだとチェックを入れるだけでIstioを導入できる Copyright 2019 FUJITSU LIMITED 33
35. 本番導入にあたって ◼最初は小さく始めるべし ◼ Service Meshが必要なほど巨大な場所ではたいてい一筋縄ではいかない ◼ 限られた範囲のみ導入してテスト ↑これを繰り返す ◼Control Planeはしっかり守るべし ◼ Citadelが乗っ取られるとセキュリティは意味がなくなる ◼ Mixerが死ぬとログ・メトリクス情報がとれなくなる Copyright 2019 FUJITSU LIMITED 34
36. まとめ ◼クラウドネイティブな世界 = 適切な権限がある人ならいつでもどこからでもアクセスできる世界 = Zero Trust Network ◼セキュリティの考え方 ◼ まずは可視化 ◼ そのあと制御 ◼Istioでできること ◼ 可視化: コア機能 ◼ 制御: Istio RBAC Copyright 2019 FUJITSU LIMITED 35
38. 外部サービスとの通信について ◼Istioの通信制御 ◼ 本来はEnvoy同士で制御 ◼Envoyがないクラウド上のサービスと通信できるのか ◼ CRDで特別に許可を与える • 参考: https://istio.io/docs/tasks/traffic-management/egress/egress-control/#envoy- passthrough-to-external-services ※最新バージョンだとデフォルトでつながる ↑ 設定が難しくて大変なため Copyright 2019 FUJITSU LIMITED 37
39. マルチクラウド時代のIstio ◼クラスタ間通信 ◼ 基本的にIstioはKubernetesクラスタ内の通信を制御 ◼ 複数クラスタにまたがる場合は工夫が必要 • 一応マルチクラスタIstioはある URL: https://istio.io/docs/concepts/multicluster-deployments/ → SaaSとかのほうが安心できる Copyright 2019 FUJITSU LIMITED 38