Challenging Multiple SPIRE Server

SPIFEF Meetup Tokyo #2 での発表資料です。

Transcript

1. SPIFFE Meetup Tokyo #2 Tomoya Usami <tousami@zlab.co.jp> @hiyosi Challenging Multiple SPIRE Server
2. http://bit.ly/2nwnZNf
3. Tomoya Usami / @hiyosi ▶ ISPにてシステム運⽤基盤の開発、IDaaSサービスの ⽴ち上げなどに関わった後、2016年9⽉にゼットラボ 株式会社に⼊社。 ▶ 現在はインフラ基盤の研究開発を⾏っている。 ▶ Zero Trust Networkや認証技術に興味がある
4. Tomoya Usami / @hiyosi ▶ Intro SPIFFE + https://speakerdeck.com/hiyosi/intro-spiffe ▶ Challenging Secure Introduction With SPIFFE + https://speakerdeck.com/hiyosi/challenging- secure-introduction-with-spiffe
5. ゼットラボ株式会社 ▶ 2015年に設⽴されたヤフー株式会社100%⼦会社 ▶ インフラ基盤技術の調査・研究開発 ▶ https://zlab.co.jp/ ▶ https://qiita.com/organizations/zlab
6. モチベーション
7. モチベーション ▶ SPIREを本番導⼊する想定でシステム設計をまじめに検討 + スケーラビリティとアベイラビリティの両⽅が必要 ▶ 複数台で構成できることは知っていたが、システム全体としてどのように構成す るのがよいかイマイチまとまっていなかった + ⼿を動かして検証し、ちゃんと理解する必要があった
8. SPIRE Serverダウン時の挙動
9. Node Attestation成功後、AgentはServerとの接続を維持して情報を更新する SPIREのコンポーネントと役割 SPIRE Server SPIRE Agent Workload Node SVIDの更新、 Nodeに紐づくWorkload情報の更新
 (SVIDs, Selectors) SVID Workload Attestation Node Node Attestation (1) (2) (3) (4) (5) (6)
10. Agentが起動できないため、Workloadに関する情報が取得できない Node Attestation前に接続断 SPIRE Server SPIRE Agent Workload Node SVIDの更新、 Nodeに紐づくWorkload情報の更新
 (SVIDs, Selectors ) Workload Attestation Node TLS
11. Node Attestationに失敗したAgentは正常に起動できずに停⽌する Node Attest前に断したときのAgent SPIRE Server SPIRE Agent Agentは起動できずにそのまま停⽌ ※systemdなどによりリトライさせることはできる TLS
12. Agentは起動しているが既存WorkloadがSVIDをローテーションできない Node Attestation成功後に接続断 SPIRE Server SPIRE Agent Workload SVID Workload Attestation Node 古いSVIDやSelector情報しか 持っていない Node SVIDの更新、 Nodeに紐づくWorkload情報の更新
 (SVIDs, Selectors ) mTLS
13. Agentは起動しているが新規WorkloadをAttestationできない Node Attestation成功後に接続断 SPIRE Server SPIRE Agent Workload Workload Attestation Node 知らないWorkload Node SVIDの更新、 Nodeに紐づくWorkload情報の更新
 (SVIDs, Selectors ) mTLS Workloadの登録
