Intro SPIFFE

SPIFFE Meetup Tokyo #1 での発表に使ったスライドです

Transcript

1. SPIFFE Meetup Tokyo #1 Tomoya Usami <tousami@zlab.co.jp> @hiyosi Intro 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. SPIFFEが必要とされる背景 2. Cloud Native Network Security 3. Zero Trust Network 4. SPIFFE 5. 参考資料 6. Appendix: OAuth/OIDC?
5. SPIFFEが必要とされる背景
6. これまでのネットワークセキュリティ と課題
7. これまでのネットワークセキュリティ Service Service Service UnTrust Trust 1 LB Trust 2 Trust 3 Trust 4 FW
8. セグメンテーション Service Service Service UnTrust Trust 1 LB Trust 2 Trust 3 Trust 4 FW
9. Trust 2 Trust 3 Trust 4 信頼の落とし⽳ Service Service Service Data Attacker パッチ適⽤されていない 認証されていない 平⽂で通信
10. クラウドやコンテナ・ファンクション の登場
11. 動的で短命なワークロード Orchestrator
12. Identity per IP 172.16.10.0/24 Pod Container Pod Container Pod Container 10.120.0.0/16 Service Service 10.0.0.0/24 172.16.20.0/24 Node
13. Identity per IP DC GW 192.168.0.0/24 Public IP
14. Cloud Native Network Security
15. Cloud Native Network Security Cloud Provider Host: 172.16.10.1/24 Host: 172.16.10.2/24 Workload Workload Workload Workload Workload Workload
16. Cloud Native Network Security Cloud Provider Host: 172.16.10.1/24 Host: 172.16.10.2/24 Workload Workload Workload Workload Workload Workload Workload レベルで制御
17. Workload Workload Workload Workload Workload Workload Cloud Native Network Security Cloud Provider Host: 172.16.10.1/24 Host: 172.16.10.2/24 ネットワークアドレスではない Identityが必要
18. ⼀つのチャレンジとして
19. Zero Trust Network
20. Zero Trust Network ▶ 完全に信頼を取り除いたネットワーク ▶ すべてのホストをインターネットに⾯しているものと同様に扱う ▶ ユーザ・アプリケーションの認証 ▶ デバイスの認証 ▶ スコアリングによる信頼性評価
21. ゼロトラスト=セキュア？ UnTrust LB Trust 1 Service Service Service Trust 2 Trust 3 Trust 4 FW Attacker 外部の脅威からの防御
22. ゼロトラスト=セキュア？ UnTrust LB Trust 1 Service Service Service Trust 2 Trust 3 Trust 4 FW Attacker 内部にも脅威
23. 信頼を取り除く Service Service Service Service Service UnTrust UnTrust
24. すべてのものは識別⼦を持つ Host: 172.16.10.1/24 Workload Workload Workload 暗号化 暗号化
25. ネットワークリクエストの制御 Policy Engine Data Sources Enforcement Trust Engine Workload Allow
26. Zero Trust Network ▶ 完全に信頼を取り除いたネットワーク ▶ すべてのホストをインターネットに⾯しているものと同様に扱う ▶ ユーザ・アプリケーションの認証 ▶ デバイスの認証 ▶ スコアリングによる信頼性評価
27. 認証⽅式と識別⼦
28. 細分化するシステムとそれぞれの認証 アプリケーション毎にバラバラの認証⽅式 Web API API DB OAuth/OIDC API Key ID/Password TLS証明書
29. 求められるもの ▶ クレデンシャルを埋め込まなくてよい ▶ ⻑期間有効なクレデンシャルを使わなくてよい ▶ クラウド、オンプレミス、どのような環境間でも使える ▶ アイデンティティと秘密保持の両⽅の役割を持つ ▶ 中央集権的な仕組みではない
30. Universal Identity GCP Host: 172.16.10.1/24 Host: 192.168.1.1/24 Workload Workload Workload Workload Workload Workload AWS Universal Identity
31. SPIFFE
33. SPIFFEプロジェクトについて ▶ 公式サイト + https://spiffe.io/ + https://github.com/spiffe/spiffe ▶ Scytale 社が中⼼となって進めている + 元GoogleやAWS, Okta らのエンジニアが中⼼となってスタート + https://scytale.io/
34. SPIFFEプロジェクトについて ▶ GlueCon 2016 での Joe Beda ⽒の発表が始まり
35. SPIFFEプロジェクトについて ▶ 2018年に Sandbox プロジェクトとして CNCF の仲間⼊り ▶ すでに有名な企業で導⼊されている + Uber + Pinterest + Square, + さらに多くの企業も興味を持っている(Cisco, VMware, Rancher, Twilio )
36. SPIFFE ▶ Secure Production Identity Framework For Everyone ▶ 統⼀された識別⼦と安全なサービス間のコミュニケーションのための標準仕様 Borg Borgmon LOAS(ALTS) GFE/ESF Kubernetes Prometheus SPIFFE Envoy
37. ジェイソン・ボーン モデル ▶ ボーンアイデンティティの冒頭のシーン + 主⼈公は何も知らない状態から始まる + 第三者から情報を与えられる + それを使って必要な情報を取得、⾏動を起こしていく SPIFFEではジェイソン・ボーン モデルに従って、何も知らない状態のホストやア プリケーションに対して、⾏動を起こすための情報を与える。 https://www.amazon.co.jp/dp/B00007G0LR
38. SPIFFE 現在SPIFFE が標準化するものは３つ ▶ 統⼀された識別⼦ + SPIFFE ID ▶ SPIFFE IDを含む検証可能なデータフォーマット + SVID (SPIFFE Verification Identity Document) ▶ SVIDを発⾏・取得するためのプラットフォームに依存しないAPI + Workload API
39. SPIFFE ID URI形式で対象を⼀意に識別できる⽂字列 spiffe://dev.acme.com/payments/web scheme=spiffe Trust Domain 対象を識別するためのパス
40. SPIFFE ID Web API DB Production prod.acme.com Payments Service /payments/web /payments/api /payments/db Web API DB staging stage.acme.com Payments Service /payments/web /payments/api /payments/db
41. SPIFFE ID Web API DB Production prod.acme.com Payments Service /payments/web /payments/api /payments/db Web API DB staging stage.acme.com Payments Service /payments/web /payments/api /payments/db spiffe://prod.acme.com/payments/web spiffe://stage.acme.com/payments/db
42. SPIFFE ID Web API DB Prod Payments Service /prod/payments/web Stage Payments Service Web API DB /prod/payments/api /prod/payments/db /stage/payments/web /stage/payments/api /stage/payments/db acme.com
43. SPIFFE ID Web API DB Prod Payments Service /prod/payments/web Stage Payments Service Web API DB /prod/payments/api /prod/payments/db /stage/payments/web /stage/payments/api /stage/payments/db acme.com spiffe://acme.com/prod/payments/web spiffe://acme.com/stage/payments/db
44. SVID ▶ ３つのコンポーネントから構成されるデータ + A SPIFFE ID + A Valid Signature + An Optional Public Key ▶ 現在仕様が固まっているフォーマットは２つ + X.509 SVID + JWT SVID
45. 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
46. 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
47. 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
48. Workload API Workload API workload
 (src) workload
 (dst) JWT SVID X.509 SVID 私は誰ですか？ 信頼できる送信元？ gRPC gRPC あなたのIDです 検証⽤データ
