Upgrade to Pro — share decks privately, control downloads, hide ads and more …

k8sとVaultを組み合わせてシークレットをもっとセキュアに

Cbc297b07593321e52c75a9ebcc0f843?s=47 Kazuto Kusama
December 07, 2021

 k8sとVaultを組み合わせてシークレットをもっとセキュアに

Kubernetes Novice Tokyo #15 で発表した資料です。
KubernetesとHashiCorp Vaultを組み合わせて良い感じにSecretの管理ができるんだよという話をしました

Cbc297b07593321e52c75a9ebcc0f843?s=128

Kazuto Kusama

December 07, 2021
Tweet

More Decks by Kazuto Kusama

Other Decks in Technology

Transcript

  1. Copyright © 2021 HashiCorp k8sとVaultを組み合わせて シークレットを もっとセキュアに

  2. Copyright © 2021 HashiCorp 草間一人 Sr. Solutions Engineer @jacopen Kazuto

    Kusama
  3. 大事なもの ちゃんと管理してますか?

  4. 大事なもの is 何 ▪ Cloud ProviderのAccess key/secretとか ▪ API Tokenとか

    ▪ DBのuser/passとか ▪ SSHの鍵とか ▪ TLSの証明書と鍵とか
  5. ちゃんと管理 is 何 AWSのAccess key/ secret access key データベースのメンテナンス用 User/Pass

    SSHのAuthorized keys *** / *** *** / *** それぞれがKeyを 手元で管理している メンテ用のuser/pass を共有している 各ユーザーの公開鍵 をauthorized_keysに 設定している
  6. ちゃんと管理 is 何 AWSのAccess key/ secret access key データベースのメンテナンス用 User/Pass

    SSHのAuthorized keys *** / *** *** / *** 間違えてgitに コミットしちゃった! 退職してもメンテ用パ スワードは内緒にね ! 退職した人の公開鍵 が登録されたまま つまり ちゃんと管理 できてない状態
  7. ちなみにk8sの場合、 どう管理するんでしたっけ?

  8. ちなみにk8sの場合、 どう管理するんでしたっけ? kind: Secret apiVersion: v1 data: username: YWRtaW4= password:

    MWYyZDFlMmU2N2Rm metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: { ... } creationTimestamp: 2016-01-22T18:41:56Z name: mysecret namespace: default resourceVersion: "164619" uid: cfee02d6-c137-11e5-8d73-42010af00002 type: Opaque
  9. ちなみにk8sの場合、 どう管理するんでしたっけ? kind: Secret apiVersion: v1 data: username: YWRtaW4= password:

    MWYyZDFlMmU2N2Rm metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: { ... } creationTimestamp: 2016-01-22T18:41:56Z name: mysecret namespace: default resourceVersion: "164619" uid: cfee02d6-c137-11e5-8d73-42010af00002 type: Opaque “admin” “1f2d1e2e67df” Base64エンコードされているだけ。Git等に入れるのはNG
  10. せっかくGitOpsにしたのに Secret Secret

  11. せっかくGitOpsにしたのに Secret Secret 間違えてgitに コミットしちゃった! あの鍵って誰が 管理してるの?

  12. Secret sprawl バラバラに保管 アプリごと/チームごと バラバラの アクセスフロー アクセスのコント ロールができない

  13. よくあるインシデント アクセスキーが漏洩 大量のインスタンスを 作成してマイニング とんでもない請求

  14. よくあるインシデント アクセスキーが漏洩 大量のインスタンスを 作成してマイニング とんでもない請求 どこから漏れたか 分かっていれば 対策はできるけど…

  15. Secretのジレンマ ▪ Secretが大事なことは誰もが分かってる ▪ だから既存の自動化フローには載せず、特別対応 – 一部の人だけが手元で厳重に管理 – 権限を絞ったプライベートリポジトリで管理 –

    権限を絞ったSpreadsheetで管理 ▪ しかしこの特別対応こそが、Secret Sprawlを生みセキュリティを低 下させる – 人間が把握できる範囲には限界がある – 人間はミスをする
  16. ちゃんと管理しましょう!

  17. Secret管理のベストプラクティス ・定期的なローテーション ・利用者に応じた細かな権限管理 ・監査記録 ・暗号化 AWS https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws-access-keys-best-practices.html Azure https://docs.microsoft.com/ja-jp/azure/architecture/framework/security/design-storage-keys GCP

    https://cloud.google.com/secret-manager?hl=ja
  18. アイデンティティベースの シークレットと暗号化の管理システム これまで挙げたような、扱いに悩むシークレットを “ちゃんと” 管理するためのシステム OSSで提供されているほか、商用版のVault EnterpriseやHCP VaultというManaged Serviceも あります。

  19. 僕たちが欲しいもの シークレットを”ちゃん と管理”できること

  20. 僕たちが欲しいもの 暗号化され安全に 管理されている 追加・削除がすぐ出 来る

  21. 僕たちが欲しいもの 誰が使っているか を特定できる 利用者ごとにポリ シーを設定出来る Admin アプリ

  22. 僕たちが欲しいもの 安全に 使える 効率的に 使える

  23. k8sに限らず、ありとあらゆるケースで活用可能 今回はk8s+Vaultの組み合わせを中心に紹介

  24. 利用方法 or or Server ここで集中管理

  25. 利用方法 or or Server CLI GUI API Interface Client Admin

    アプリ CI/CD さまざまな人/システムが、さま ざまな方法でアクセス
  26. デプロイ方法 Helmを使ってk8sの中に セットアップ

  27. デプロイ方法 k8sの外に建てたVaultと連携

  28. デプロイ方法 HCP VaultだとHashiCorp ManagedなVaultが使える

  29. デプロイ方法 Vault間でReplication

  30. 認証 Otka JWT/OIDC LDAP Azure AD AWS IAM GitHub Token

    etc… AppRole Kubernetes TLS Certs
  31. シンプルな例 - KV Secrets Engine GUIもしくはCLIでVaultに値を保存 vault kv put kv/secret/path

    foo=bar or GUI CLI foo=bar
  32. アプリからアクセス (API) foo=bar アプリ foo=bar API

  33. Kubernetesを経由してアプリに渡す foo=bar アプリ vault-agent foo=bar foo=bar init-container or Sidecar

  34. Kubernetesを経由してアプリに渡す Vault Agent InjectorをKubernetes 上にセットアップ。Helmでインストー ル可能 Mutating webhookでPodにInit containerやSidecarを追加してくれ る

  35. CODE EDITOR {{- with secret "internal/data/database/config" -}} postgresql://{{ .Data.data.username }}:{{

    .Data.data.password }}@postgres:5432/wizard {{- end -}}
  36. CODE EDITOR spec: template: metadata: annotations: vault.hashicorp.com/agent-inject: "true" vault.hashicorp.com/agent-inject-status: "update"

    vault.hashicorp.com/role: "internal-app" vault.hashicorp.com/agent-inject-secret-database-config.txt: "internal/data/database/config" vault.hashicorp.com/agent-inject-template-database-config.txt: | {{- with secret "internal/data/database/config" -}} postgresql://{{ .Data.data.username }}:{{ .Data.data.password }}@postgres:5432/wizard {{- end -}}
  37. TERMINAL > kubectl exec payroll --container payroll \ -- cat

    /vault/secrets/database-config.txt postgresql://db-readonly-user:db-secret-password@postgres:5432/wizard Render されたTemplate
  38. Kubernetesを経由してアプリに渡す (CSI Provider) foo=bar アプリ CSI Provider foo=bar foo=bar ボリュームとして

    Podにマウント
  39. Kubernetesを経由してアプリに渡す (CSI Provider)

  40. Kubernetesを経由してアプリに渡す (Kubernetes External Secrets) https://github.com/external-secrets/kubernetes-external-secrets External Secrets Controller Secrets foo=bar

    foo=bar kube-apiserver External Secrets
  41. External Secrets Operator ▪ 前述のKubernetes External Secrets (KES)は メンテナンスモードに ▪

    後継のExternal Secrets Operatorが登場 – https://github.com/external-secrets/external-secrets – Vaultにも対応 – まだ試したことないので誰か教えてください
  42. 便利さは分かったけど ほかの選択肢もあるよね?

  43. Vaultの醍醐味は Dynamic Secretにあり

  44. データベースのメンテナンス Maintenance User/Pass Maintenance User/Pass

  45. データベースのメンテナンス(Dynamic Secret) Temporary User/Pass ログ Database Secret Engine

  46. CI/CDからクラウドの利用 Cloud Provider IAM Test & Build Deploy CI/CDツール

  47. CI/CDからクラウドの利用(Dynamic Secret) Temporary IAM Test & Build Deploy CI/CDツール AWS

    Secret Engine Azure, GCPにも対応
  48. 外部の運用者からの利用 内部の人 外部の人 Cloud Provider IAM 作成 & 権限設定

  49. 外部の運用者からの利用(Dynamic Secret) 内部の人 外部の人 Temporary IAM Account 権限、TTL設定 TTLが設定出来るので、一定時間経 つと自動で無効になる

  50. さらにこんなのも

  51. PKI ルート認証局 X.509証明書 • Vault を中間認証局として設定 • 認証や暗号化通信に必要な署名済みの X.509証明書を動的に発行 X.509証明書

    Signed X.509証明書 Lease Lease Application A Application B 中間認証局
  52. Cert-manager apiVersion: cert-manager.io/v1 kind: Issuer metadata: name: vault-issuer namespace: sandbox

    spec: vault: path: pki_int/sign/example-dot-com server: https://vault.local caBundle: <base64 encoded CA Bundle PEM file> auth: ... apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: app-cert spec: dnsNames: - '*.example.local' issuerRef: kind: ClusterIssuer name: vault-issuer secretName: app-cert
  53. Encryption as a Service • データの暗号化/復号の中継地点 暗号化/復号 Application A Application

    B PII PII = Personal Identifiable Information PII 暗号化 復号 暗号鍵 PII PII データベース 書き込み 読み出し
  54. OIDC Provider ▪ Vault 1.9からの新機能(Tech Preview) ▪ VaultがOIDCのIdPとして振る舞える https://www.vaultproject.io/docs/secrets/identity/oidc-provider

  55. 紹介しきれないので まずは触ってみて! $ vault server -dev

  56. Vault Users Group発足 & Meetupやります! ▪ #vugjp ▪ 12/16 19:00

    - https://vault.connpass.com/event/228646/
  57. 3/11 (金) 開催! 来週からCFP開始!

  58. Thank You hello@hashicorp.com www.hashicorp.com