Challenging_Secure_Introduction_With_SPIFFE.pdf

by Tomoya Usami

Slide 1

Slide 1 text

Cloud Native Days Tokyo 2019 Tomoya Usami @hiyosi Challenging Secure Introduction with 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. Can You Keep A Secret Secret? 2. Secure Introduction 3. SPIFFE 4. Our Challenges 5. More Challenges

Slide 5

Slide 5 text

Workloadが使うシークレット Workloadは認証や暗号化など、⾊々な⽤途で秘密情報が必要 Workload Workload TLS Private Key, Client Secret, Password, Encryption Key API Key,

Slide 6

Slide 6 text

シークレットの漏洩時のリスク Workload Workload Unauthorized Workload

Slide 7

Slide 7 text

Can You Keep A Secret Secret?

Slide 8

Slide 8 text

どうやってシークレットを渡すか Workload Secret Store

Slide 9

Slide 9 text

⼿動でシークレットを登録してCI/CD経由での受け渡しシークレットのデプロイ CI/CD Secret Store Workload Push Push Deploy Fetch

Slide 10

Slide 10 text

CI/CDがシークレットを取得してWorkloadに渡すシークレットのデプロイ CI/CD Secret Store Workload Push Fetch Deploy

Slide 11

Slide 11 text

CI/CDツールにシークレットを持たせてデプロイ時に配布シークレットのデプロイ CI/CD Secret Store Workload Push Push Deploy Fetch ２重管理秘密を保管ディスク経由

Slide 12

Slide 12 text

デプロイ時にCI/CDがシークレットを取得してWorkloadに渡すシークレットのデプロイ CI/CD Secret Store Workload Push Fetch Deploy 強い権限ディスク経由

Slide 13

Slide 13 text

k8sの場合もSecretリソースの管理で同様の課題がありそうシークレットのデプロイ CI/CD Secret Store Push Deploy Deployment Secret Push Fetch

Slide 14

Slide 14 text

リスクを軽減するには単⼀の情報源 (SSOT) 最⼩権限の原則 (POLA)

Slide 15

Slide 15 text

Workloadは必要なシークレットを⾃分で取得するのが良さそうシークレットのデプロイ Workload Fetch

Slide 16

Slide 16 text

Workloadは必要なシークレットを⾃分で取得するのが良さそうシークレットのデプロイ Workload Fetch 安全に取得するには？必要なシークレットのみ許可したい

Slide 17

Slide 17 text

セキュリティリスクの軽減のために単⼀の情報源 (SSOT) 最⼩権限の原則 (POLA) 適切な単位で主体を識別認証・認可

Slide 18

Slide 18 text

Workload単位で認証・認可され、必要なシークレットにみアクセスできるシークレットの取得と認証・認可 Workload 認可認証シークレットの取得

Slide 19

Slide 19 text

シークレットの取得と認証・認可 Workload 認証シークレットの取得認可結局は最初のシークレットが必要になってしまうが…

Slide 20

Slide 20 text

Secure Introduction

Slide 21

Slide 21 text

Generally, If you can protect the ﬁrst secret, you can protect any secret. https://bit.ly/2YlUyLe

Slide 22

Slide 22 text

クラウドサービスの場合、IaaSやIAM、KMSと連携して実現できる Secure Introduction IAM KMS Workload Fetch Check Fetch Cloud Controller Inject

Slide 23

Slide 23 text

Secure Introduction オンプレミスの場合は？ IAMやKMSが存在しない環境ではどうしたらいいか？ IAM KMS Workload Fetch Check Fetch Controller Inject

Slide 24

Slide 24 text

これらを使ってSecure Introductionの仕組みを実現 Secure Introduction

Slide 25

Slide 25 text

Secure Introduction Workload Fetch AuthN Fetch Validate AuthZ

Slide 26

Slide 26 text

IP Address ? Firewall ? ▶ 柔軟性の問題 + Workloadを配置する物理的な場所に縛られる ▶ 動的なポリシー更新の問題 + 実装は難しく、短命なワークロードの環境ではさらに困難 ▶ Cloud Native環境ではIPアドレスはあまり意味をもたない + k8sのようなWorkloadが同⼀IPアドレス空間に配置されて、頻繁に作り直しされる環境ではIPアドレスでの制御は難しい

Slide 27

Slide 27 text

Kubernetesの場合はSA Tokenが使える？ ▶ 確かに同じようなアプローチで、PodがSA Tokenを使ってSecret Storeにログインし、シークレットを取得することができます。 ▶ (今の) SA Tokenの問題 + 有効期限が設定されていない + Pod単位での認証が難しい ※これらは現在進められている新しい仕様のSA Tokenに置き換わることによって将来的に解決する⾒込みはあると思います。

Slide 28

Slide 28 text

SPIFFE

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 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 37

Slide 37 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 38

Slide 38 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 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

Implementation

Slide 43

Slide 43 text

SVID Issuers

Slide 44

Slide 44 text

SVID Consumers Ghostunnel

Slide 45

Slide 45 text

Our Challenges

Slide 46

Slide 46 text

SPIFFEの実装としてSPIREを採⽤ Our Challenge

Slide 47

Slide 47 text

SPIREの構成 •SPIRE Server •SPIRE Agent(ノード毎) SPIRE Component SPIRE Agent SPIRE Server SPIRE Agent SPIRE Agent Workload Workload Workload Workload Workload Workload

