![Vaultへの認証フローとポリシー
24
Client
$ curl --request POST
http://127.0.0.1:8200/v1/auth/github/login
organization=hashicorp
team=team-a
Role: mysql-client-policy
path "mysql/*" {
capabilities = [ "read", "create", "delete"]
}
$ vault login -method=github
Vault
Token
GitHub Token](https://image.slidesharecdn.com/hashicorpvault-191111145054/85/HashiCorp-Vault-24-320.jpg)
HashiCorp Vault 紹介
- 1. Copyright © 2019 HashiCorp HashiCorp Vaultによる シークレット管理と データプロテクション
- 2. © 2018 HashiCorp Networking Connect infrastructure and applications Development Run applications Security Secure applications and infrastructure Operations Provision Infrastructure The 4 essential elements of dynamic infrastructure 2THE HASHICORP STACK
- 3. © 2018 HashiCorp Connect THE HASHICORP STACK Infrastructure and applications Development Run applications Security Secure infrastructure and applications Operations Provision infrastructure The 4 essential elements of distributed infrastructure 3
- 4. アジェンダ ● HashiCorp Vaultとは ● Vaultのユースケース ○ シークレット管理 ○ データプロテクション
- 5. HashiCorp Vault とは https://www.vaultproject.io ● シークレットのライフサイクルの集中管理 ● データプロテクション : API-Drivenな暗号化 ● 20+ のシークレットに対応 ○ Database, RabbitMQ, Public Clouds, SSH, PKI
- 6. About Vault 500+ 顧客数 1M+ 月間ダウンロード数 10.4K+ Github スター 2T+ トランザクション プロダクトローンチ2014
- 13. 人的ミスによるシークレットリーク 13 spring.datasource.url = jdbc:postgresql://kabuctl.run/database spring.datasource.username = foo spring.datasource.password = bar variable "access_key" { default = xxxxx } variable "secret_key" { default = xxxxx } apiVersion: apps/v1 kind: Deployment ~~~~ containers: - name: subscriber image: gcr.io/google-samples/pubsub-sample:v1 volumeMounts: - name: google-cloud-key mountPath: /var/secrets/google env: - name: GOOGLE_APPLICATION_CREDENTIALS value: /var/secrets/google/key.json
- 17. ● クラウドネイティブ, DevOps, Microservices ● ツール、アプリや環境 ● 重要なシークレット 運用コスト セキュリティ
- 18. • 多くのシークレットが存在しており、セキュアに管理されていない • シークレット管理のコストが高い • シークレットへのアクセス管理が出来ていない • シークレットの動的な発行やローテーションを行うのが困難である • シークレット管理や暗号化に関するガバナンスが効いていない • クラウド、Dynamicな環境に対応した既存のツールがない Vault Origins
- 19. シークレット管理 データプロテクション Vaultのユースケース シークレット(トークン、パスワード、証明書や暗号化キー)の 中央集権的な生成、保存、提供 データ暗号化のためのシンプルなAPIと暗号化のキー管理の機能 を提供し、アプリケーションのデータをセキュアに保つ ＊シークレットとは認証認可を与えるものの総称で DBクレデンシャル、クラウドの IAM、トークン、 TLS証明書、ID&パスワード、SSH Keyなどを指します
- 20. Vaultによるシークレット管理 ● パスワードの使い回し ● 同一シークレットの長期利用 ● アプリなどのクライアントのコンフィグに重 要なシークレットを記入 ● クラウドのアカウント乱立 ● シークレットのエクセル管理 ● シークレットのシングルレポジトリ ● Vaultから様々なシークレットを発行 ● 期限(TTL)付与しシークレットのライフサイ クルをコントロール ● プラットフォームフリー ● 監査ログにて全てのシークレットの発行状 況やアクセス状況を把握 よくある一般的な運用 Vaultによるシークレット管理 シークレット管理の手間や、 同じシークレットを長期間利用し続ける ことのリスク クラウドアカウントの統制が効かない シークレット管理を改善し、 短期間で新しいシークレットを発行
- 21. Vaultによるシークレット管理ワークフロー Client Backend シークレット要 求 シークレット発行 TTL=1hour シークレット提 供 TTL後 シークレット破棄 Token Terminal $ vault read database/creds/mysql-role → VaultがDatabaseのSQLを実行し、ユーザとパスワードを発行 $ vault read aws/creds/vpc-admin → VaultがAWS API実行し、IAMキーを発行 $ vault read ssh/role/otp → VaultがVM上でシェルを実行し、 SSHパスワードを発行 $ vault write pki_intermediate/issue/kabuctl-dot-run common_name="blog.kabuctl.run" → Vaultが認証局となり、証明書を発行
- 22. Vault Dynamic Secrets Principals 22 ● あらゆる外部サービスのシークレット管理を集約し、自動化 ● リクエストに応じてオンデマンドで必要最低限のTTLのシークレットを生成 ● クライアントはVaultに対して最低限のアクセスレベルを有する ● 動的にシークレットを破棄する ● 全てのシークレットの全てライフサイクルは監査可能である
- 23. Secrets Management: Secret Engines
- 24. Vaultへの認証フローとポリシー 24 Client $ curl --request POST http://127.0.0.1:8200/v1/auth/github/login organization=hashicorp team=team-a Role: mysql-client-policy path "mysql/*" { capabilities = [ "read", "create", "delete"] } $ vault login -method=github Vault Token GitHub Token
- 26. application.properties spring.datasource.url = jdbc:postgresql://kabuctl.run/database spring.datasource.username = foo spring.datasource.password = bar pipeline.yml jobs: - name: hello-world plan: - task: say-hello params: MY_SECRET: P@$$w0rd クライアントの変化の例 Before After application.properties spring: cloud: vault: uri: VAULT_ADDR token: TOKEN mysql: enabled: true role: my-role backend: database datasource: url: jdbc:mysql://127.0.0.1:3306
- 27. シークレット管理 データプロテクション Vaultのユースケース シークレット(トークン、パスワード、証明書や暗号化キー)の 中央集権的な生成、保存、提供 データ暗号化のためのシンプルなAPIと暗号化のキー管理の機能 を提供し、アプリケーションのデータをセキュアに保つ ＊シークレットとは認証認可を与えるものの総称で DBクレデンシャル、クラウドの IAM、トークン、 TLS証明書、ID&パスワード、SSH Keyなどを指します
- 28. ● アプリ毎にロジックを作成 ● 鍵ローテーションの運用が決まっていな い ● 暗号化ロジックの開発者に依存したメン テナンス ● HSMを利用していてコストが高い ● VaultによるHTTP APIで暗号化が可能 （機能追加が簡単） ● 鍵の運用やローテーションも考慮不要 （Vaultが対応） ● 複数の暗号化ロジックから選択可能 ● ソフトウェアなのでスケーラブル よくある一般的な運用 Vaultによる暗号化 暗号化の手法や品質が開発者に依存、 キーの管理コストが高い、 もしくはそもそも管理されていない APIドリブンな安全で高品質な暗号化、 キーのライフサイクル管理を Vaultに委託 Vaultによる個人情報などのデータ暗号化
- 32. Vault Enterprise 機能名 概要 DR Replication Vaultクラスター間でトークン、シークレットやキーを含めたレプリケーションを し可用性を向上 Performance Replication Vaultクラスター間でシークレットなどをレプリケーションし、複数クラスタで リードを処理しパフォーマンスを向上 Performance Standby 1クラスタ内で複数のリードノードを立てパフォーマンスを向上 Control Groups Response Wrapping Tokenにアクセスする際に認証フローを入れセキュ リティを向上 HSM Auto-unseal Hardware Security Moduleによる自動unseal Replication Filters クラスタ間でレプリケーションするデータの条件を指定してフィルタリングをす る Policy as Code (Sentinel) SentinelによるVault APIコール等に関するポリシーの設定 Multi Factor Authentication Vaultへの多要素の認証
- 33. Key takeaways ● Vaultで運用コストを抑えつつより強固なセキュリティを ○ マルチクラウドやダイナミックな環境のシークレット管理ならVault ! ○ アプリに透過的なAPI-Driveな暗号化やキー管理ならVault !!
- 34. Performance Standby EnterpriseOSS ActiveStandby Standby read write read write read write ActivePerf Standby Perf Standby read write read write read write Cluster Cluster
- 35. DR Replication Vault Active cluster (Primary cluster) Vault Standby Cluster (Secondary) Token, configuration, Secretな どのレプリケーション Vault Standby cluster
- 36. Performance Replication Vault Active cluster (Primary cluster) Vault Perf Standby cluster (Secondary cluster) Vault Perf Standby cluster (Secondarymary cluster) read read read write write write Configuration Secrets Configuration Secrets Configuration Secrets 転送 転送 複製 複製
- 37. DR ReplicationとPerformance Replication Header DR Replication Performance Replication プライマリクラスタのコングレーションのミラーリング Yes Yes 認証やシークレットエンジンなどのプライマリのバックエンドの コンフィグのミラーリング Yes Yes リースやトークンまたはプライマリクラスタとインタラクションを しているユーザのミラーリング Yes No. セカンダリクラスタは独自のデータを持つため、セカ ンダリがプロモーションするときにアプリやサイド認 証をし、新しいプライマリから再度リースやトークンを 取得する セカンダリクラスタがリクエストを処理できるか Yes Yes
- 38. Policy as Code (Sentinel) ● 通常のACLの設定に加えてVaultの安全性を保つためにより高度で柔軟な設 定を実現する ○ Role Governing Policies (RGPs) ■ 特定のトークンやIDに関連付けるポリシー ○ Endpoint Governing Policies (EGPs) ■ Vaultの特定のエンドポイントに関連付けるポリシー