Intro SPIFFE - Speaker Deck

Intro SPIFFE

by Tomoya Usami

Slide 1

Slide 1 text

SPIFFE Meetup Tokyo #1 Tomoya Usami @hiyosi Intro SPIFFE

Slide 2

Slide 2 text

Tomoya Usami / @hiyosi ▶ ISPにてシステム運⽤基盤の開発、IDaaSサービスの⽴ち上げなどに関わった後、2016年9⽉にゼットラボ株式会社に⼊社。 ▶ 現在はインフラ基盤の研究開発を⾏っている。 ▶ Zero Trust Networkや認証技術に興味がある

Slide 3

Slide 3 text

ゼットラボ株式会社 ▶ 2015年に設⽴されたヤフー株式会社100%⼦会社 ▶ インフラ基盤技術の調査・研究開発 ▶ https://zlab.co.jp/ ▶ https://qiita.com/organizations/zlab

Slide 4

Slide 4 text

アジェンダ 1. SPIFFEが必要とされる背景 2. Cloud Native Network Security 3. Zero Trust Network 4. SPIFFE 5. 参考資料 6. Appendix: OAuth/OIDC?

Slide 5

Slide 5 text

SPIFFEが必要とされる背景

Slide 6

Slide 6 text

これまでのネットワークセキュリティと課題

Slide 7

Slide 7 text

これまでのネットワークセキュリティ Service Service Service UnTrust Trust 1 LB Trust 2 Trust 3 Trust 4 FW

Slide 8

Slide 8 text

セグメンテーション Service Service Service UnTrust Trust 1 LB Trust 2 Trust 3 Trust 4 FW

Slide 9

Slide 9 text

Trust 2 Trust 3 Trust 4 信頼の落とし⽳ Service Service Service Data Attacker パッチ適⽤されていない認証されていない平⽂で通信

Slide 10

Slide 10 text

クラウドやコンテナ・ファンクションの登場

Slide 11

Slide 11 text

動的で短命なワークロード Orchestrator

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Identity per IP DC GW 192.168.0.0/24 Public IP

Slide 14

Slide 14 text

Cloud Native Network Security

Slide 15

Slide 15 text

Cloud Native Network Security Cloud Provider Host: 172.16.10.1/24 Host: 172.16.10.2/24 Workload Workload Workload Workload Workload Workload

Slide 16

Slide 16 text

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 レベルで制御

Slide 17

Slide 17 text

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が必要

Slide 18

Slide 18 text

⼀つのチャレンジとして

Slide 19

Slide 19 text

Zero Trust Network

Slide 20

Slide 20 text

Zero Trust Network ▶ 完全に信頼を取り除いたネットワーク ▶ すべてのホストをインターネットに⾯しているものと同様に扱う ▶ ユーザ・アプリケーションの認証 ▶ デバイスの認証 ▶ スコアリングによる信頼性評価

Slide 21

Slide 21 text

ゼロトラスト=セキュア？ UnTrust LB Trust 1 Service Service Service Trust 2 Trust 3 Trust 4 FW Attacker 外部の脅威からの防御

Slide 22

Slide 22 text

ゼロトラスト=セキュア？ UnTrust LB Trust 1 Service Service Service Trust 2 Trust 3 Trust 4 FW Attacker 内部にも脅威

Slide 23

Slide 23 text

信頼を取り除く Service Service Service Service Service UnTrust UnTrust

Slide 24

Slide 24 text

すべてのものは識別⼦を持つ Host: 172.16.10.1/24 Workload Workload Workload 暗号化暗号化

Slide 25

Slide 25 text

ネットワークリクエストの制御 Policy Engine Data Sources Enforcement Trust Engine Workload Allow

Slide 26

Slide 26 text

Slide 27

Slide 27 text

認証⽅式と識別⼦

Slide 28

Slide 28 text

細分化するシステムとそれぞれの認証アプリケーション毎にバラバラの認証⽅式 Web API API DB OAuth/OIDC API Key ID/Password TLS証明書

Slide 29

Slide 29 text

求められるもの ▶ クレデンシャルを埋め込まなくてよい ▶ ⻑期間有効なクレデンシャルを使わなくてよい ▶ クラウド、オンプレミス、どのような環境間でも使える ▶ アイデンティティと秘密保持の両⽅の役割を持つ ▶ 中央集権的な仕組みではない

Slide 30

Slide 30 text

Universal Identity GCP Host: 172.16.10.1/24 Host: 192.168.1.1/24 Workload Workload Workload Workload Workload Workload AWS Universal Identity

Slide 31

Slide 31 text

SPIFFE

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

SPIFFEプロジェクトについて ▶ 公式サイト + https://spiffe.io/ + https://github.com/spiffe/spiffe ▶ Scytale 社が中⼼となって進めている + 元GoogleやAWS, Okta らのエンジニアが中⼼となってスタート + https://scytale.io/

Slide 34

Slide 34 text

SPIFFEプロジェクトについて ▶ GlueCon 2016 での Joe Beda ⽒の発表が始まり

Slide 35

Slide 35 text

SPIFFEプロジェクトについて ▶ 2018年に Sandbox プロジェクトとして CNCF の仲間⼊り ▶ すでに有名な企業で導⼊されている + Uber + Pinterest + Square, + さらに多くの企業も興味を持っている(Cisco, VMware, Rancher, Twilio )

Slide 36

Slide 36 text

SPIFFE ▶ Secure Production Identity Framework For Everyone ▶ 統⼀された識別⼦と安全なサービス間のコミュニケーションのための標準仕様 Borg Borgmon LOAS(ALTS) GFE/ESF Kubernetes Prometheus SPIFFE Envoy