14. Agentは起動しており、Workload 情報更新のための接続をひたすら繰り返す Node Attest後に断したときのAgent SPIRE Server SPIRE Agent Agentは再接続を繰り返す mTLS
15. Serverの障害発⽣時もAgentは他のServerへ接続できる構成に Agentが正しく動作するために複数のServerが必要 SPIRE Server SPIRE Server SPIRE Agent SPIRE Server
16. SPIREの可⽤性向上
17. ただ接続できればいいだけなく、いくつか考慮する点がある 別のServerに接続して継続するには SPIRE Server SPIRE Agent SPIRE Server
18. Agentが正しく別のServerに接続できるには ▶ Agentの情報(Node Attestationの情報)がServer間で共有されている必要がある + 信頼済み情報がないと再接続時に不明なAgentとして接続がエラーになる ▶ Agent/Serverはお互いのSVID(証明書チェーン)が正しく検証できる必要がある + Agent - ServerはTLS/mTLSで認証しているのでどのような接続の組み合わせ でも正しく証明書が検証できて認証できなければならない
19. Attestation情報の共有
20. Node Attest後に新規Serverに接続した際に不正なAgentと⾒なされる。 Attestationエントリが存在しないため信頼されない Attestationエントリを共有していない場合 SPIRE Server SPIRE Agent SPIRE Server 知らないAgent
21. 別のServerでAttestation済みで情報も共有されているため、意識せずに接続できる Attestationエントリを共有している場合 SPIRE Server SPIRE Agent SPIRE Server Datastore 信頼済みのAgent
22. 各証明書を正しく検証する
23. Agent - Server 間の通信 ▶ Node Attestation時の通信 + Agent - Server 間は単なるTLS通信 + Agentはサーバ証明書を検証する ▶ Node Attestation後のSVID更新、Workload情報の同期のための通信 + Agent - Server はmTLS通信 + AgentとServerはお互いの証明書を検証する + ServerはAgentを識別(ノードを識別)できるので、ノードに紐づいたワーク ロード情報を返す
24. SPIRE ServerによるSVIDの発⾏ Server Upstream CA Disk/Memory Datastore Agent SVID Key Pair Attestation情報 , Bundles, etc 既存PKIに合流する場合 CA API Server SVID TLS/mTLS CA Cert
25. Upstream CAが存在する場合の 各証明書の検証
26. Serverの証明書を検証する(Node Attest前) SPIRE Server SPIRE Agent Server SVID agent.conf 
 agent {
 … trust_bundle_path=server_upstream.pem
 … } Sever SVIDはAgentの設定ファイルで指定した証明書で検証する
27. Serverの証明書を検証する (Node Attest前) agent.conf 
 agent {
 … trust_bundle_path=server_upstream.pem
 … } Server
 CA Upstream CA Server Cert Server
 CA Upstream CAが存在する場合はUpstream CAの証明書(バンドル) を配布することでAgentはそれを使ってServer SVIDを検証できる issuer=Upstream CA issuer=Server CA Server Cert
28. Serverの証明書を検証する (Node Attest後) SPIRE Server SPIRE Agent agent_svid.der
 - Agent Cert
 - Server CA Cert(ICA) bundle.der - Upstream Bundle Node Attestationの結果として AgentのSVIDを発⾏、 他のSVID検証⽤のBundleが⼿に⼊る Upstream CA ServerCA Data Bundles server_svid
 - Server Cert
 - Server CA Cert ※ ICA=Intermediate Certificate Authority
29. Agentの証明書を検証する (Node Attest後) SPIRE Server SPIRE Agent agent_svid.der
 - Agent Cert
 - Server CA Cert(ICA) bundle.der - Upstream Bundle Upstream CA ServerCA Data 中間CA証明書と連結されたAgentSVIDの証明書チェーンを Upstream CAの証明書で検証する Bundles server_svid
 - Server Cert
 - Server CA Cert ※ ICA=Intermediate Certificate Authority
30. PKI ツリー Server
 CA(ICA) Upstream CA Server Cert Server
 CA(ICA) Server Cert Agent Cert Agent Cert サーバが提⽰する内容 クライアントが提⽰する内容
31. Upstream CAを使わない場合の 各証明書の検証
32. Serverの証明書を検証する (Node Attest前) agent.conf 
 agent {
 … trust_bundle_path=server_upstream.pem
 … } Server
 CA Server
 Cert Server Cert Server
 CA DatastoreにそれぞれのRoot CA証明書が保管されて いる(master)ので、そのデータをAgentに配布。
 ⽴ち上げてからじゃないと配布できない課題がある。 (※後ほど補⾜) Upstream CAが存在しない場合は
 Server CAがRoot CAになる Data
33. Serverの証明書を検証する (Node Attest後) SPIRE Server SPIRE Agent agent_svid.der
 - Agent Cert bundle.der - Server CA Certs Node Attestationの結果として AgentのSVIDを発⾏、および 他のSVID検証⽤のBundleが⼿に⼊る ServerCA Data Bundles server_svid
 - Server Cert ※ ICA=Intermediate Certificate Authority
34. Agentの証明書を検証する (Node Attest後) SPIRE Server SPIRE Agent agent_svid.der
 - Agent Cert bundle.der - Server CA Certs ServerCA Data AgentSVIDをBundleとして保管されている Root CA証明書群で検証する Bundles server_svid
 - Server Cert ※ ICA=Intermediate Certificate Authority
