Challenging_Secure_Introduction_With_SPIFFE.pdf

Transcript

1. Cloud Native Days Tokyo 2019 Tomoya Usami <tousami@zlab.co.jp> @hiyosi Challenging Secure Introduction with SPIFFE
2. Tomoya Usami / @hiyosi ▶ ISPにてシステム運⽤基盤の開発、IDaaSサービスの ⽴ち上げなどに関わった後、2016年9⽉にゼットラボ 株式会社に⼊社。 ▶ 現在はインフラ基盤の研究開発を⾏っている。 ▶ Zero Trust Networkや認証技術に興味がある
3. ゼットラボ株式会社 ▶ 2015年に設⽴されたヤフー株式会社100%⼦会社 ▶ インフラ基盤技術の調査・研究開発 ▶ https://zlab.co.jp/ ▶ https://qiita.com/organizations/zlab
4. アジェンダ 1. Can You Keep A Secret Secret? 2. Secure Introduction 3. SPIFFE 4. Our Challenges 5. More Challenges
5. Workloadが使うシークレット Workloadは認証や暗号化など、⾊々な⽤途で秘密情報が必要 Workload Workload TLS Private Key, Client Secret, Password, Encryption Key API Key,
6. シークレットの漏洩時のリスク Workload Workload Unauthorized Workload
7. Can You Keep A Secret Secret?
8. どうやってシークレットを渡すか Workload Secret Store
9. ⼿動でシークレットを登録してCI/CD経由での受け渡し シークレットのデプロイ CI/CD Secret Store Workload Push Push Deploy Fetch
10. CI/CDがシークレットを取得してWorkloadに渡す シークレットのデプロイ CI/CD Secret Store Workload Push Fetch Deploy
11. CI/CDツールにシークレットを持たせてデプロイ時に配布 シークレットのデプロイ CI/CD Secret Store Workload Push Push Deploy Fetch ２重管理 秘密を保管 ディスク経由
12. デプロイ時にCI/CDがシークレットを取得してWorkloadに渡す シークレットのデプロイ CI/CD Secret Store Workload Push Fetch Deploy 強い権限 ディスク経由
13. k8sの場合もSecretリソースの管理で同様の課題がありそう シークレットのデプロイ CI/CD Secret Store Push Deploy Deployment Secret Push Fetch
14. リスクを軽減するには 単⼀の情報源 (SSOT) 最⼩権限の原則 (POLA)
15. Workloadは必要なシークレットを⾃分で取得するのが良さそう シークレットのデプロイ Workload Fetch
16. Workloadは必要なシークレットを⾃分で取得するのが良さそう シークレットのデプロイ Workload Fetch 安全に取得するには？ 必要なシークレット のみ許可したい
17. セキュリティリスクの軽減のために 単⼀の情報源 (SSOT) 最⼩権限の原則 (POLA) 適切な単位で主体を識別 認証・認可
18. Workload単位で認証・認可され、必要なシークレットにみアクセスできる シークレットの取得と認証・認可 Workload 認可 認証 シークレットの取得
19. シークレットの取得と認証・認可 Workload 認証 シークレットの取得 認可 結局は最初のシークレットが必要になってしまうが…
20. Secure Introduction
21. Generally, If you can protect the first secret, you can protect any secret. https://bit.ly/2YlUyLe
22. クラウドサービスの場合、IaaSやIAM、KMSと連携して実現できる Secure Introduction IAM KMS Workload Fetch Check Fetch Cloud Controller Inject
23. Secure Introduction オンプレミスの場合は？ IAMやKMSが存在しない環境ではどうしたらいいか？ IAM KMS Workload Fetch Check Fetch Controller Inject
24. これらを使ってSecure Introductionの仕組みを実現 Secure Introduction
25. Secure Introduction Workload Fetch AuthN Fetch Validate AuthZ
26. IP Address ? Firewall ? ▶ 柔軟性の問題 + Workloadを配置する物理的な場所に縛られる ▶ 動的なポリシー更新の問題 + 実装は難しく、短命なワークロードの環境ではさらに困難 ▶ Cloud Native環境ではIPアドレスはあまり意味をもたない + k8sのようなWorkloadが同⼀IPアドレス空間に配置されて、頻繁に作り直しさ れる環境ではIPアドレスでの制御は難しい
27. Kubernetesの場合はSA Tokenが使える？ ▶ 確かに同じようなアプローチで、PodがSA Tokenを使ってSecret Storeにログイ ンし、シークレットを取得することができます。 ▶ (今の) SA Tokenの問題 + 有効期限が設定されていない + Pod単位での認証が難しい ※これらは現在進められている新しい仕様のSA Tokenに置き換わることによって 将来的に解決する⾒込みはあると思います。
28. SPIFFE
29. SPIFFEプロジェクトについて ▶ 公式サイト + https://spiffe.io/ + https://github.com/spiffe/spiffe ▶ Scytale 社が中⼼となって進めている + 元GoogleやAWS, Okta らのエンジニアが中⼼となってスタート + https://scytale.io/
30. SPIFFEプロジェクトについて ▶ 2018年に Sandbox プロジェクトとして CNCF の仲間⼊り ▶ すでに有名な企業で導⼊されている + Uber + Pinterest + Square, + さらに多くの企業も興味を持っている(Cisco, VMware, Rancher, Twilio )
31. SPIFFE ▶ Secure Production Identity Framework For Everyone ▶ 統⼀された識別⼦と安全なサービス間のコミュニケーションのための標準仕様 Borg Borgmon LOAS(ALTS) GFE/ESF Kubernetes Prometheus SPIFFE Envoy
32. ジェイソン・ボーン モデル ▶ ボーンアイデンティティの冒頭のシーン + 主⼈公は何も知らない状態から始まる + 第三者から情報を与えられる + それを使って必要な情報を取得、⾏動を起こしていく SPIFFEではジェイソン・ボーン モデルに従って、何も知らない状態のホストやア プリケーションに対して、⾏動を起こすための情報を与える。 https://www.amazon.co.jp/dp/B00007G0LR
33. SPIFFE 現在SPIFFE が標準化するものは３つ ▶ 統⼀された識別⼦ + SPIFFE ID ▶ SPIFFE IDを含む検証可能なデータフォーマット + SVID (SPIFFE Verification Identity Document) ▶ SVIDを発⾏・取得するためのプラットフォームに依存しないAPI + Workload API, Federation API
34. SPIFFE ID URI形式で対象を⼀意に識別できる⽂字列 spiffe://dev.acme.com/payments/web scheme=spiffe Trust Domain 対象を識別するためのパス
35. SVID ▶ ３つのコンポーネントから構成されるデータフォーマット + A SPIFFE ID + A Valid Signature + An Optional Public Key ▶ 現在仕様が固まっているフォーマットは２つ + X.509 SVID + JWT SVID
36. X.509 SVID Data: Version: 3 (0x2) Serial Number: 4 (0x4) Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=SPIFFE 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/host/workload
37. JWT SVID { "aud":"sidecar", "exp":1551170058, "iat":1551169758, "sub": "spiffe://prod.acme.com/payments/web" } Issuer Web API JWT SVIDください JWT SVID JWT Auth iss
 (issuer) sub (subject) aud (audience) payload
