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