35. PKI ツリー Server
 CA(Root) Server Cert Server
 CA(Root) Server Cert Agent Cert Agent Cert サーバが提⽰する内容 クライアントが提⽰する内容
36. 注意点 (No UpstreamCA) ▶ Server CAがRoot CAとなるが、そのための鍵ペアはServerのローカルで管理され ている + Key Manager は Disk plugin を使い、data_dirの永続化が必要 + SPIRE Serverのノードが再⽣成されるとRoot CA証明書が変わってしまい、 Agentが接続できなくなる ▶ Server SVID検証のBootstrap問題を解消しつつ、SPIRE ServerはTrust Domain内 でRoot CAとして振るまうような設定(upstream_bundle=false)もできるが、問 題が確認されたので将来的には無くなりそうな流れ + spiffe/spire/issues/1095
37. upstream_bundle=falseの設定とは ▶ Upstream CAは使うがあくまでBootstrap時のみ ▶ ⾃⾝は中間CAの⽴ち位置であるが、Upstream Bundleに上位のBundleを含めな いことで、Trust Domain内では上位のCAとは切り離して運⽤する ▶ これはAgentのBootstrap問題を回避するためにダミーのUpstream CA証明書を 使ったワークアラウンドの際に⽣み出されたものだと思われる(ダミーCAのツ リーに組み込まれたくない) ▶ 将来的にBootstrap問題を解消して廃⽌の流れなのでテスト以外では使わない
38. Server証明書の検証 (upstream_bundle=false) agent.conf 
 agent {
 … trust_bundle_path=server_upstream.pem
 … } Server
 CA Upstream CA Server Cert Server
 CA Bootstrap時はUpstreamCAのBundleを使ってServer SVIDの検証 issuer=Upstream CA issuer=Server CA Server Cert
39. Server証明書の検証 (upstream_bundle=false) SPIRE Server SPIRE Agent agent_svid.der
 - Agent Cert bundle.der - Server CA Certs Agentに渡すBundleにはupstreamのbundleを含めない Upstream CA ServerCA Data Bundles server_svid
 - Server Cert
 - Server CA Cert
40. PKIツリーの設計が構成を決める上で 重要なポイントになる
41. 関連するコンポーネントの整理 ▶ Datastore + NodeのAttestation情報やWorkloadの情報(Selectorなど), Trust Bundleを保存 ▶ Key Manager + SPIRE ServerがSVID(証明書orJWT)を発⾏するための鍵ペアを管理 ▶ Upstream CA + SPIREが発⾏する証明書を既存のツリーに組み込むのかどうか
42. https://spiffe.io/spire/overview/
43. バックエンドの選択 ▶ Datastore + 複数のサーバ間で共有が必要 + MySQL, PostgreSQL + Kubernetes pluginも(summerwind/spire-plugin-datastore-k8s) ▶ Key Manager + Upstream CA使わない場合はdiskプラグインを使って永続ボリュームに書き出す ▶ Upstream CA + Amazon KMSやStaticな鍵ペア、HashiCorp Vaultなど選択できる
44. 前回の訂正 ▶ Datastore + 複数のサーバ間で共有が必要 + MySQL, PostgreSQL + Kubernetes pluginも(summerwind/spire-plugin-datastore-k8s) ▶ Key Manager + Upstream CA使わない場合はdiskプラグインを使って永続ボリュームに書き出す ▶ Upstream CA + Amazon KMSやStaticな鍵ペア、HashiCorp Vaultなど選択できる 前回のMeetupの質疑応答で冗⻑化のためには
 KeyManager部分も共有が必要かもと⾔いましたが、
 共有しなくても良さそうでした
45. SPIRE Serverを振り分ける
46. L4 LoadBalancerによる冗⻑化・(分散) SPIRE Server SPIRE Server SPIRE Agent SPIRE Server L4 Load Balancer Agent-ServerはgRPC通信なので L4 LBでは最初の接続しか分散できない
47. DNSによる冗⻑化・分散 SPIRE Server SPIRE Server SPIRE Agent SPIRE Server DNS Service spire-server 192.168.0.1 spire-server 192.168.0.2 spire-server 192.168.0.3 障害ノードに振られると再接続を繰り返 してしまう点に注意。 ※将来的に解消される⾒込み
 (spiffe/spire/pull/1061)