49. [WIP] Federation API Workload API workload
 (src) workload
 (dst) JWT SVID X.509 SVID Workload API Federation API Federation API Federationによりお互いのTrust Bundleを交換
50. SPIFFEのある世界 SPIFFE X.509 SVID JWT SVID L4 L7 API API SPIFFE SPIFFE Amazon EC2 API
51. 参考: 参照実装(SPIRE)の具体例 Workload Cloud Provider SPIRE Agent (1) Node認証 (2) Node 正当性検証 (4) Workload認証 (5) Workload 正当性検証 (6) Workload 情報取得 Kernel / Orchestrator (3) (7) (0) workload 情報登録
52. 詳細な仕様 https://github.com/spiffe/spiffe#spiffe-standards
53. Implementation
54. SVID Issuers
55. SVID Consumers Ghostunnel
56. ユースケース
57. Simple Authentication Service Service SPIFFE TLSクライアント 証明書認証 Bearerトークン Authentication SVIDを使った統⼀された⽅法による認証
58. 最初のシークレットを持たない安全なワークロード・インスタンスの起動 Secure Introduction Service Secret Store SPIFFE HashiCorp Vault, Knox, etc Authentication シークレットの取得
59. SVIDによる相互認証とトンネリングを使った安全なメトリクス・ログの転送 Secure Metrics/Logging SPIFFE Prometheus Proxy Proxy Service トンネリング Authentication
60. 統⼀された識別⼦を使ったService Mesh Service Mesh Service Service Service Service Data Data mTLS SPIFFE mTLS mTLS mTLS
61. VPNを使わず安全にあらゆるシステムにアクセス BeyondCorp SPIFFE Service Access Proxy SSO Controle Plane Enforcement
62. まとめ
63. まとめ ▶ これまでのネットワークセキュリティの課題 + 信頼を作ることによる落とし⽳ + 認証という⽂脈ではIPアドレスは不⼗分になってきた ▶ Zero Trust Network + IPアドレスに頼らないネットワークセキュリティモデル + ユーザ、アプリケーション、デバイス、すべて認証されて識別⼦をもつ ▶ SPIFFE + SPIFFE ID, SVID, Workload APIを定義する標準仕様 + 統⼀された識別⼦を使ってどのような環境でもお互いに認証できる
64. より詳しく知るには ▶ 試してみる (SPIREを使った認証) + https://spiffe.io/spire/getting-started-linux/ + https://spiffe.io/spire/getting-started-k8s/ ▶ コミュニティ Slack チャンネル + https://spiffe.slack.com/ ▶ Qiita + https://qiita.com/tags/spiffe
65. 参考資料
66. 参考資料 1. https://www.slideshare.net/prabathsiriwardena/cloud-native-identity-with- spiffe 2. https://speakerdeck.com/evan2645/introducing-spiffe-an-open-standard-for- identity-in-cloud-native-environments 3. https://schd.ws/hosted_files/kccna18/b6/ KubeCon%20NA%202018_%20SPIFFE%20Intro.pdf 4. https://blog.scytale.io/why-cloud-and-containers-require-a-new-approach-to- service-authentication-c41c4769e1f8 5. https://cloud.google.com/security/encryption-in-transit/application-layer- transport-security/
67. Appendix: OAuth/OIDC?
68. OAuth/OIDC ？ ▶ どうやってNodeを認証するか？ + シークレットを埋め込んだり、共有したりせず、⼈が介在せずに認証したい ▶ ユースケースが限られる + Bearerトークンによる認証以外で使えない + TCPストリームの保護、メッセージの署名などにも使えるほうがよい ▶ Provider運⽤の問題 + 中央集権でない構成が望ましい + 課⾦問題によるスケーラビリティ。プライベートプロバイダ運⽤する？ ▶ フェデレーション？ + いまならOIDCでフェデレーションできる？
69. この後の流れ