Slide 37

Slide 37 text

ジェイソン・ボーンモデル ▶ ボーンアイデンティティの冒頭のシーン + 主⼈公は何も知らない状態から始まる + 第三者から情報を与えられる + それを使って必要な情報を取得、⾏動を起こしていく SPIFFEではジェイソン・ボーンモデルに従って、何も知らない状態のホストやアプリケーションに対して、⾏動を起こすための情報を与える。 https://www.amazon.co.jp/dp/B00007G0LR

Slide 38

Slide 38 text

SPIFFE 現在SPIFFE が標準化するものは３つ ▶ 統⼀された識別⼦ + SPIFFE ID ▶ SPIFFE IDを含む検証可能なデータフォーマット + SVID (SPIFFE Veriﬁcation Identity Document) ▶ SVIDを発⾏・取得するためのプラットフォームに依存しないAPI + Workload API

Slide 39

Slide 39 text

SPIFFE ID URI形式で対象を⼀意に識別できる⽂字列 spiﬀe://dev.acme.com/payments/web scheme=spiﬀe Trust Domain 対象を識別するためのパス

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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 spiﬀe://prod.acme.com/payments/web spiﬀe://stage.acme.com/payments/db

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

Slide 44

Slide 44 text

SVID ▶ ３つのコンポーネントから構成されるデータ + A SPIFFE ID + A Valid Signature + An Optional Public Key ▶ 現在仕様が固まっているフォーマットは２つ + X.509 SVID + JWT SVID

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

Workload API ▶ gRPCのストリーミングにより接続 ▶ エンドポイントで直接的な認証は実装しない + カーネルやオーケストレータに問い合わせて呼び出し元のプロセスを特定 ▶ SPIFFE IDとSVIDおよびSVIDを検証するための証明書や鍵ペアを取得できる + X.509 SVID + SPIFFE ID, Certiﬁcate and Private-Key, Trust CA Bundles + JWT SVID + SPIFFE ID, JWT, Trust Public-Key Bundles

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

[WIP] Federation API Workload API workload  (src) workload  (dst) JWT SVID X.509 SVID Workload API Federation API Federation API Federationによりお互いのTrust Bundleを交換

Slide 50

Slide 50 text

SPIFFEのある世界 SPIFFE X.509 SVID JWT SVID L4 L7 API API SPIFFE SPIFFE Amazon EC2 API

Slide 51

Slide 51 text

参考: 参照実装(SPIRE)の具体例 Workload Cloud Provider SPIRE Agent (1) Node認証 (2) Node 正当性検証 (4) Workload認証 (5) Workload 正当性検証 (6) Workload 情報取得 Kernel / Orchestrator (3) (7) (0) workload 情報登録

Slide 52

Slide 52 text

詳細な仕様 https://github.com/spiffe/spiffe#spiffe-standards

Slide 53

Slide 53 text

Implementation

Slide 54

Slide 54 text

SVID Issuers

Slide 55

Slide 55 text

SVID Consumers Ghostunnel

Slide 56

Slide 56 text

ユースケース

Slide 57

Slide 57 text

Simple Authentication Service Service SPIFFE TLSクライアント証明書認証 Bearerトークン Authentication SVIDを使った統⼀された⽅法による認証

Slide 58

Slide 58 text

最初のシークレットを持たない安全なワークロード・インスタンスの起動 Secure Introduction Service Secret Store SPIFFE HashiCorp Vault, Knox, etc Authentication シークレットの取得

Slide 59

Slide 59 text

SVIDによる相互認証とトンネリングを使った安全なメトリクス・ログの転送 Secure Metrics/Logging SPIFFE Prometheus Proxy Proxy Service トンネリング Authentication

Slide 60

Slide 60 text

統⼀された識別⼦を使ったService Mesh Service Mesh Service Service Service Service Data Data mTLS SPIFFE mTLS mTLS mTLS

Slide 61

Slide 61 text

VPNを使わず安全にあらゆるシステムにアクセス BeyondCorp SPIFFE Service Access Proxy SSO Controle Plane Enforcement

Slide 62

Slide 62 text

まとめ

Slide 63

Slide 63 text

まとめ ▶ これまでのネットワークセキュリティの課題 + 信頼を作ることによる落とし⽳ + 認証という⽂脈ではIPアドレスは不⼗分になってきた ▶ Zero Trust Network + IPアドレスに頼らないネットワークセキュリティモデル + ユーザ、アプリケーション、デバイス、すべて認証されて識別⼦をもつ ▶ SPIFFE + SPIFFE ID, SVID, Workload APIを定義する標準仕様 + 統⼀された識別⼦を使ってどのような環境でもお互いに認証できる

Slide 64

Slide 64 text

より詳しく知るには ▶ 試してみる (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

Slide 65

Slide 65 text

参考資料

Slide 66

Slide 66 text

参考資料 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/

Slide 67

Slide 67 text

Appendix: OAuth/OIDC?

Slide 68

Slide 68 text

OAuth/OIDC ？ ▶ どうやってNodeを認証するか？ + シークレットを埋め込んだり、共有したりせず、⼈が介在せずに認証したい ▶ ユースケースが限られる + Bearerトークンによる認証以外で使えない + TCPストリームの保護、メッセージの署名などにも使えるほうがよい ▶ Provider運⽤の問題 + 中央集権でない構成が望ましい + 課⾦問題によるスケーラビリティ。プライベートプロバイダ運⽤する？ ▶ フェデレーション？ + いまならOIDCでフェデレーションできる？