48. L7 LoadBalancerによる冗⻑化・分散？ SPIRE Server SPIRE Server SPIRE Agent SPIRE Server L7 LoadBalancer 途中にL7LB挟んで正しくmTLSできる？
 
 mTLSできてもServerが認証した相⼿は
 LBになってしまわないか AgentとServerはmTLSで通信
49. ワークロードがJWT-SVIDを使う場合の問題
50. 複数台構成でのJWT-SVIDの課題 ▶ JWT-SVID はServerのKey Managerが管理する鍵によって署名される + JWTの証明書は鍵はServer毎に管理されている秘密鍵で署名される + JWTの署名はTLS証明書のようにチェーンで検証できない ▶ Upstream CAを使っている場合、DatastoreにBundleとして保管されているのは Upstream CAの証明書Bundleのみなので、署名に使った各Server間の鍵とペア の公開鍵の配布が難しい ▶ Upstream CA使っていない場合はBundleとして各Server(RootCA)の証明書が⼿に ⼊るので、そこから公開鍵が⼿に⼊れられる。
51. JWT-SVIDを利⽤する SPIRE Server SPIRE Agent Upstream CA ServerCA Workload Server CAの鍵で署名 されている SPIRE Server SPIRE Agent ServerCA Workload 送信元のJWTの検証鍵
 を⼿に⼊れられない Workload, Agentが
 持っているのは
 UpstreamCAのBundle だけ
52. JWT-SVIDを利⽤する $ spire-server experimental bundle show { "keys": [{ "use": “x509-svid", "kty": "EC", "crv": "P-256", "x": "fK-wKTnKL7KFLM27lqq5DC-bxrVaH6rDV-IcCSEOeL4", "y": "wq-g3TQWxYlV51TCPH030yXsRxvujD4hUUaIQrXk4KI", "x5c": [ “MIIBKjCB0aAD……r7OVLUrL+b9ylAdZglS5kKnYigmwDh+/U=" ] }, { "use": “jwt-svid", "kty": "EC", "kid": "KID", "crv": "P-256", "x": "fK-wKTnKL7KFLM27lqq5DC-bxrVaH6rDV-IcCSEOeL4", "y": "wq-g3TQWxYlV51TCPH030yXsRxvujD4hUUaIQrXk4KI" } ] } X509 SVIDΛݕূ͢ΔͨΊͷ৘ใ JWT SVIDΛݕূ͢ΔͨΊͷ৘ใ
53. JWT-SVIDを利⽤する ▶ 先ほどのコマンドの結果はJWKs形式なので、そのままJWKsエンドポイントで公 開し、JWTの検証ロジックから参照することで鍵は⼿に⼊る ▶ ただし、Server毎の結果なので複数台構成でバランシングされている場合、マッ チする鍵を持つServerに振り分けられないと検証に失敗する + ワークアラウンドとしては + Active/Standby のような構成にする？ + 鍵情報をまとめて公開するJWKsエンドポイントを⽤意する？ ͜͜͸·ͩίϛϡχςΟ΋ղܾઌΛ໛ࡧͯ͠·͢ʢͱࢥ͍·͢) Կ͔Α͍ํ๏͕͋Ε͹ڭ͍͑ͯͩ͘͞
54. まとめ
55. まとめ ▶ Upstream CAがあるとSPIRE Serverは永続ボリューム持たなくてもいいので構成 がシンプルになる ▶ upstream_bundle=false の設定は本番では使わない ▶ Upstream CA無しのパターンは次期バージョンからのほうが良さそう ▶ SPIRE ServerのバランシングはL4 LBかクライアント側でバランシング ▶ 複数台構成でのJWT-SVID利⽤は課題あり + フェデレーションが絡んでくるとさらに難しくなってくる
56. 今後やりたいこと ▶ SPIREのパフォーマンス検証 ▶ MySQL/PostgreSQL以外のデータストア検討 ▶ IstioのIdentityまわりを整理したい + サービス識別⼦がたくさんあって⼤変
57. 今後やりたいこと ▶ もちろん SPIFFE Meetup Tokyo も継続して開催していきたい ▶ 次はZero Trust関連もしくはIstioの発表を集められたらと思っています + ゼロトラストネットワーク ―境界防御の限界を超えるためのセキュアなシステム設計 + 2019/10/28 に⽇本語訳の書籍が発売予定 ▶ 次回も是⾮ご参加いただけたら嬉しいです
58. We’re hiring ご興味ある⽅は、ゼットラボ社員に直接ご連絡ください