38. Workload API ▶ gRPCのストリーミングにより接続 ▶ エンドポイントで直接的な認証は実装しない + カーネルやオーケストレータに問い合わせて呼び出し元のプロセスを特定 ▶ SPIFFE IDとSVIDおよびSVIDを検証するための証明書や鍵ペアを取得できる + X.509 SVID + SPIFFE ID, Certificate and Private-Key, Trust CA Bundles + JWT SVID + SPIFFE ID, JWT, Trust Public-Key Bundles
39. Workload API Workload API workload
 (src) workload
 (dst) JWT SVID X.509 SVID 私は誰ですか？ 信頼できる送信元？ gRPC gRPC あなたのIDです 検証⽤データ
40. Federation API Workload API workload
 (src) workload
 (dst) JWT SVID X.509 SVID Workload API Federation API Federation API Federationによりお互いのTrust Bundleを交換
41. SPIFFEのある世界 SPIFFE X.509 SVID JWT SVID L4 L7 API API SPIFFE SPIFFE Amazon EC2 API
42. Implementation
43. SVID Issuers
44. SVID Consumers Ghostunnel
45. Our Challenges
46. SPIFFEの実装としてSPIREを採⽤ Our Challenge
47. SPIREの構成 •SPIRE Server •SPIRE Agent(ノード毎) SPIRE Component SPIRE Agent SPIRE Server SPIRE Agent SPIRE Agent Workload Workload Workload Workload Workload Workload
48. Node Attestation SPIRE Agent Valid Attestation Request Fetch Node Info Attest SPIRE Server Provider
49. SPIRE on OpenStack ▶ 現時点でSPIREはOpenStackをサポートしておらず、OpenStack Instanceの Attestationができなかった OpenStack Plugin作りました！ https://github.com/zlabjp/spire-openstack-plugin
50. Node Attestation (OpenStack) Agent Attest Node Fetch Node information Fetch Node data Signed Node Identifier Sign Identifier Node Attestor Node Attestor Server MetaData Service Nova API Attestation Request w/ Node information
51. Workload Attestation Workload Provider SPIRE Agent Fetch Identifier Kernel / Orchestrator SPIRE Server Fetch Workload data Attest Attested Node
52. Workload Attestation(e.g., K8S) Client Agent Fetch workload identifier Fetch workload information Attest workload 
 (compare entry) Signed workload Identifier Workload Attestor Server kubelet sync entries related to Node Attested Instance Kernel
53. Building Trust Chain Provider VM OS Workload SPIRE Agent SPIRE Server Attest Attest
54. Authenticate with First Secret(SVID) SPIREから取得したWorkload Identifier(SVID)を使って認証する Workload AuthN JWT Auth TLS Cert Auth X.509 Cert or JWT
55. Authenticate with JWT SVID workload Authentication Request Verify JWT sync public keys Verify 
 subject, audience claims Fetch Secrets Token /auth/jwt/login /secret/data/:path
