Using SPIRE as Identity Provider for Athenz at Yahoo! JAPAN

SPIFFE Meetup Tokyo #3

Transcript

1. Using SPIRE as Identity Provider for Athenz at Yahoo! JAPAN Deep Dive Into Architecture SPIFFE Meetup Tokyo #3 Tomoya Usami(@hiyosi), Z Lab Corporation
2. Outline • Overview • Node Attestation • OpenStack IID • Agent Operation • Workload Attestation • RegistrationEntry • UpstreamAuthority • Topology • Considerations • Opinion
3. VM Overview Nova Compute SPIRE Server UpstreamAuthority NodeAttestor Athenz ※ Athenzを使ったアクセス制御は ローカルのキャッシュを参照する構成も可能 Fetch JWK(s) Policy Check Policy Check Node Attestation Request SVIDs HashiCorp Vault Request CA Cert IID API Write IID Request IID Fetch SVIDs via UNIX Domain Socket SPIRE Agent Workload WorkloadAttestor NodeAttestor
4. • OpenStack IIDを使ったNode Attestationのプラグインを実装 ◦ NodeAttestor ‘openstack_iid’(OSS版とは別のもの) • AgentはConfigDrive経由で渡されたIIDを取得してServerに送付 • ServerはIID(JWT)の署名を検証し、X.509 SVIDを発行 DeepDive: Node Attestation SPIRE Agent Plugin Agent FetchAttestaionData() Read IID SPIRE Server Plugin Server IID API Attest() AttestAgent() Verify IID Fetch JWK(s) Nova Compute IID API Athenz(ZTS) Write IID to ConfigDrive Policy Check Create VM Request IID
5. • IID APIはIIDの発行時、AthenzにPolicyを確認する ◦ 対象インスタンスに対してX.509 SVIDの発行が許可されているか • ConfigDriveに書き出されたIIDはNova APIの結果には含まれない ◦ 対象のインスタンスのみが参照可 SPIRE Agent Plugin Agent FetchAttestaionData() Read IID SPIRE Server Plugin Server IID API Attest() AttestAgent() Verify IID Fetch JWK(s) DeepDive: Node Attestation Nova Compute IID API Athenz(ZTS) Write IID to ConfigDrive Policy Check Create VM Request IID
6. DeepDive: OpenStack IID • IID(JWT)はNode Attestationの有効期限を持つ ◦ 更新されない ◦ 期限内のNode Attestationが必要 • VMに紐付くWorkload情報も含まれる ◦ 1VMでは1つのAthenz Serviceが動作する ◦ 利用者がVM作成時にメタデータとして指定 ◦ 紐付けの正しさはIID作成時にAthenzのPolicyを確認 • Project ID x Instance IDでVMを識別 • e.g. spiffe://example.org/agent/openstack_iid/2a0acd9…./e28a9443-ef3e-4f70-.... { "uuid": "e28a9443-ef3e-4f70-....", "cluster_name": "test-os-cluster", "project_id": "2a0acd9...", "project_name": "test-project", "exp": 4120383600, "athenz_domain": "sports", "athenz_service": "backend", ... } ペイロードの例
7. Yet Another OpenStack IID OpenStackのVendordata(Dynamic JSON)を 使った案も検討したが、YJでの採用は見送り cf. https://docs.google.com/document/d/1HkK3 Q74yYiqckBMI-h9FrZdlWEkrY5R4uHbXRqSRl W8/edit
8. DeepDive: Agent Operation • 再起動時のRe-Attestationは禁止している ◦ 導入環境において、マウントしたIIDに対するアクセス制御が不十分 ▪ Trust on First Use モデル ◦ ただし再起動時はVM再作成 or 取得済みSVIDの再利用が必要 ◦ SVIDを再利用する場合は秘密鍵の永続化が必要(KeyManager Plugin) • ReliabilityとSecurityのバランスが難しい ◦ 鍵を永続化する場合、より短期間でローテーションしたい ◦ SVIDが失効するとAgentの再起動はできないのでVMの作り直しが必要 • SVIDのTTLとは別にローテーション周期を設定したい ◦ 現状はTTLの1/2が経過したらローテーションで固定されている ◦ ReliabilityのためにTTLを大きくすると、ローテーションの頻度が低くなる ◦ https://github.com/spiffe/spire/issues/1754
9. DeepDive: Workload Attestation • IIDに含まれるAthenzサービス情報(Workload情報)を使ったAttestation ◦ WorkloadAttestor ‘openstack_iid’ • IID置き換えに攻撃によるWorkload Attestationは成立しない ◦ RegistrationEntryと一致しないため、Workload Attestationは失敗する ◦ NodeのRe-Attestationは禁止 SPIRE Agent Plugin Agent Read IID FetchX509SVID() Workload Make Selectors - athenz_domain:xxx - athenz_service:xxx Check Entries (Workload Attestation) Attest() ※ 紐付くRegistrationEntryの中に 一致するSelectorがあるか確認
10. DeepDive: RegistrationEntry • 動的にRegistrationEntryを作成する仕組みを用意 ◦ スケジューラによる作成など、任意のタイミングで実施 ◦ Workload Attestationに間に合えばよい ◦ AgentによるEntryの同期 + SVID発行の時間も考慮する • TCP経由でのEntry作成にはAdmin権限が付いたX.509 SVIDが必要 ◦ Entry作成に対してAdmin権限はToo Much ◦ 任意のSVIDを発行できたり、何でもあり ◦ 安全に配布する仕組みとか監査とか考えると管理が大変 • CLIやUDS経由ならAdmin権限不要 ◦ とりあえずNode AttestationのタイミングでEntryを作成するようにした ◦ 今回はIIDにWorkload情報が含まれていたり、基本的に変更されないので可能 • 将来的にはRBAC機能が実装されるかも ◦ https://github.com/spiffe/spire/issues/1975 ◦ 細かく権限を分割できると、TCP経由でのEntry作成も気軽にできるようになる ◦ RBAC機能が実装されたらEntry作成の仕組みは再設計したい SPIRE Server SPIRE Agent Sync Entries Workload CSRs SVIDs Store Entries Fetch SVID SVID Create Entries (Workload Attestation) Check Entries
11. DeepDive: Upstream Authority • 社内のPKIに合流させたい ◦ Athenzや他のプラットフォームとの互換性 ◦ 社内CAとの間にHashiCorpt Vault (Enterprise)を挟んだ構成にした ◦ 社内CAの運用上の都合 • HashiCorp Vault PKI Secret Engine ◦ HashiCorp VaultをCAとして利用 ◦ 中間CAの秘密鍵はVault内で生成され、外には出ない • クレデンシャルなど秘密情報の保護 ◦ PKI Secret Engineの利用には認証が必要 ◦ 漏洩すると社内で利用可能な任意のX.509証明書が発行できてしまう ◦ SPIRE Serverを入室制限や情報持ち出しが困難なネットワークに隔離 ◦ AppRole Auth Methodの利用し、SecretやTokenはマイクロセグメントにバインド • SPIRE Server内部のCAの秘密鍵 ◦ 現在はオンメモリで管理 ◦ 内部のCAがHSMを使って証明書を発行できるようになるとよさそう ▪ https://github.com/spiffe/spire/issues/525 社内CA HashiCorp Vault SPIRE Server Intermediate CA Intermediate CA Issue CA Cert Issue CA Cert Issue Leaf Cert (= X.509 SVID)
12. DeepDive: Topology SPIRE Server SPIRE Server L4 Load Balancer HashiCorp Vault MySQL GSLB SPIRE Server SPIRE Server L4 Load Balancer MySQL HashiCorp Vault Region A Region B Replication Trust Domain: production.example.org
13. DeepDive: Topology • シンプルHA構成のSPIREをマルチリージョンに配置 ◦ JWT SVIDは使わないのでNested SPIRE構成は必要ない、まずはシンプルな構成から ▪ 今後、負荷が問題になってきたらNested SPIRE or Trust Domain分割などが必要になるかも ◦ 広域負荷分散で各Regionに振り分け • TrustDomainは環境ごとに分割 ◦ 同じDatastoreを共有しているためRegionが異なっても同じTrust Domain ◦ RegionでDomain分けるとFederationが必要になってくる ▪ 結局は同じTrust Bundleだが... • L4 Load Balancerを使った負荷分散 ◦ SPIREではgRPCのコネクションは3min毎に作り直される ◦ DNSラウンドロビンだと、RPC単位で分散される ◦ 今回はGSLBの仕組みに関連してL4 Load Balancerを採用 • HashiCorp Vault, MySQLはRegionを跨いでReplication ◦ HashiCorp Vault, MySQLともに社内のプラットフォームを利用 ◦ Vault Tokenはtoken_type=batchを設定
14. Considerations • OpenStack NovaにおけるVMのRebuild (openstack server rebuild …) ◦ VMのRebuildはInstanceのUUIDが同じものが再生成される ◦ Node Attestationにbuild毎に変わるパラメータを入れるなどの考慮が必要 • Agentのアップグレード ◦ SPIRE Serverとのバージョン差異は1マイナーバージョンまで ▪ https://qiita.com/ryysud/items/9575f08cd96936896eb0 ◦ 利用者に依存する形でのバージョンアップは厳しいと感じている ◦ 最新に更新していくための仕組みを検討している ▪ 自動アップグレードの仕組みの提供など • Agent→Serverの通信量 ◦ Agentは定期的(5sec毎)に自分に紐付くRegistration Entryを取得する ◦ 紐付くEntryが多い場合や、Agentの数が多い場合は通信量が多くなる ◦ 今回の場合、紐付くEntryは基本変わらないのでSync Intervalを調整 ▪ Experimental & Undocumented なパラメータなので利用は自己責任 ◦ SPIREでも通信量を減らす作業が行われており改善はされている ▪ https://github.com/spiffe/spire/issues/2182 • モニタリング ◦ Prometheusを使っているが、Metricsはまだこなれていない感じがある ◦ 今後フィードバックして改善していく必要がある
15. Opinion • 運用自体は難しいものではない ◦ 基本的には自動で復旧する仕組みが組み込まれている ◦ PKIの基本的な知識は必要 • loginやexecが制限されているとつらいかも ◦ CLIをつかった運用が制限されてしまう ▪ 安全ではある ◦ 独自でWebベースの管理コンソール作ったりが必要になる ▪ Admin SVID問題が出てくる • 導入する場合はSPIRE Serverを適切に管理できるか検討する ◦ 不正アクセスの防止 ▪ 不正なCLI操作やAdmin SVIDによる操作 ◦ 秘密情報の適切な管理 ▪ Upstream AuthorityやNode Attestationのためのクレデンシャルとか ◦ 証明書有効期限やローテーション周期のバランス, キャパシティプランニング、リリース・アップグレード戦略 ▪ 障害時の影響は大きい ▪ Agent数、Agentに紐付くWorkload数の見積もり(RegistrationEntryの設計) ▪ カナリアリリースやBlue Greenデプロイ
16. Q&A
17. Thank you!