$30 off During Our Annual Pro Sale. View Details »

改めて学ぶ、Vaultの基本

Kazuto Kusama
December 16, 2021

 改めて学ぶ、Vaultの基本

Vault Meetup #1で発表した資料です。
HashiCorp Vaultって何をするもの?どう便利なのか?をまとめました。

Kazuto Kusama

December 16, 2021
Tweet

More Decks by Kazuto Kusama

Other Decks in Technology

Transcript

  1. Copyright © 2021 HashiCorp
    改めて学ぶ
    Vaultのキホン

    View Slide

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

    View Slide

  3. これから話すこと
    ▪ HashiCorp Vaultって何だっけ? 何が便利なんだっけ? という話
    をします
    ▪ Vaultを知らない、もしくは名前は知っているけど
    活用はこれからという人向けです
    ▪ 既にバリバリ使っている人には既知の話が多いです
    – Vaultの必要性を他の人に説明するときの
    説明方法の一つとして見てもらうといいかも

    View Slide

  4. Vault is 何
    アイデンティティベースの
    シークレットと暗号化の管理システム

    View Slide

  5. いきなりなんですが
    みなさん
    は好きですか?

    View Slide

  6. いきなりなんですが
    みなさん
    は好きですか?
    好きです! #vugjp
    毎日使ってます! #vugjp
    無いと仕事にならないです! #vugjp

    View Slide

  7. Terraform Providers
    IaaS Network
    Middleware
    Orchestrators

    View Slide

  8. いろんな環境をTerraformでIaC
    いろんなサービスやプラットフォームを活用していく
    のが “クラウドネイティブ時代 ” っぽい

    View Slide

  9. でも、新たな悩みが・・・ どのサービスも、API Tokenや
    Access Key、
    User/Passwordなど
    Credentialを必要とする

    View Slide

  10. ちゃんと管理してますか?

    View Slide

  11. 管理する必要のあるもの
    ▪ Cloud ProviderのAccess key/secretとか
    ▪ API Tokenとか
    ▪ DBのuser/passとか
    ▪ SSHの鍵とか
    ▪ TLSの証明書と鍵とか

    View Slide

  12. AWSのAccess key/ secret access key
    データベースのメンテナンス用
    User/Pass
    SSHのAuthorized keys
    *** / ***
    *** / ***
    それぞれがKeyを
    手元で管理している
    メンテ用のuser/pass
    を共有している
    各ユーザーの公開鍵
    をauthorized_keysに
    設定している
    パスワード制限した
    台帳で管理している

    View Slide

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

    View Slide

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

    View Slide

  15. クラウド時代の秘密情報の管理
    従来の秘密情報の管理
    ● ネットワークの境界を中と外で明確に分

    ● 自社が管理する信頼性の高いネット
    ワークを前提に管理
    クラウド時代においては・・・
    ● IaaS, SaaSベンダーが管理するネットワー
    クとデータセンターの相互運用
    ● ネットワークの境界が曖昧になり、
    Identityベースでの管理が必要
    静的なインフラ環境 動的なインフラ環境

    View Slide

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

    View Slide

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

    View Slide

  18. 管理を怠ると何が起こる?
    例えば・・・
    ▪ どこからかクラウドプロバイダーのキーが流出し、DBインスタンス
    のマスターパスワードが変更され、中にあった
    個人情報が流出
    ▪ オブジェクトストレージのアクセスキーが流出し、
    研究データが他国に流出
    やばい

    View Slide

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

    View Slide

  20. ちゃんと管理しましょう!

    View Slide

  21. 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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  27. The Tao of HashiCorp
    Workflows, not Technologies
    HashiCorpのアプローチは、根底にある技術より、むしろ ワークフ
    ローの最終ゴールに焦点をあてています 。ソフトウェアやハード
    ウェアは進化し、改善されていくものですが、我々の目標は、新し
    いツールの導入を簡単にし、かつ可能な限り合理的なユーザー
    体験を提供することにあります。我々の製品設計は、目標を達成
    するためのワークフローを想像するところから始まります。次に、
    ワークフローを単純化するための既存のツールを探します。
    もし十分なツールが存在ければ、我々がそれを作ります。このよ
    うにして、我々は基本的に技術にとらわれない考え方をしていま
    す。
    技術が進化し、より優れたツールが登場すれば、理想的なワーク
    フローは更新されます。技術が変わっても、最終的な目標は変わ
    りません。

    View Slide

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

    View Slide

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

    View Slide

  30. デプロイ方法
    Vaultのバイナリを起動
    (1バイナリなのでセットアップも比較
    的容易)

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  49. CI/CDからクラウドの利用
    Cloud
    Provider
    IAM
    Test

    Build
    Deploy
    CI/CDツール

    View Slide

  50. CI/CDからクラウドの利用(Dynamic Secret)
    Temporary
    IAM
    Test

    Build
    Deploy
    CI/CDツール
    AWS Secret Engine
    Azure, GCPにも対応

    View Slide

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

    View Slide

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

    View Slide

  53. さらにこんなのも

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  57. Vaultの暗号化機能の活用例
    アプリ
    S3
    #1 データ
    の暗号化
    #2 暗号
    データを格

    悪意のある内部ユーザ

    AWSの権限だけではデータを
    取ることはできない
    研究データ
    個人情報

    View Slide

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

    View Slide

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

    View Slide

  60. View Slide

  61. ドキュメント & HashiCorp Learn

    View Slide

  62. 日本語版ワークショップ

    View Slide

  63. 質問チャンネル
    Slack
    #question

    View Slide

  64. Thank You
    [email protected]
    www.hashicorp.com

    View Slide