主要 Service Mesh プロダクトの Identity 管理機能とアクセス制御機能の比較 / Comparison of Identity Management and Access Control Features of Major Service Mesh Products

CloudNative Days Tokyo 2020 で発表したスライドとなります。
https://event.cloudnativedays.jp/cndt2020/talks/27

発表時の録画は上記のリンクから参照ください。

Transcript

1. CloudNative Days Tokyo 2020 Ryuma Yoshida @ryysud 主要 Service Mesh プロダクトの Identity 管理機能とアクセス制御機能の⽐較
2. Ryuma Yoshida Software Engineer at Z Lab Corporation Twitter & GitHub: @ryysud
3. ゼットラボ株式会社 ▶ 2015年に設⽴されたヤフー株式会社100%⼦会社 ▶ ヤフーの⼤規模インフラを⽀える基盤開発と R&D を実施 + 代表的なプロダクトは Kubernetes as a Service（KaaS） ▶ これまでの取り組みは会社ホームページの News を参照 + https://zlab.co.jp ▶ R&D で得られたナレッジは Qiita で外部発信 + https://qiita.com/organizations/zlab
4. アジェンダ 1. Service Mesh プロダクトの調査に⾄った背景 2.⼤規模環境への Service Mesh 導⼊の懸念点 3. Service Mesh プロダクトの調査⽅針 4. 調査結果 5. まとめ 6. 今後の展望
5. Service Mesh プロダクトの調査に⾄った背景
6. 背景 ▶ ゼロトラストネットワークの実現に向けて R&D を⾏うチームが 2019年10⽉ に発⾜ + ゼットラボはゼロトラストネットワークの実現を⽬指している ▶ まずは Kubernetes を利⽤して構築されたマイクロサービス環境での実現を⽬指す + サービス ↔ サービスの通信を Secure にすることから着⼿ + サービス ↔ ユーザー/デバイス の通信については今後対応を進める ▶ マイクロサービス環境のセキュリティ課題とそれに対しての有効な解決策を調査 + NIST の SP 800-204 を中⼼に調査を実施 + 有効な解決策の1つとして Service Mesh の導⼊が挙げられた
8. マイクロサービス環境の脅威 ▶ サービスディスカバリへの攻撃 + レジストリに悪意のあるサービスを登録してそのサービスに誘導させる + レジストリデータを破壊してサービスディスカバリが機能しないようにする 正常なサービスディスカバリ レジストリの汚染により 悪意のあるサービスに誘導されてしまう
9. マイクロサービス環境の脅威 ▶ ネットワーク経由の攻撃 + マイクロサービス環境では各機能を個別にサービス化してネットワーク経由で機能を呼び出す + モノリシック環境では各機能がサービス内の関数で定義されていたので攻撃箇所が限定されていた + ネットワークで到達可能なエンドポイントの増加による攻撃箇所の拡⼤ + サービスへの不正アクセスのリスクが⾼まる モノリシック環境 マイクロサービス環境
10. マイクロサービス環境の脅威 ▶ ネットワーク経由の攻撃 + セキュリティ機能をバイパスされる攻撃 + セキュリティ機能が実装されていないサービスが狙われる モノリシック環境 443 マイクロサービス環境
11. ▶ カスケード障害のリスク + マイクロサービス環境では複数サービスが機能的に特定のサービスに依存していることが多い 複数サービスが依存している サービスで障害が発⽣ 依存関係にあった すべてのサービスで障害が発⽣ マイクロサービス環境の脅威
12. マイクロサービス環境のセキュリティ要件 ▶ 認証と認可（アクセス制御） + mTLS や JWT を利⽤してサービス間の相互認証 + サービス単位で定義されたポリシーを元にきめ細かなアクセス制御 ▶ サービスディスカバリ + 機密性、完全性、可⽤性を考慮して構築する ▶ サービス間の安全な通信 + TLS による通信の暗号化 ▶ セキュリティ監視 + インジェクション攻撃や不正アクセスの検知など ▶ 可⽤性の向上 + ロードバランシング、サーキットブレーカー、レート制限 + カナリアリリース、ブルーグリーンデプロイ
13. セキュリティ課題に対する有効な解決策 ▶ セキュリティ機能はマイクロサービス環境の共通機能として提供する + サービス毎に実装するのは開発者に負担がかかる + セキュリティレベルを統⼀できる ▶ 実装パターンの1つとして Service Mesh が有効な解決策であることがわかった + サービス毎に Sidecar Proxy を持たせて Sidecar Proxy 同⼠がメッシュネットワークを構成 + mTLS によるサービス間の相互認証と通信の暗号化 + Sidecar Proxy によるセキュリティ実装の共通化 + サービスの開発者がアプリケーションにセキュリティ機能を実装しなくてよい + Control Plane による Sidecar Proxy の⼀元管理 + 中央管理により統⼀されたポリシー運⽤が可能 ▶ マイクロサービス環境への Service Mesh の導⼊検討を開始
14. ⼤規模環境への Service Mesh 導⼊の懸念点
15. このセッションにおける⼤規模環境の定義 ▶ ⼤規模環境 = 様々なプラットフォームで多くのサービスが構成されている環境 + ⼤規模環境 != 単⼀の巨⼤な OpenStack クラスタで構成された環境 + ⼤規模環境 != 単⼀の巨⼤な Kubernetes クラスタで構成された環境 KaaS IaaS PaaS Service Service Service Service Service Service Service Service Service Service Service Service
16. 懸念点1: アクセス制御の分散管理 ▶ 様々なプラットフォームで構成される⼤規模環境への Service Mesh 導⼊にはアクセス制御（認可）の点で課題が残る + それぞれのプラットフォームでそれぞれの管理者が異なる仕組みでアクセス制御を⾏っている状態 KaaS IaaS 独⾃のアクセス制御 PaaS 独⾃のアクセス制御 独⾃のアクセス制御 Service Mesh Legacy services Microservices Microservices 運⽤ルールの統⼀ 運⽤ルールの統⼀ Policy Policy Policy Policy Policy Policy
17. 懸念点1: アクセス制御の分散管理 ▶ ⼤規模環境ではアクセス制御を中央管理するシステムを配置する + 各プラットフォームが中央管理システムと連携することで統⼀された仕組みでのアクセス制御が可能 KaaS IaaS PaaS Access Control System 統⼀された仕組みでのアクセス制御 Service Mesh Microservices Microservices Legacy services 連携 連携 連携 Policy Policy Policy Policy Policy Policy Policy
18. 懸念点2: サービス間の認証の仕組み ▶ アクセス制御を⾏うためには通信対象のサービスを識別する必要がある（認証） ▶ 認証のための識別⼦としてネットワークアドレスが信頼できない + KaaS や PaaS などモダンなプラットフォームで構築されたマイクロサービス環境ではサービスが頻繁にデプロイされる + サービスのスケーリングなどでアプリケーションが頻繁かつ動的に分散配置される + アプリケーションに割り当てられる IP アドレスが短い期間で変化する + ⼤規模環境では更に複雑度が増していく ▶ 認証⽅式の乱⽴ + OAuth/OIDC、TLS、ID/Password などサービス毎に異なる認証⽅式が使⽤される
19. ▶ アクセス制御を⾏うためには通信対象のサービスを識別する必要がある（認証） ▶ 認証のための識別⼦としてネットワークアドレスが信頼できない + KaaS や PaaS などモダンなプラットフォームで構築されたマイクロサービス環境ではサービスが頻繁にデプロイされる + サービスのスケーリングなどでアプリケーションが頻繁かつ動的に分散配置される + アプリケーションに割り当てられる IP アドレスが短い期間で変化する + ⼤規模環境では更に複雑度が増していく ▶ 認証⽅式の乱⽴ + OAuth/OIDC、TLS、ID/Password などサービス毎に異なる認証⽅式が使⽤される ネットワークアドレスではない識別⼦が必要 認証⽅式を統⼀したい 懸念点2: サービス間の認証の仕組み
20. ▶ アクセス制御を⾏うためには通信対象のサービスを識別する必要がある（認証） ▶ 認証のための識別⼦としてネットワークアドレスが信頼できない + KaaS や PaaS などモダンなプラットフォームで構築されたマイクロサービス環境ではサービスが頻繁にデプロイされる + サービスのスケーリングなどでアプリケーションが頻繁かつ動的に分散配置される + アプリケーションに割り当てられる IP アドレスが短い期間で変化する + ⼤規模環境では更に複雑度が増していく ▶ 認証⽅式の乱⽴ + OAuth/OIDC、TLS、ID/Password などサービス毎に異なる認証⽅式が使⽤される ▶ SPIFFE を採⽤する + SPIFFE がサポートされている Service Mesh を導⼊することで上記の課題を解決できる + ゼットラボは 2017 年から SPIFFE の動向を追いかけている ネットワークアドレスではない識別⼦が必要 認証⽅式を統⼀したい 懸念点2: サービス間の認証の仕組み
21. ▶ SPIFFE（Secure Production Identity Framework For Everyone） + サービス間認証のための標準仕様 ▶ SPIFFE で標準化されている仕様 + SPIFFE ID + サービスを識別するための URI 形式で構造化された⽂字列 + spiffe://<trust-domain>/<service-idenfifier> で構成される + 例: spiffe://production.example.com/payments/api + Trust Domain は組織、部⾨、実⾏環境などセキュリティの境界を描くためのもの + 同⼀ Trust Domain 配下のワークロード同⼠で相互認証が可能 + SVID（SPIFFE Verifiable Identity Document） + SPIFFE ID を証明するためのファイル + X.509証明書形式の X.509 SVID と JWT 形式の JWT SVID がサポートされている + X.509 SVID では SAN の URI に SPIFFE ID をセットする + Workload API + SVID と Trust Bundle（SVID を検証するための証明書や公開鍵）を取得するための API ▶ SPIFFE がサポートされている Service Mesh を導⼊する + 統⼀された識別⼦と統⼀された認証⽅式でのサービス間の認証が実現可能 懸念点2: サービス間の認証の仕組み
22. 懸念点2: サービス間の認証の仕組み Certificate: Data: Version: 3 (0x2) Serial Number: 4 (0x4) Signature Algorithm: ecdsa-with-SHA384 Issuer: C=US, O=SPIFFE ... Subject: C=US, O=SPIRE ... X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment, Key Agreement X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication ... X509v3 Subject Alternative Name: URI: spiffe://example.org/workload ... ▶ X.509 SVID の例（SAN の URI にサービスを識別するための SPIFFE ID をセットする）
23. KaaS IaaS PaaS Access Control System Service Mesh Service + Sidecar Proxy Service + Sidecar Proxy Service + Sidecar Proxy 連携 連携 連携 Workload API Workload API Workload API mTLS mTLS X.509 SVID SPIFFE ID で統⼀された識別⼦ X.509 SVID X.509 SVID spiffe://iaas.example.com/web spiffe://kaas.example.com/api spiffe://paas.example.com/db サービスへの X.509 SVID 配布 mTLS で統⼀された認証⽅式 SPIFFE ID SPIFFE ID SPIFFE ID SPIFFE ID を元に統⼀された仕組みでのアクセス制御 リクエストに含まれる SPIFFE ID と Policy を 元にアクセス制御 リクエストに含まれる SPIFFE ID と Policy を 元にアクセス制御 リクエストに含まれる SPIFFE ID と Policy を 元にアクセス制御 サービスへの X.509 SVID 配布 サービスへの X.509 SVID 配布 Policy Policy Policy Policy Policy Policy Policy
24. SPIFFE について詳しく知りたい⽅は SPIFFE Meetup Tokyo の資料を参照 Slide: https://speakerdeck.com/hiyosi/intro-spiffe Video: https://youtu.be/wrws1muD-zE
25. Service Mesh プロダクトの調査⽅針
26. 調査⽅針 ▶ Kubernetes をサポートする Service Mesh プロダクト + Kubernetes を利⽤して構築されたマイクロサービス環境が最初のターゲットなので必須な要件 ▶ Identity 管理機能とアクセス制御機能にフォーカスした調査を実施する + アクセス制御を中央管理するシステムとの連携に必要 ▶ Identity 管理機能における要件 + SPIFFE がサポートされている + 任意の SPIFFE ID が使⽤できる + 外部 PKI との連携が可能 ▶ アクセス制御機能における要件 + 外部システムとの連携が可能 まずはここへの Service Mesh 導⼊
27. 調査対象の Service Mesh プロダクト
28. 調査結果
29. 調査対象のバージョン: 1.7.0 https://github.com/istio/istio ※ 2020年9⽉8⽇時点での最新バージョン
30. Identity 管理機能 ▶ Identity 管理機能の仕組み + Control Plane に CA を設定できる + CA は Control Plane で⾃動⽣成された CA を使⽤するか、任意の CA を使⽤するか選択可能 + Control Plane で発⾏した SPIFFE に準拠した X.509 証明書（X.509 SVID）を Istio Agent が SDS 経由で Envoy に配布する + SPIFFE ID フォーマット: spiffe://<trust-domain>/ns/<namespace>/sa/<service-account> + SPIFFE ID は Service Account 単位で⽣成される + 任意の SPIFFE ID 設定はサポートされていない + X.509 証明書は定期的にローテーションされる + PeerAuthentication リソースでサービス間で mTLS させるかどうかを設定できる ▶ ◦ 任意の SPIFFE ID を使⽤できる + Sidecar Proxy のマニフェストテンプレートや Pod の Annotation などで Envoy の設定を変更できる + 任意の SPIFFE ID 設定はサポートされていないが Identity 管理を別の仕組みに変えることで実現可能 + DestinationRule リソースで宛先に応じて mTLS に利⽤する CA 証明書、X.509 証明書、秘密鍵を設定できる + サーバー証明書は Istio で発⾏されたもの、クライアント証明書は別の仕組みで発⾏されたものを使⽤できる ▶ ◦ 外部 PKI と連携可能 + ルート CA 証明書と中間 CA 証明書の両⽅を設定できる + 中間 CA 証明書を設定する場合にはルート CA 証明書や証明書チェーンを Secret に配置する対応が必要
31. istio-init Envoy Istio Agent istio-proxy App Pod Init Container 3. Pod の全ての送受信トラフィックが istio-proxy を通るように iptables を制御する 6. istiod 内部に設定された CA の秘密鍵を使⽤して X.509 証明書を発⾏ 2. Pod の Spec を書き換えて istio-init と istio-proxy を追加 Data Plane Control Plane 1. Pod が デプロイされる App istio-proxy Pod App Pod mTLS 9. Ready になる ※ X.509 証明書は定期的にローテーション デフォルトだと24時間毎のローテーション ※ イメージしやすいように 処理をナンバリングしているが 同時に処理が進むものもある Container 4. SDS 経由で X.509 証明書と 秘密鍵をリクエスト istio-proxy istiod 5. 秘密鍵と CSR を ⽣成して CSR を送信 8. SDS 経由で X.509 証明書と 秘密鍵をレスポンス 7. X.509 証明書を送信
32. istiod App istio-proxy Pod App istio-proxy Pod mTLS AuthorizationPolicy リソースを作成する AuthorizationPolicy リソースを Envoy の RBAC Filter に変換する LDS 経由で istio-proxy に設定を反映する アクセス制御機能 ▶ アクセス制御機能の仕組み + AuthorizationPolicy リソースでサービス間のアクセス制御が可能 + 詳細な仕様が気になる⽅は Qiita の "Istio での Authorization Policy を利⽤したワークロードのアクセス制御" を参照 + アクセス制御を外部システムと連携させるための機能はサポートされていない + Mixer Adapter も検討したが Deprecated なので⾒送り + Control Plane が AuthorizationPolicy リソースを Envoy の RBAC Filter に変換して LDS 経由で Envoy に適⽤する + アクセス制御はサービスの SPIFFE ID をベースに実⾏される ▶ ◦ 外部システムと連携可能 + Sidecar Proxy のマニフェストテンプレートなどで Envoy の設定を変更できる + アクセス制御を別の仕組みに変えることで実現可能 + 外部システムのポリシーを AuthorizationPolicy リソースに変換するアプローチもある + ポリシーをカスタムリソースとして Kubernetes クラスタに同期して変換
33. 調査対象のバージョン: 0.7.1 https://github.com/kumahq/kuma ※ 2020年9⽉8⽇時点での最新バージョン
34. Identity 管理機能 Mesh Pod Pod Pod DataPlane DataPlane DataPlane リソースの論理関係 Pod の Annotation で紐付け ⼦リソース ▶ Identity 管理機能の仕組み + Mesh リソースで Pod を束ねて Service Mesh を構成する + Pod の Annotation で Mesh リソースを指定することで紐付け + Envoy の制御⽤途で Pod の⼦リソースとして Service リソース情報が定義された DataPlane リソースを作成 + Mesh リソース毎に CA が定義できる + CA は Control Plane で⾃動⽣成された CA を使⽤するか、任意の CA を使⽤するか選択可能 + 単⼀クラスタ内に複数の Mesh リソース定義が可能で認証範囲を柔軟に分けられるのでマルチテナント環境でも使いやすい + Control Plane で発⾏した SPIFFE に準拠した X.509 証明書（X.509 SVID）を SDS 経由で Envoy に配布する + SPIFFE ID フォーマット: spiffe://<mesh-name>/<service-name>_<namespace-name>_svc_<service-port> + SPIFFE ID は Pod に対応する Service リソース単位で⽣成される + 任意の SPIFFE ID 設定はサポートされていない + X.509 証明書は定期的にローテーションされる ▶ ◦ 任意の SPIFFE ID を使⽤できる + ProxyTemplate リソースで Envoy の設定を変更できる + Identity 管理を別の仕組みに変えることで実現可能 ▶ △ 外部 PKI と連携可能 + ルート CA 証明書は設定できるが中間 CA 証明書は設定できない + https://github.com/kumahq/kuma/issues/759 CA SVID SVID SVID
35. kuma-init App kuma-cp Init Container Data Plane Control Plane kuma-dp（Envoy） Container Pod DataPlane 1. Pod が デプロイされる 2. Pod の Spec を書き換えて kuma-init と kuma-dp を追加 3. Pod の全ての送受信トラフィックが kuma-dp を通るように iptables を制御する Mesh 7. Annotation を元に Pod に対応する Mesh リソースを参照して CA 証明書と秘密鍵を取得 8. kuma-dp ⽤の鍵ペアを⽣成して CA の秘密鍵で署名して X.509 証明書を発⾏ （SPIFFE ID は Service リソース情報を元に⽣成） 9. SDS 経由で CA 証明書、 X.509 証明書、秘密鍵を配布 5. DataPlane リソースから Service リソース情報を抽出 App kuma-dp Pod App kuma-dp Pod mTLS 10. Ready になる ※ X.509 証明書は定期的にローテーション 有効期限が 1/5 になるとローテーションされる デフォルトの有効期限が30⽇なので24⽇毎にローテーション ※ イメージしやすいように 処理をナンバリングしているが 同時に処理が進むものもある 6. Service リソース情報を元に Envoy 設定を⽣成して LDS/CDS 経由で設定を適⽤ 4. Pod の⼦リソースとして Service リソース情報が定義された DataPlane リソース を作成する ※ kuma-dp は Envoy のラッパー ※ kuma-init の 実体は istio-init
36. kuma-cp App kuma-dp Pod App kuma-dp Pod mTLS TrafficPermission リソースを作成する TrafficPermission リソースを Envoy の RBAC Filter に変換する LDS 経由で Envoy に設定を反映する アクセス制御機能 ▶ アクセス制御機能の仕組み + TrafficPermission リソースを定義することでサービス間のアクセス制御が可能 + TrafficPermission リソースの sources と destinations でアクセス制御対象のサービスを指定する + アクセス制御を外部システムと連携させるための機能はサポートされていない + Control Plane が TrafficPermission リソースを Envoy の RBAC Filter に変換して LDS 経由で Envoy に適⽤する + アクセス制御はサービスの SPIFFE ID をベースに実⾏される ▶ ◦ 外部システムと連携可能 + ProxyTemplate リソースで Envoy の設定を変更できる + アクセス制御を別の仕組みに変えることで実現可能 + 外部システムのポリシーを TrafficPermission リソースに変換するアプローチもある + ポリシーをカスタムリソースとして Kubernetes クラスタに同期して変換
37. 調査対象のバージョン: stable-2.8.1 https://github.com/linkerd/linkerd2 ※ 2020年9⽉8⽇時点での Stable 版の最新バージョン
38. Identity 管理機能 ▶ Identity 管理機能の仕組み + Control Plane に CA を定義できる + CA は Control Plane で⾃動⽣成された CA を使⽤するか、任意の CA を使⽤するか選択可能 + Sidecar Proxy が起動時に秘密鍵と CSR を⽣成して Control Plane の CA コンポーネントから X.509 証明書を発⾏してもらう + X.509 証明書は Service Account 単位になっていて SPIFFE はサポートされていない + CN と SAN の DNS にサービスの Identity が含まれる + フォーマット: <sa>.<ns>.serviceaccount.identity.<linkerd-controlplane-ns>.<trust-domain> + 任意の Identity 設定はサポートされていない + X.509 証明書は定期的にローテーションされる ▶ ✕ SPIFFE はサポートされておらず任意の SPIFFE ID は使⽤できない + Sidecar Proxy として独⾃の Rust 製プロキシ linkerd2-proxy が採⽤されている + 設定変更で Identity 管理を別の仕組みに変えることもできない + Sidecar Proxy の置き換えはサポートされていない + linkerd2-proxy を Envoy に置き換えるアプローチも不可能 ▶ ◦ 外部 PKI と連携可能 + ルート CA 証明書と中間 CA 証明書の両⽅を設定できる + 中間 CA 証明書を設定する場合にはルート CA 証明書の設定が必要
39. Proxy Injector linkerd-init linkerd2-proxy-identity linkerd2-proxy linkerd-proxy App Pod Identity Init Container 3. Pod の全ての送受信トラフィックが linkerd-proxy を通るように iptables を制御する 6. CSR と SAトークンを送信 9. X.509 証明書を送信 Other component 2. Pod の Spec を書き換えて linkerd-init と linkerd-proxy を追加 Data Plane Control Plane Other component Other component 1. Pod が デプロイされる 7. TokenReview API で SA トークンを検証後に CSR に含まれる Identity とマッチするか確認 ※ linkerd2-proxy は 軽量で⾼速な Proxy を 使⽤したいモチベー ションから Rust で書か れている 10. Ready になる ※ X.509 証明書は定期的にローテーション デフォルトだと24時間毎のローテーション ※ イメージしやすいように 処理をナンバリングしているが 同時に処理が進むものもある Container 4. 秘密鍵と CSR を⽣成する ※ CSR には SA 単位の Identity を含める 5. 秘密鍵と CSR を Shared Volume 経由で渡す 8. Control Plane 内部に設定された CA の秘密鍵を使⽤して X.509 証明書を発⾏ App linkerd-proxy Pod App linkerd-proxy Pod mTLS
40. アクセス制御機能 ▶ アクセス制御機能の仕組み + アクセス制御機能はサポートされていない + 将来的には実装される可能性あり + https://github.com/linkerd/linkerd2/issues/3342 ▶ ✕ 外部システムと連携不可能 + Sidecar Proxy の変更もサポートされていない + linkerd2-proxy を Envoy に置き換えてアクセス制御を⾏うこともできない
41. 調査対象のバージョン: 1.8.3 https://github.com/hashicorp/consul ※ 2020年9⽉8⽇時点での最新バージョン
42. Identity 管理機能 ▶ Consul では Connect という Service Mesh を構築する機能がサポートされている + Service Mesh 内では Consul の サービスディスカバリ機能（サービスカタログ、ヘルスチェック、ロードバランシング）を利⽤ ▶ Identity 管理機能の仕組み + Consul Server（Control Plane）に CA を定義できる + CA は Consul Server で⾃動⽣成された CA を使⽤するか、任意の CA を使⽤するか選択可能 + Vault の PKI Secret Engine を使⽤することもできる + Consul Server で発⾏した SPIFFE に準拠した X.509 証明書（X.509 SVID）を Consul Agent が LDS 経由で Envoy に配布する + SPIFFE ID フォーマット: spiffe://<cluster-id>.<consul-domain>/ns/<ns-name>/dc/<dc-name>/svc/<consul-svc-name> + SPIFFE ID は Pod に対応する Consul サービス単位で⽣成される + 任意の SPIFFE ID 設定はサポートされていない + X.509 証明書は定期的にローテーションされる ▶ ◦ 任意の SPIFFE ID を使⽤できる + Proxy Defaults 機能などで Envoy の設定を変更できる + 任意の SPIFFE ID 設定はサポートされていないが Identity 管理を別の仕組みに変えることで実現可能 ▶ △ 外部 PKI と連携可能 + ルート CA 証明書と中間 CA 証明書の両⽅を設定できる + 中間 CA 証明書を設定する場合には Envoy にルート CA 証明書を配置する対応が必要
43. Lifecycle Sidecar Envoy App Pod Init Container Consul Server 2. Pod の Spec を書き換えて Injector Init、Lifecycle Sidecar、 Envoy を追加 Data Plane Control Plane 1. Pod が デプロイされる App Envoy Pod App Pod mTLS Envoy ※ X.509 証明書は定期的にローテーション デフォルトだと72時間毎のローテーション ※ Lifecycle Sidecar が定期的に App と Envoy を Consul サービスとして再登録をする Container 3. App と Envoy を Consul サービスとして 登録後に Envoy の設定ファイルを⽣成 9. Ready になる Inject Init Lifecycle Sidecar Lifecycle Sidecar ※ イメージしやすいように 処理をナンバリングしているが 同時に処理が進むものもある 4. Envoy ⽤の秘密鍵と CSR を⽣成する （SPIFFE ID は Pod に対応する Consul サービスを元に⽣成） Consul Agent Connect Injector 5. CSR を送信 8. Envoy 設定を⽣成して LDS/CDS 経由で設定を適⽤ （CA 証明書、X.509 証明書、 秘密鍵は SDS ではなく LDS 経由 でインライン形式で配布） 6. Consul Server 内部に 設定された CA の秘密鍵を使⽤して X.509 証明書を発⾏ 7. X.509 証明書を送信
44. Consul Agent App Envoy Pod App Envoy Pod mTLS Intentions 情報の同期 mTLS が完了した後にアクセス権限があるか確認 アクセス制御機能 Consul Server Intentions を定義 ▶ アクセス制御機能の仕組み + Intentions という仕組みでサービス間のアクセス制御が可能 + 特定の Consul サービス間の通信制御を指定した Intention を Consul Server に定義する + Intentions の管理は API、CLI、WebUI から⾏える + アクセス制御を外部システムと連携させるための機能はサポートされていない + Envoy の External Authorization Server として設定された Consul Agent が Intentions の定義を元にアクセス制御を⾏う + Listener への External Authorization の設定は Pod が Ready になる時点で適⽤されている + アクセス制御はサービスの SPIFFE ID をベースに実⾏される ▶ ◦ 外部システムと連携可能 + Proxy Defaults 機能などで Envoy の設定を変更できる + アクセス制御を別の仕組みに変えることで実現可能 + 外部システムのポリシーを Intention に変換するアプローチもある + ポリシーをカスタムリソースとして Kubernetes クラスタに同期して変換
45. 調査対象のバージョン: 0.2.0 https://github.com/networkservicemesh/networkservicemesh ※ 2020年9⽉8⽇時点での最新バージョン
46. Identity 管理機能とアクセス制御機能は存在しない ▶ Network Service Mesh は L2/L3 レイヤーの Service Mesh を構築するためのもの + Network Service Mesh を利⽤することで Pod に任意の L2/L3 ネットワークのインターフェースを追加できる ▶ これまで調査した⼀般的な Service Mesh プロダクトとは⽬的が異なる + サービス同⼠が Sidecar Proxy を介して L4 で mTLS をしてアクセス制御を⾏うものではない + 他の Service Mesh プロダクトと組み合わせて使⽤することが想定されている 引⽤: https://www.cisco.com/c/dam/m/en_us/ network-intelligence/service-provider/digital- transformation/knowledge-network-webinars/pdfs/ 1128_TECHAD_CKN_PDF.pdf
47. ▶ Network Service Mesh のコンポーネントが攻撃されると危険 + ネットワークトラフィックの変更や傍聴のリスク ▶ コンポーネントの認証に SPIFFE が利⽤されている + SPIFFE の参照実装である SPIRE を利⽤して各コンポーネントに X.509 SVID を発⾏ + https://github.com/spiffe/spire + 各コンポーネントは X.509 SVID を使⽤して gRPC エンドポイントを公開 ▶ 具体的に SPIFFE がどのように活⽤されているかを知りたい⽅は以下を参照 + https://youtu.be/fxtG1wuLSDw?t=1050 + https://youtu.be/QfYS79SptyQ 内部で SPIFFE が利⽤されていた
48. プロダクト バージョン Identity 管理機能 アクセス制御機能 SPIFFE サポート 任意の SPIFFE ID 使⽤ 外部 PKI 連携 外部システム連携 Istio 1.7.0 ◦ ◦ ◦ ◦ Kuma 0.7.1 ◦ ◦ △ ◦ Linkerd stable-2.8.1 ✕ ✕ ◦ - Consul 1.8.3 ◦ ◦ △ ◦ Network Service Mesh 0.2.0 - - - - ▶ 調査結果から Istio を採⽤して PoC を実施することを決めた 調査結果
49. PoC で採⽤する Identity 連携のアーキテクチャ (仮) istio-init Identity Agent (Init mode) Init Container Identity Agent (Refresh mode) App Envoy Istio Agent istio-proxy Container Pod istiod Identity Server X.509 SVID (独⾃仕様) X.509 SVID (Istio 仕様) istio-proxy Identity Agent (Refresh mode) X.509 SVID App X.509 SVID istio-proxy Identity Agent (Refresh mode) X.509 SVID App X.509 SVID Pod Pod mTLS PeerAuthentication リソースと DestinationRule リソースを定義して サーバー証明書は Istio 仕様の X.509 SVID を クライアント証明書は独⾃仕様の X.509 SVID で mTLS させる ※ クライアント証明書は mTLS で利⽤した後はアクセス制御で利⽤ ※ X.509 証明書は定期的にローテーション Ready アクセス制御を中央管理するシステムで利⽤できる SPIFFE ID を持つ X.509 証明書を発⾏する spiffe://internal.zlab.co.jp/ns/<ns>/sa/<sa> spiffe://internal.zlab.co.jp/<original-identifier> SPIFFE ID SPIFFE ID Access Control System 同じルート CA を持つ PKI ツリーを構成する ※ ⻘⾊は独⾃のコンポーネント Pod の Spec を書き換えて istio-init と istio-proxy に加えて Identity Agent を追加するようにする 秘密鍵と CSR を⽣成する CSR を送信する X.509 証明書 を送信する
50. istiod Access Control System istio-proxy X.509 SVID App X.509 SVID istio-proxy X.509 SVID App X.509 SVID Pod Pod mTLS Policy Policy Syncer Policy Controller アクセス制御を中央管理するシステムで定義されたポリシーを カスタムリソースとして Kubernetes クラスタに同期する ※ ポリシー同期は定期実⾏ AuthorizationPolicy Policy 同期されたカスタムリソースを AuthorizationPolicy リソースに変換して Istio に独⾃ポリシーを適⽤する Istio 内で稼働するサービス同⼠の通信で 独⾃ポリシーに基づいたアクセス制御が⾏われる ※ 独⾃仕様の X.509 SVID に含まれる SPIFFE ID を利⽤ ※ ⻘⾊は独⾃のコンポーネント PoC で採⽤するアクセス制御連携のアーキテクチャ (仮)
51. まとめ
52. まとめ ▶ ゼットラボはゼロトラストネットワークの実現を⽬指している + Kubernetes を利⽤して構築されたマイクロサービス環境への Service Mesh の導⼊検討を開始 + まずはサービス ↔ サービスの通信を Secure にすることから着⼿ ▶ ⼤規模環境への Service Mesh 導⼊を考慮して要件を洗い出した + SPIFFE を利⽤して統⼀された識別⼦と認証⽅式でのサービス間認証が⾏えること + アクセス制御を中央管理するシステムと連携できること ▶ Service Mesh プロダクトの調査を実施 + Identity 管理機能とアクセス制御機能にフォーカスして調査 + Istio を採⽤して PoC を実施することに決定 まずはここへの Service Mesh 導⼊
53. 参考資料 ▶ NIST SP 800-204 - Security Strategies for Microservices-based Application Systems + https://csrc.nist.gov/publications/detail/sp/800-204/final ▶ NIST SP 800-204a - Building Secure Microservices-based Applications Using Service-Mesh Architecture + https://csrc.nist.gov/publications/detail/sp/800-204a/final ▶ Microservices Security in Action + https://www.manning.com/books/microservices-security-in-action ▶ The Difference Between API Gateways and Service Mesh + https://www.cncf.io/blog/2020/03/06/the-difference-between-api-gateways-and-service-mesh/ ▶ Service Mesh Comparison + https://servicemesh.es ▶ Get to Know Service Mesh ‒ Video Series + https://www.solo.io/resource/hoot-get-to-know-service-mesh-series
54. 今後の展望
55. 今後の展望 ▶ マイクロサービス環境への Service Mesh の導⼊検討のために Istio で PoC を実施 + ゼロトラストネットワークの実現に向けてまずは サービス ↔ サービスの通信を Secure にする ▶ モダンなプラットフォームに乗り切らないレガシーなサービスの認証を SPIFFE で改善 + IaaS への SPIFFE 導⼊ + SPIRE を利⽤した OpenStack インスタンス上で稼働するサービスへの X.509 SVID 配布 + OpenStack インスタンスを厳密に検証する仕組みを 設計/開発 して SPIFFE コミュニティに共有済み + https://github.com/zlabjp/spire-openstack-plugin + https://docs.google.com/document/d/1HkK3Q74yYiqckBMI-h9FrZdlWEkrY5R4uHbXRqSRlW8/edit ▶ サービス ↔ ユーザー/デバイス の通信も Secure にしていく + 外部からのリクエストを受けるゼロトラストなプロキシの調査から着⼿ + 安全な認証とコンテキストベースでのアクセス制御 + キーワード：BeyondCorp、Identity Aware Proxy、Access Proxy ▶ SPIFFE プロジェクトへの継続的なコントリビュート 進⾏中 進⾏中 現在はこの部分の実現に向けた作業を進めている
56. WE ARE HIRING! https://zlab.co.jp
57. Thank you!