56. Authenticate with JWT SVID workload Authentication Request Verify JWT sync public keys Verify 
 subject, audience claims Fetch Secrets Token /auth/jwt/login /secret/data/:path JWK未サポート ※次バージョンでは 解消されそう
57. Vault Configuration (JWT Auth) 許可するSPIFFE ID
58. Authenticate with X.509 SVID workload Authentication Request Verify TLS Cert sync CA cert Verify 
 SAN field Fetch Secrets Token /auth/cert/login /secret/data/:path
59. Authenticate with X.509 SVID workload Authentication Request Verify TLS Cert sync CA cert Verify 
 SAN field Fetch Secrets Token /auth/cert/login /secret/data/:path 1個しかセット
 できなさそう CNフィールド必須
60. Implementation Pattern
61. Implementation( Direct) Workload Fetch AuthN Fetch AuthZ SPIRE Agent 既成プロダクトへの導⼊は困難
62. Implementation( Sidecar) Workload Fetch AuthN Fetch AuthZ Sidecar Workload毎にSidecarの設定が必要 SPIRE Agent
63. Implementation( Ambassadors) Proxy Fetch AuthN AuthZ Workload SPIRE Agent Workload Fetch Workload単位での識別が難しい
64. More Challenges
65. よりセキュアにOpenStack の Node を Attestation できないか
66. OpenStack Metadata { "uuid": "d8e02d56-2648-49a3-bf97-6be8f1204f38", "availability_zone": "nova", "hostname": "test.novalocal", "launch_index": 0, "meta": { "priority": "low", "role": "webserver" }, "project_id": "f7ac731cc11f40efbc03a9f9e1d1d21f", "public_keys": “…”, "name": "test" }
67. OpenStack Metadata $ curl http://169.254.169.254/2009-04-04/meta-data/ ami-id local-hostname ami-launch-index local-ipv4 ami-manifest-path placement/ block-device-mapping/ public-hostname hostname public-ipv4 instance-action public-keys/ instance-id ramdisk-id instance-type reservation-id kernel-id security-groups
68. OpenStack Metadataの課題 ▶ 提供されているメタデータはNova APIにアクセスできる権限があればだれでも参 照可能なデータ。 つまり、簡単になりすましが可能な状態 なりすましを防ぐにはメタデータへの署名などが必要 ▶ AWSのInstance Identity Documents ▶ GCPのInstance Identity Token ▶ AzureのMSI Token 主要なクラウドプロバイダは同等のデータを 提供しているが、OpenStackにはない
69. Vendordata(Dynamic JSON)を使った拡張 「OpenStack Instance Identity Documents 」 検証可能なメタデータを提供するための仕様をまとめました！ Proposalドキュメントとして近⽇公開し、SPIFFEコミュニティとのオープンな議 論で内容を詰めていきます。 ▶ Nova VM Instanceのメタデータに署名を付与しJWT形式で提供 ▶ JWT検証⽤の公開鍵もJWK形式で提供
70. Vendordata(Dynamic JSON)を使った拡張
71. OpenStack IIDの例 { "iid": { "data": “eyJhbGciOiJFUzM4NCIsImtpZCI6IjgxOW…vQ_uXMNiTwhCuJkqnpKAui6XKiM0… CTQwkbA5ePfwO9MjzcMFzPL-VUMZo77VjXBu” }, "iid_keys": { "keys": [ { "use": "sig", "crv": "P-384", "kty": "EC", "alg": "ES384", "y": "izVeFkEF7HxFlhWL69wN46bSh_Fb-FhfeuouxgSqdjR39GczxhXvztq0AukORw48", "x": "nY6zWiORxfRX0aEGB9ykiycUCTgVfWC_6mEF5xQW1dGdlD7u2bjAUrzj3Yuga8BE", "kid": "e225f0db90671819000576ec37fd34f787edb303" } ] } }
72. Node Attestation (with IID) Node Agent Attestation Request w/ IID Attest Instance Fetch verification keys Fetch instance data Signed Instance Identifier Sign Identifier MetaData Service Metadata Service Instance Identity Documents(IID) public keys verify signature Server
73. しかし、OpenStackには標準機能として署名付き のメタデータを提供してほしいです
74. まとめ
75. まとめ ▶ Workloadは何も持っていなくても⾃⾝のIdentityを⼿に⼊れることができる + SPIFFE/SPIRE ▶ 最初のシークレットを安全に配布することで、Workloadはそれを使ってシーク レットストア等から必要なシークレットを安全に取得することができる + Secure Introduction ▶ 現状のOpenStackでは厳密なNode Attestationは難しい + Vendordataを使って拡張
76. コミュニティの宣伝
77. ▶ SPIFFE Meetup Tokyo 主催しています！ ▶ https://spiffe-jp.connpass.com/ ▶ 2019/5 に第⼀回を開催 + Youtube にSPIFFE Meetup Tokyo チャンネルあります + 前回の動画も公開しています！ ▶ 第⼆回の開催を秋頃に予定していますのでぜひご参加ください！ SPIFFE Meetup Tokyoについて
78. 会社の宣伝
79. We’re hiring ご興味ある⽅は、ゼットラボ社員に直接ご連絡ください
80. Thank you!