Intro SPIFFE

Intro SPIFFE

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

9e8bdaea0cc26ccf98270c870b9ad26a?s=128

Tomoya Usami

May 14, 2019
Tweet

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

  32. None
  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 が標準化するものは3つ ▶ 統⼀された識別⼦ + 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 ▶ 3つのコンポーネントから構成されるデータ + A SPIFFE ID + A Valid

    Signature + An Optional Public Key ▶ 現在仕様が固まっているフォーマットは2つ + 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. この後の流れ

  70. None