Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

Intro SPIFFE

Intro SPIFFE

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

Tomoya Usami

May 14, 2019
Tweet

More Decks by Tomoya Usami

Other Decks in Technology

Transcript

  1. アジェンダ 1. SPIFFEが必要とされる背景 2. Cloud Native Network Security 3. Zero

    Trust Network 4. SPIFFE 5. 参考資料 6. Appendix: OAuth/OIDC?
  2. Trust 2 Trust 3 Trust 4 信頼の落とし⽳ Service Service Service

    Data Attacker パッチ適⽤されていない 認証されていない 平⽂で通信
  3. 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
  4. 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 レベルで制御
  5. 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が必要
  6. ゼロトラスト=セキュア? UnTrust LB Trust 1 Service Service Service Trust 2

    Trust 3 Trust 4 FW Attacker 外部の脅威からの防御
  7. SPIFFEプロジェクトについて ▶ 2018年に Sandbox プロジェクトとして CNCF の仲間⼊り ▶ すでに有名な企業で導⼊されている +

    Uber + Pinterest + Square, + さらに多くの企業も興味を持っている(Cisco, VMware, Rancher, Twilio )
  8. ジェイソン・ボーン モデル ▶ ボーンアイデンティティの冒頭のシーン + 主⼈公は何も知らない状態から始まる + 第三者から情報を与えられる + それを使って必要な情報を取得、⾏動を起こしていく

    SPIFFEではジェイソン・ボーン モデルに従って、何も知らない状態のホストやア プリケーションに対して、⾏動を起こすための情報を与える。 https://www.amazon.co.jp/dp/B00007G0LR
  9. SPIFFE 現在SPIFFE が標準化するものは3つ ▶ 統⼀された識別⼦ + SPIFFE ID ▶ SPIFFE

    IDを含む検証可能なデータフォーマット + SVID (SPIFFE Verification Identity Document) ▶ SVIDを発⾏・取得するためのプラットフォームに依存しないAPI + Workload API
  10. 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
  11. 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
  12. 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
  13. 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
  14. SVID ▶ 3つのコンポーネントから構成されるデータ + A SPIFFE ID + A Valid

    Signature + An Optional Public Key ▶ 現在仕様が固まっているフォーマットは2つ + X.509 SVID + JWT SVID
  15. 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
  16. 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
  17. 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
  18. Workload API Workload API workload
 (src) workload
 (dst) JWT SVID

    X.509 SVID 私は誰ですか? 信頼できる送信元? gRPC gRPC あなたのIDです 検証⽤データ
  19. [WIP] Federation API Workload API workload
 (src) workload
 (dst) JWT

    SVID X.509 SVID Workload API Federation API Federation API Federationによりお互いのTrust Bundleを交換
  20. 参考: 参照実装(SPIRE)の具体例 Workload Cloud Provider SPIRE Agent (1) Node認証 (2)

    Node 正当性検証 (4) Workload認証 (5) Workload 正当性検証 (6) Workload 情報取得 Kernel / Orchestrator (3) (7) (0) workload 情報登録
  21. まとめ ▶ これまでのネットワークセキュリティの課題 + 信頼を作ることによる落とし⽳ + 認証という⽂脈ではIPアドレスは不⼗分になってきた ▶ Zero Trust

    Network + IPアドレスに頼らないネットワークセキュリティモデル + ユーザ、アプリケーション、デバイス、すべて認証されて識別⼦をもつ ▶ SPIFFE + SPIFFE ID, SVID, Workload APIを定義する標準仕様 + 統⼀された識別⼦を使ってどのような環境でもお互いに認証できる
  22. 参考資料 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/
  23. OAuth/OIDC ? ▶ どうやってNodeを認証するか? + シークレットを埋め込んだり、共有したりせず、⼈が介在せずに認証したい ▶ ユースケースが限られる + Bearerトークンによる認証以外で使えない

    + TCPストリームの保護、メッセージの署名などにも使えるほうがよい ▶ Provider運⽤の問題 + 中央集権でない構成が望ましい + 課⾦問題によるスケーラビリティ。プライベートプロバイダ運⽤する? ▶ フェデレーション? + いまならOIDCでフェデレーションできる?