Slide 48

Slide 48 text

Node Attestation SPIRE Agent Valid Attestation Request Fetch Node Info Attest SPIRE Server Provider

Slide 49

Slide 49 text

SPIRE on OpenStack ▶ 現時点でSPIREはOpenStackをサポートしておらず、OpenStack Instanceの Attestationができなかった OpenStack Plugin作りました！ https://github.com/zlabjp/spire-openstack-plugin

Slide 50

Slide 50 text

Node Attestation (OpenStack) Agent Attest Node Fetch Node information Fetch Node data Signed Node Identiﬁer Sign Identiﬁer Node Attestor Node Attestor Server MetaData Service Nova API Attestation Request w/ Node information

Slide 51

Slide 51 text

Workload Attestation Workload Provider SPIRE Agent Fetch Identiﬁer Kernel / Orchestrator SPIRE Server Fetch Workload data Attest Attested Node

Slide 52

Slide 52 text

Workload Attestation(e.g., K8S) Client Agent Fetch workload identiﬁer Fetch workload information Attest workload   (compare entry) Signed workload Identiﬁer Workload Attestor Server kubelet sync entries related to Node Attested Instance Kernel

Slide 53

Slide 53 text

Building Trust Chain Provider VM OS Workload SPIRE Agent SPIRE Server Attest Attest

Slide 54

Slide 54 text

Authenticate with First Secret(SVID) SPIREから取得したWorkload Identiﬁer(SVID)を使って認証する Workload AuthN JWT Auth TLS Cert Auth X.509 Cert or JWT

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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未サポート ※次バージョンでは解消されそう

Slide 57

Slide 57 text

Vault Conﬁguration (JWT Auth) 許可するSPIFFE ID

Slide 58

Slide 58 text

Authenticate with X.509 SVID workload Authentication Request Verify TLS Cert sync CA cert Verify   SAN ﬁeld Fetch Secrets Token /auth/cert/login /secret/data/:path

Slide 59

Slide 59 text

Authenticate with X.509 SVID workload Authentication Request Verify TLS Cert sync CA cert Verify   SAN ﬁeld Fetch Secrets Token /auth/cert/login /secret/data/:path 1個しかセット  できなさそう CNフィールド必須

Slide 60

Slide 60 text

Implementation Pattern

Slide 61

Slide 61 text

Implementation( Direct) Workload Fetch AuthN Fetch AuthZ SPIRE Agent 既成プロダクトへの導⼊は困難

Slide 62

Slide 62 text

Implementation( Sidecar) Workload Fetch AuthN Fetch AuthZ Sidecar Workload毎にSidecarの設定が必要 SPIRE Agent

Slide 63

Slide 63 text

Implementation( Ambassadors) Proxy Fetch AuthN AuthZ Workload SPIRE Agent Workload Fetch Workload単位での識別が難しい

Slide 64

Slide 64 text

More Challenges

Slide 65

Slide 65 text

よりセキュアにOpenStack の Node を Attestation できないか

Slide 66

Slide 66 text

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" }

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

OpenStack Metadataの課題 ▶ 提供されているメタデータはNova APIにアクセスできる権限があればだれでも参照可能なデータ。つまり、簡単になりすましが可能な状態なりすましを防ぐにはメタデータへの署名などが必要 ▶ AWSのInstance Identity Documents ▶ GCPのInstance Identity Token ▶ AzureのMSI Token 主要なクラウドプロバイダは同等のデータを提供しているが、OpenStackにはない

Slide 69

Slide 69 text

Vendordata(Dynamic JSON)を使った拡張「OpenStack Instance Identity Documents 」検証可能なメタデータを提供するための仕様をまとめました！ Proposalドキュメントとして近⽇公開し、SPIFFEコミュニティとのオープンな議論で内容を詰めていきます。 ▶ Nova VM Instanceのメタデータに署名を付与しJWT形式で提供 ▶ JWT検証⽤の公開鍵もJWK形式で提供

Slide 70

Slide 70 text

Vendordata(Dynamic JSON)を使った拡張

Slide 71

Slide 71 text

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" } ] } }

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

しかし、OpenStackには標準機能として署名付きのメタデータを提供してほしいです

Slide 74

Slide 74 text

まとめ

Slide 75

Slide 75 text

まとめ ▶ Workloadは何も持っていなくても⾃⾝のIdentityを⼿に⼊れることができる + SPIFFE/SPIRE ▶ 最初のシークレットを安全に配布することで、Workloadはそれを使ってシークレットストア等から必要なシークレットを安全に取得することができる + Secure Introduction ▶ 現状のOpenStackでは厳密なNode Attestationは難しい + Vendordataを使って拡張

Slide 76

Slide 76 text

コミュニティの宣伝

Slide 77

Slide 77 text

▶ SPIFFE Meetup Tokyo 主催しています！ ▶ https://spiﬀe-jp.connpass.com/ ▶ 2019/5 に第⼀回を開催 + Youtube にSPIFFE Meetup Tokyo チャンネルあります + 前回の動画も公開しています！ ▶ 第⼆回の開催を秋頃に予定していますのでぜひご参加ください！ SPIFFE Meetup Tokyoについて

Slide 78

Slide 78 text

会社の宣伝

Slide 79

Slide 79 text

We’re hiring ご興味ある⽅は、ゼットラボ社員に直接ご連絡ください

Slide 80

Slide 80 text

Thank you!