Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Shunsuke Miyoshi

July 23, 2019
Tweet

More Decks by Shunsuke Miyoshi

Other Decks in Programming

Transcript

  1. 目次 ◼クラウドネイティブ時代のセキュリティ ◼ イメージ図 ◼ Zero Trust Network ◼Istio ◼

    Istioの概要 ◼ 可視化について ◼ アクセス制御の方法 ◼ デモ ◼まとめ Copyright 2019 FUJITSU LIMITED 1
  2. 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 何でも屋
  3. クラウドネイティブの定義 ◼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
  4. クラウドネイティブな世界のイメージ図 Copyright 2019 FUJITSU LIMITED 7 PC in 自宅 PC

    in 会社 認証サーバ Webサーバ DB GW GW クラウド × × Webはok 正統なユーザ && 権限あり? 抜け道はなし 証明書 証明書
  5. クラウドネイティブ世界のセキュリティ ◼Zero Trust Network ◼ 2010年に提唱された新しいセキュリティモデル ◼ コンセプト: 何も信じるな、必ず疑ってかかれ •

    社内ネットワークだからと言って本当に信頼できるのか? • 特権VPNでアクセスしてきたからといって本当に管理者か? ◼実現に必要なこと ◼ 誰と通信しているのか(通信相手の認証) ◼ 通信路の安全性(通信路の暗号化) Copyright 2019 FUJITSU LIMITED 8
  6. 事例紹介 ◼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
  7. 事例紹介 ◼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のような超巨大企業でもできている → 夢物語ではない
  8. 導入の手順 ◼Googleはどのようにしていったのか 1. 可視化 ◼ いつだれがどこにアクセスしてきたのか? → 現状を把握できていないのに縛るのはダメ ◼ セキュリティを上げるからUXは落ちますっていうのは最悪

    → デジタルツインのような環境で徹底的なシミュレーション 2. 制御 ◼ 完全に動作を把握できたら考えていくべし → 先に制御するとトラブル時の原因究明が非常に困難 Copyright 2019 FUJITSU LIMITED 11
  9. Istioの機能 ◼Istioのコア機能 ◼ Traffic Management → ルーティングなどのトラフィック制御 ◼ Observability →

    通信内容やトラフィック状況などの監視 ◼ Security → 認証やアクセス制限、暗号化 Copyright 2019 FUJITSU LIMITED 15 Istioのいいところ ・アプリケーションの変更なしで導入できる ・証明書の管理なしでセキュアな通信が可能
  10. 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
  11. Istioの全体イメージ図 Copyright 2019 FUJITSU LIMITED 17 サービス A サービス B

    サービス C サービス D サービス E Istio Control Plane Envoy間通信の監視と制御 Envoy(Istio Data Plane) エッジプロキシ 各サービス間の通信を肩代わり
  12. Istioでの可視化の例(Service Mesh) ◼kialiとは? ◼ Service Meshの可視化プロジェクト ◼ URL: https://www.kiali.io/ Copyright

    2019 FUJITSU LIMITED 21 可視化できるもの ・どのサービスがつがっているか ・サービスの状態はどうか
  13. (余談)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
  14. Istioで制御 ◼制御の基本 ◼ Default: all deny ◼ 必要な人やサービスに必要な分だけ権限を与える Copyright 2019

    FUJITSU LIMITED 25 ユーザA Webサーバ DB GW × 管理機関 証明書 基本はDeny Webサーバならok
  15. Istioで制御(続き) ◼Istioにおける制御モデル Copyright 2019 FUJITSU LIMITED 26 Webサーバ DB Envoy

    管理機関 Citadel 証明書 Envoyで認証認可 Kubernetes Cluster Envoy 証明書の管理 ・発行や失効処理など
  16. 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関係の通信は 通るようにしたほうがいい
  17. 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/
  18. 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
  19. ちょっと裏側の話 ◼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": { ・・・
  20. 本番導入にあたって ◼最初は小さく始めるべし ◼ Service Meshが必要なほど巨大な場所ではたいてい一筋縄ではいかない ◼ 限られた範囲のみ導入してテスト ↑これを繰り返す ◼Control Planeはしっかり守るべし

    ◼ Citadelが乗っ取られるとセキュリティは意味がなくなる ◼ Mixerが死ぬとログ・メトリクス情報がとれなくなる Copyright 2019 FUJITSU LIMITED 34
  21. まとめ ◼クラウドネイティブな世界 = 適切な権限がある人ならいつでもどこからでもアクセスできる世界 = Zero Trust Network ◼セキュリティの考え方 ◼

    まずは可視化 ◼ そのあと制御 ◼Istioでできること ◼ 可視化: コア機能 ◼ 制御: Istio RBAC Copyright 2019 FUJITSU LIMITED 35