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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

大事なものちゃんと管理してますか？

Slide 4

Slide 4 text

大事なもの is 何 ▪ Cloud ProviderのAccess key/secretとか ▪ API Tokenとか ▪ DBのuser/passとか ▪ SSHの鍵とか ▪ TLSの証明書と鍵とか

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

ちゃんと管理 is 何 AWSのAccess key/ secret access key データベースのメンテナンス用 User/Pass SSHのAuthorized keys *** / *** *** / *** 間違えてgitにコミットしちゃった！退職してもメンテ用パスワードは内緒にね ! 退職した人の公開鍵が登録されたままつまりちゃんと管理できてない状態

Slide 7

Slide 7 text

ちなみにk8sの場合、どう管理するんでしたっけ？

Slide 8

Slide 8 text

ちなみに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

Slide 9

Slide 9 text

Slide 10

Slide 10 text

せっかくGitOpsにしたのに Secret Secret

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

Secretのジレンマ ▪ Secretが大事なことは誰もが分かってる ▪ だから既存の自動化フローには載せず、特別対応 – 一部の人だけが手元で厳重に管理 – 権限を絞ったプライベートリポジトリで管理 – 権限を絞ったSpreadsheetで管理 ▪ しかしこの特別対応こそが、Secret Sprawlを生みセキュリティを低下させる – 人間が把握できる範囲には限界がある – 人間はミスをする

Slide 16

Slide 16 text

ちゃんと管理しましょう！

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

利用方法 or or Server CLI GUI API Interface Client Admin アプリ CI/CD さまざまな人/システムが、さまざまな方法でアクセス

Slide 26

Slide 26 text

デプロイ方法 Helmを使ってk8sの中にセットアップ

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

デプロイ方法 Vault間でReplication

Slide 30

Slide 30 text

認証 Otka JWT/OIDC LDAP Azure AD AWS IAM GitHub Token etc… AppRole Kubernetes TLS Certs

Slide 31

Slide 31 text

シンプルな例 - KV Secrets Engine GUIもしくはCLIでVaultに値を保存 vault kv put kv/secret/path foo=bar or GUI CLI foo=bar

Slide 32

Slide 32 text

アプリからアクセス (API) foo=bar アプリ foo=bar API

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

CODE EDITOR {{- with secret "internal/data/database/config" -}} postgresql://{{ .Data.data.username }}:{{ .Data.data.password }}@postgres:5432/wizard {{- end -}}

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

TERMINAL > kubectl exec payroll --container payroll \ -- cat /vault/secrets/database-config.txt postgresql://db-readonly-user:db-secret-password@postgres:5432/wizard Render されたTemplate

Slide 38

Slide 38 text

Kubernetesを経由してアプリに渡す (CSI Provider) foo=bar アプリ CSI Provider foo=bar foo=bar ボリュームとして Podにマウント

Slide 39

Slide 39 text

Kubernetesを経由してアプリに渡す (CSI Provider)

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

External Secrets Operator ▪ 前述のKubernetes External Secrets (KES)はメンテナンスモードに ▪ 後継のExternal Secrets Operatorが登場 – https://github.com/external-secrets/external-secrets – Vaultにも対応 – まだ試したことないので誰か教えてください

Slide 42

Slide 42 text

便利さは分かったけどほかの選択肢もあるよね？

Slide 43

Slide 43 text

Vaultの醍醐味は Dynamic Secretにあり

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

CI/CDからクラウドの利用(Dynamic Secret) Temporary IAM Test ＆ Build Deploy CI/CDツール AWS Secret Engine Azure, GCPにも対応

Slide 48

Slide 48 text

外部の運用者からの利用内部の人外部の人 Cloud Provider IAM 作成 & 権限設定

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

さらにこんなのも

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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: 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

Slide 53

Slide 53 text

Encryption as a Service ● データの暗号化/復号の中継地点暗号化/復号 Application A Application B PII PII = Personal Identiﬁable Information PII 暗号化復号暗号鍵 PII PII データベース書き込み読み出し

Slide 54

Slide 54 text

OIDC Provider ▪ Vault 1.9からの新機能(Tech Preview) ▪ VaultがOIDCのIdPとして振る舞える https://www.vaultproject.io/docs/secrets/identity/oidc-provider

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

Vault Users Group発足 & Meetupやります！ ▪ #vugjp ▪ 12/16 19:00 - https://vault.connpass.com/event/228646/