Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
改めて学ぶ、Vaultの基本
Search
Kazuto Kusama
December 16, 2021
Technology
1
1k
改めて学ぶ、Vaultの基本
Vault Meetup #1で発表した資料です。
HashiCorp Vaultって何をするもの?どう便利なのか?をまとめました。
Kazuto Kusama
December 16, 2021
Tweet
Share
More Decks by Kazuto Kusama
See All by Kazuto Kusama
「共通基盤」を超えよ! 今、Platform Engineeringに取り組むべき理由
jacopen
25
5.9k
いろんな外資、いろんなロールで働いてみた話
jacopen
14
4.6k
サービスの危機に立ち向かうリーダーシップ~インシデントコマンダーの役割と戦略~
jacopen
20
6k
5分でわかる(かもしれない)Platform Engineering
jacopen
4
720
ChatOpsで回す、クラウドネイティブな組織運営
jacopen
1
190
2024年のPlatform Engineeringはこうなる(なってほしい)
jacopen
7
3.6k
技術の洪水に立ち向かう: 開発者の心を軽くするプラットフォームエンジニアリングの話
jacopen
12
6.3k
プラットフォーム名決めるのも、ロゴ作るのも、プラットフォームチームの仕事です
jacopen
3
180
CNCFが考えるPlatform - Platforms White Paperについて
jacopen
2
1k
Other Decks in Technology
See All in Technology
入社後初めてのタスクでk8sアップグレードした話.pdf
kkato1
1
380
LLM とプロンプトエンジニアリング/チューターをビルドする / LLM and Prompt Engineering and Building Tutors
ks91
PRO
0
220
AWS を使う上で知っておきたいオンプレミス知識/aws-on-premise-essentials
emiki
1
4.2k
HEXA OSINT CTF V3 作戦会議
meow_noisy
0
110
プロデザ! BY リクルート vol.18_リクルートのリサーチ実践組織「リサーチブーストコミュニティ」
recruitengineers
PRO
3
240
クラウドサインにおけるプロダクトマネージャーの役割と開発プロセス / 20240410_cloudsign-PdM
bengo4com
1
680
Aurora MySQL v3(MySQL8.0互換)の オンラインDDLの罠挙動を全バージョンで検証した
yutakikai
1
150
オブザーバビリティの Primary Signals
onk
PRO
0
550
インシデントレスポンスのライフサイクルを廻すポイントってなに / Pinpoints of Incidentresponse Lifecycle for Operation
sakaitakeshi
1
300
自動生成を活用した、運用保守コストを抑える Error/Alert/Runbook の一元集約管理 / Centralized management of Error/Alert/Runbook to minimize operational costs using automated code generation
biwashi
9
2.1k
シン・Kafka / shin-kafka
oracle4engineer
PRO
7
2.7k
ユーザーストーリーのレビューを自動化したみたの
bun913
1
330
Featured
See All Featured
Optimising Largest Contentful Paint
csswizardry
7
2.3k
Designing Experiences People Love
moore
136
23k
A Philosophy of Restraint
colly
196
16k
Being A Developer After 40
akosma
56
580k
The World Runs on Bad Software
bkeepers
PRO
61
6.7k
How to train your dragon (web standard)
notwaldorf
72
5.1k
RailsConf 2023
tenderlove
2
530
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
12
1.5k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
5
1.5k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
15
1.4k
10 Git Anti Patterns You Should be Aware of
lemiorhan
646
57k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3k
Transcript
Copyright © 2021 HashiCorp 改めて学ぶ Vaultのキホン
Copyright © 2021 HashiCorp 草間一人 Sr. Solutions Engineer @jacopen Kazuto
Kusama
これから話すこと ▪ HashiCorp Vaultって何だっけ? 何が便利なんだっけ? という話 をします ▪ Vaultを知らない、もしくは名前は知っているけど 活用はこれからという人向けです
▪ 既にバリバリ使っている人には既知の話が多いです – Vaultの必要性を他の人に説明するときの 説明方法の一つとして見てもらうといいかも
Vault is 何 アイデンティティベースの シークレットと暗号化の管理システム
いきなりなんですが みなさん は好きですか?
いきなりなんですが みなさん は好きですか? 好きです! #vugjp 毎日使ってます! #vugjp 無いと仕事にならないです! #vugjp
Terraform Providers IaaS Network Middleware Orchestrators
いろんな環境をTerraformでIaC いろんなサービスやプラットフォームを活用していく のが “クラウドネイティブ時代 ” っぽい
でも、新たな悩みが・・・ どのサービスも、API Tokenや Access Key、 User/Passwordなど Credentialを必要とする
ちゃんと管理してますか?
管理する必要のあるもの ▪ Cloud ProviderのAccess key/secretとか ▪ API Tokenとか ▪ DBのuser/passとか
▪ SSHの鍵とか ▪ TLSの証明書と鍵とか
AWSのAccess key/ secret access key データベースのメンテナンス用 User/Pass SSHのAuthorized keys ***
/ *** *** / *** それぞれがKeyを 手元で管理している メンテ用のuser/pass を共有している 各ユーザーの公開鍵 をauthorized_keysに 設定している パスワード制限した 台帳で管理している
AWSのAccess key/ secret access key データベースのメンテナンス用 User/Pass SSHのAuthorized keys ***
/ *** *** / *** 間違えてgitに コミットしちゃった! 退職してもメンテ用パ スワードは内緒にね ! 退職した人の公開鍵 が登録されたまま つまり ちゃんと管理 できてない状態 何者かによって 台帳の中身が流出
Secret sprawl バラバラに保管 アプリごと/チームごと バラバラの アクセスフロー アクセスのコント ロールができない
クラウド時代の秘密情報の管理 従来の秘密情報の管理 • ネットワークの境界を中と外で明確に分 割 • 自社が管理する信頼性の高いネット ワークを前提に管理 クラウド時代においては・・・ •
IaaS, SaaSベンダーが管理するネットワー クとデータセンターの相互運用 • ネットワークの境界が曖昧になり、 Identityベースでの管理が必要 静的なインフラ環境 動的なインフラ環境
よくあるインシデント アクセスキーが漏洩 大量のインスタンスを 作成してマイニング とんでもない請求
よくあるインシデント アクセスキーが漏洩 大量のインスタンスを 作成してマイニング とんでもない請求 どこから漏れたか 分かっていれば 対策はできるけど…
管理を怠ると何が起こる? 例えば・・・ ▪ どこからかクラウドプロバイダーのキーが流出し、DBインスタンス のマスターパスワードが変更され、中にあった 個人情報が流出 ▪ オブジェクトストレージのアクセスキーが流出し、 研究データが他国に流出 やばい
Secretのジレンマ ▪ Secretが大事なことは誰もが分かってる ▪ だから既存の自動化フローには載せず、特別対応 – 一部の人だけが手元で厳重に管理 – 権限を絞ったプライベートリポジトリで管理 –
権限を絞ったSpreadsheetで管理 ▪ しかしこの特別対応こそが、Secret Sprawlを生みセキュリティを低 下させる – 人間が把握できる範囲には限界がある – 人間はミスをする
ちゃんと管理しましょう!
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
アイデンティティベースの シークレットと暗号化の管理システム これまで挙げたような、扱いに悩むシークレットを “ちゃんと” 管理するためのシステム OSSで提供されているほか、商用版のVault EnterpriseやHCP VaultというManaged Serviceも あります。
僕たちが欲しいもの シークレットを”ちゃん と管理”できること
僕たちが欲しいもの 暗号化され安全に 管理されている 追加・削除がすぐ出 来る
僕たちが欲しいもの 誰が使っているか を特定できる 利用者ごとにポリ シーを設定出来る Admin アプリ
僕たちが欲しいもの 安全に 使える 効率的に 使える
The Tao of HashiCorp Workflows, not Technologies HashiCorpのアプローチは、根底にある技術より、むしろ ワークフ ローの最終ゴールに焦点をあてています
。ソフトウェアやハード ウェアは進化し、改善されていくものですが、我々の目標は、新し いツールの導入を簡単にし、かつ可能な限り合理的なユーザー 体験を提供することにあります。我々の製品設計は、目標を達成 するためのワークフローを想像するところから始まります。次に、 ワークフローを単純化するための既存のツールを探します。 もし十分なツールが存在ければ、我々がそれを作ります。このよ うにして、我々は基本的に技術にとらわれない考え方をしていま す。 技術が進化し、より優れたツールが登場すれば、理想的なワーク フローは更新されます。技術が変わっても、最終的な目標は変わ りません。
利用方法 or or Server ここで集中管理
利用方法 or or Server CLI GUI API Interface Client Admin
アプリ CI/CD さまざまな人/システムが、さま ざまな方法でアクセス
デプロイ方法 Vaultのバイナリを起動 (1バイナリなのでセットアップも比較 的容易)
デプロイ方法 Helmを使ってk8sの中に セットアップ
デプロイ方法 HCP VaultだとHashiCorp ManagedなVaultが使える
デプロイ方法 Vault間でReplication
認証 Otka JWT/OIDC LDAP Azure AD AWS IAM GitHub Token
etc… AppRole Kubernetes TLS Certs
シンプルな例 - KV Secrets Engine GUIもしくはCLIでVaultに値を保存 vault kv put kv/secret/path
foo=bar or GUI CLI foo=bar
アプリからアクセス (API) foo=bar アプリ foo=bar API
Kubernetesを経由してアプリに渡す foo=bar アプリ vault-agent foo=bar foo=bar init-container or Sidecar
Kubernetesを経由してアプリに渡す Vault Agent InjectorをKubernetes 上にセットアップ。Helmでインストー ル可能 Mutating webhookでPodにInit containerやSidecarを追加してくれ る
CODE EDITOR {{- with secret "internal/data/database/config" -}} postgresql://{{ .Data.data.username }}:{{
.Data.data.password }}@postgres:5432/wizard {{- end -}}
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 -}}
TERMINAL > kubectl exec payroll --container payroll \ -- cat
/vault/secrets/database-config.txt postgresql://db-readonly-user:db-secret-password@postgres:5432/wizard Render されたTemplate
Kubernetesを経由してアプリに渡す (CSI Provider) foo=bar アプリ CSI Provider foo=bar foo=bar ボリュームとして
Podにマウント
Kubernetesを経由してアプリに渡す (CSI Provider)
Kubernetesを経由してアプリに渡す (Kubernetes External Secrets) https://github.com/external-secrets/kubernetes-external-secrets External Secrets Controller Secrets foo=bar
foo=bar kube-apiserver External Secrets
便利さは分かったけど ほかの選択肢もあるよね?
Vaultの醍醐味は Dynamic Secretにあり
データベースのメンテナンス Maintenance User/Pass Maintenance User/Pass
データベースのメンテナンス(Dynamic Secret) Temporary User/Pass ログ Database Secret Engine
CI/CDからクラウドの利用 Cloud Provider IAM Test & Build Deploy CI/CDツール
CI/CDからクラウドの利用(Dynamic Secret) Temporary IAM Test & Build Deploy CI/CDツール AWS
Secret Engine Azure, GCPにも対応
外部の運用者からの利用 内部の人 外部の人 Cloud Provider IAM 作成 & 権限設定
外部の運用者からの利用(Dynamic Secret) 内部の人 外部の人 Temporary IAM Account 権限、TTL設定 TTLが設定出来るので、一定時間経 つと自動で無効になる
さらにこんなのも
PKI ルート認証局 X.509証明書 • Vault を中間認証局として設定 • 認証や暗号化通信に必要な署名済みの X.509証明書を動的に発行 X.509証明書
Signed X.509証明書 Lease Lease Application A Application B 中間認証局
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
Encryption as a Service • データの暗号化/復号の中継地点 暗号化/復号 Application A Application
B PII PII = Personal Identifiable Information PII 暗号化 復号 暗号鍵 PII PII データベース 書き込み 読み出し
Vaultの暗号化機能の活用例 アプリ S3 #1 データ の暗号化 #2 暗号 データを格 納
悪意のある内部ユーザ ❌ AWSの権限だけではデータを 取ることはできない 研究データ 個人情報
OIDC Provider ▪ Vault 1.9からの新機能(Tech Preview) ▪ VaultがOIDCのIdPとして振る舞える https://www.vaultproject.io/docs/secrets/identity/oidc-provider
紹介しきれないので まずは触ってみよう! $ vault server -dev
None
ドキュメント & HashiCorp Learn
日本語版ワークショップ
質問チャンネル Slack #question
Thank You
[email protected]
www.hashicorp.com