Challenging_Secure_Introduction_With_SPIFFE.pdf

9e8bdaea0cc26ccf98270c870b9ad26a?s=47 Tomoya Usami
July 23, 2019
1.6k

 Challenging_Secure_Introduction_With_SPIFFE.pdf

9e8bdaea0cc26ccf98270c870b9ad26a?s=128

Tomoya Usami

July 23, 2019
Tweet

Transcript

  1. Cloud Native Days Tokyo 2019 Tomoya Usami <tousami@zlab.co.jp> @hiyosi Challenging

    Secure Introduction with 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. Can You Keep A Secret Secret? 2. Secure

    Introduction 3. SPIFFE 4. Our Challenges 5. More Challenges
  5. Workloadが使うシークレット Workloadは認証や暗号化など、⾊々な⽤途で秘密情報が必要 Workload Workload TLS Private Key, Client Secret, Password,

    Encryption Key API Key,
  6. シークレットの漏洩時のリスク Workload Workload Unauthorized Workload

  7. Can You Keep A Secret Secret?

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

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

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

  11. CI/CDツールにシークレットを持たせてデプロイ時に配布 シークレットのデプロイ CI/CD Secret Store Workload Push Push Deploy Fetch

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

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

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

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

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

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

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

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

  20. Secure Introduction

  21. Generally, If you can protect the first secret, you can

    protect any secret. https://bit.ly/2YlUyLe
  22. クラウドサービスの場合、IaaSやIAM、KMSと連携して実現できる Secure Introduction IAM KMS Workload Fetch Check Fetch Cloud

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

    Controller Inject
  24. これらを使ってSecure Introductionの仕組みを実現 Secure Introduction

  25. Secure Introduction Workload Fetch AuthN Fetch Validate AuthZ

  26. IP Address ? Firewall ? ▶ 柔軟性の問題 + Workloadを配置する物理的な場所に縛られる ▶

    動的なポリシー更新の問題 + 実装は難しく、短命なワークロードの環境ではさらに困難 ▶ Cloud Native環境ではIPアドレスはあまり意味をもたない + k8sのようなWorkloadが同⼀IPアドレス空間に配置されて、頻繁に作り直しさ れる環境ではIPアドレスでの制御は難しい
  27. Kubernetesの場合はSA Tokenが使える? ▶ 確かに同じようなアプローチで、PodがSA Tokenを使ってSecret Storeにログイ ンし、シークレットを取得することができます。 ▶ (今の) SA

    Tokenの問題 + 有効期限が設定されていない + Pod単位での認証が難しい ※これらは現在進められている新しい仕様のSA Tokenに置き換わることによって 将来的に解決する⾒込みはあると思います。
  28. SPIFFE

  29. SPIFFEプロジェクトについて ▶ 公式サイト + https://spiffe.io/ + https://github.com/spiffe/spiffe ▶ Scytale 社が中⼼となって進めている

    + 元GoogleやAWS, Okta らのエンジニアが中⼼となってスタート + https://scytale.io/
  30. SPIFFEプロジェクトについて ▶ 2018年に Sandbox プロジェクトとして CNCF の仲間⼊り ▶ すでに有名な企業で導⼊されている +

    Uber + Pinterest + Square, + さらに多くの企業も興味を持っている(Cisco, VMware, Rancher, Twilio )
  31. SPIFFE ▶ Secure Production Identity Framework For Everyone ▶ 統⼀された識別⼦と安全なサービス間のコミュニケーションのための標準仕様

    Borg Borgmon LOAS(ALTS) GFE/ESF Kubernetes Prometheus SPIFFE Envoy
  32. ジェイソン・ボーン モデル ▶ ボーンアイデンティティの冒頭のシーン + 主⼈公は何も知らない状態から始まる + 第三者から情報を与えられる + それを使って必要な情報を取得、⾏動を起こしていく

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

    IDを含む検証可能なデータフォーマット + SVID (SPIFFE Verification Identity Document) ▶ SVIDを発⾏・取得するためのプラットフォームに依存しないAPI + Workload API, Federation API
  34. SPIFFE ID URI形式で対象を⼀意に識別できる⽂字列 spiffe://dev.acme.com/payments/web scheme=spiffe Trust Domain 対象を識別するためのパス

  35. SVID ▶ 3つのコンポーネントから構成されるデータフォーマット + A SPIFFE ID + A Valid

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

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

    X.509 SVID Workload API Federation API Federation API Federationによりお互いのTrust Bundleを交換
  41. SPIFFEのある世界 SPIFFE X.509 SVID JWT SVID L4 L7 API API

    SPIFFE SPIFFE Amazon EC2 API
  42. Implementation

  43. SVID Issuers

  44. SVID Consumers Ghostunnel

  45. Our Challenges

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

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

    Server SPIRE Agent SPIRE Agent Workload Workload Workload Workload Workload Workload
  48. Node Attestation SPIRE Agent Valid Attestation Request Fetch Node Info

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

  50. Node Attestation (OpenStack) Agent Attest Node Fetch Node information Fetch

    Node data Signed Node Identifier Sign Identifier Node Attestor Node Attestor Server MetaData Service Nova API Attestation Request w/ Node information
  51. Workload Attestation Workload Provider SPIRE Agent Fetch Identifier Kernel /

    Orchestrator SPIRE Server Fetch Workload data Attest Attested Node
  52. Workload Attestation(e.g., K8S) Client Agent Fetch workload identifier Fetch workload

    information Attest workload 
 (compare entry) Signed workload Identifier Workload Attestor Server kubelet sync entries related to Node Attested Instance Kernel
  53. Building Trust Chain Provider VM OS Workload SPIRE Agent SPIRE

    Server Attest Attest
  54. Authenticate with First Secret(SVID) SPIREから取得したWorkload Identifier(SVID)を使って認証する Workload AuthN JWT Auth

    TLS Cert Auth X.509 Cert or JWT
  55. 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
  56. 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未サポート ※次バージョンでは 解消されそう
  57. Vault Configuration (JWT Auth) 許可するSPIFFE ID

  58. Authenticate with X.509 SVID workload Authentication Request Verify TLS Cert

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

    sync CA cert Verify 
 SAN field Fetch Secrets Token /auth/cert/login /secret/data/:path 1個しかセット
 できなさそう CNフィールド必須
  60. Implementation Pattern

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

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

    Agent
  63. Implementation( Ambassadors) Proxy Fetch AuthN AuthZ Workload SPIRE Agent Workload

    Fetch Workload単位での識別が難しい
  64. More Challenges

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

  66. 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" }
  67. 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
  68. OpenStack Metadataの課題 ▶ 提供されているメタデータはNova APIにアクセスできる権限があればだれでも参 照可能なデータ。 つまり、簡単になりすましが可能な状態 なりすましを防ぐにはメタデータへの署名などが必要 ▶ AWSのInstance

    Identity Documents ▶ GCPのInstance Identity Token ▶ AzureのMSI Token 主要なクラウドプロバイダは同等のデータを 提供しているが、OpenStackにはない
  69. Vendordata(Dynamic JSON)を使った拡張 「OpenStack Instance Identity Documents 」 検証可能なメタデータを提供するための仕様をまとめました! Proposalドキュメントとして近⽇公開し、SPIFFEコミュニティとのオープンな議 論で内容を詰めていきます。

    ▶ Nova VM Instanceのメタデータに署名を付与しJWT形式で提供 ▶ JWT検証⽤の公開鍵もJWK形式で提供
  70. Vendordata(Dynamic JSON)を使った拡張

  71. 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" } ] } }
  72. 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
  73. しかし、OpenStackには標準機能として署名付き のメタデータを提供してほしいです

  74. まとめ

  75. まとめ ▶ Workloadは何も持っていなくても⾃⾝のIdentityを⼿に⼊れることができる + SPIFFE/SPIRE ▶ 最初のシークレットを安全に配布することで、Workloadはそれを使ってシーク レットストア等から必要なシークレットを安全に取得することができる + Secure

    Introduction ▶ 現状のOpenStackでは厳密なNode Attestationは難しい + Vendordataを使って拡張
  76. コミュニティの宣伝

  77. ▶ SPIFFE Meetup Tokyo 主催しています! ▶ https://spiffe-jp.connpass.com/ ▶ 2019/5 に第⼀回を開催

    + Youtube にSPIFFE Meetup Tokyo チャンネルあります + 前回の動画も公開しています! ▶ 第⼆回の開催を秋頃に予定していますのでぜひご参加ください! SPIFFE Meetup Tokyoについて
  78. 会社の宣伝

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

  80. Thank you!