Vault

https://gyazo.com/cc31262e128a6c2af426bb0ac321d9ad

A modern system requires access to a multitude of secrets, including database credentials, API keys for external services, credentials for service-oriented architecture communication, etc. It can be difficult to understand who is accessing which secrets, especially since this can be platform-specific. Adding on key rolling, secure storage, and detailed audit logs is almost impossible without a custom solution. This is where Vault steps in.

Vault validates and authorizes clients (users, machines, apps) before providing them access to secrets or stored sensitive data.

Quick Start

code: (bash)

export VAULT_NAMESPACE="admin"

vault login $VAULT_TOKEN

vault token lookup

Configuration

Seal

利用できる key

クラウド KMS

pkcs11

Enterprise のみ

transit

外部の Vault

token が必要

Migration

Restore は前の情報が必要なので、データだけマイグレする方法

Kubernetes

https://www.youtube.com/watch?v=b2iiZ16eI7A

Vault Agent Injector

Mutting webhook で Pod に initContainer や Sidecar を追加する

template 機能が使える

Vault CSI Provider

Secret を作成する

Pod を再起動しないと新しい Secret が反映されない

Auth Method

https://gyazo.com/c11f3cd4da79670363e4f4fe50a174ec

Vault にログインする方法

Vault 自身でも認証が必要

Kubernetes

Bootstrap

code: (bash)

# 初回起動後は init してから unseal する

# HA(Raft) の場合 Leader のみ実行

$ vault operator init -n 1 -t 1

Unseal Key 1: 8pyjFXuHV0b91mijvvZ8aPrro9hO/Oky//fdoJyD6vJe

Initial Root Token: hvs.gX08iEGzhj2TNLTVaK1Zk0kn

Vault initialized with 5 key shares and a key threshold of 3. Please securely

distribute the key shares printed above. When the Vault is re-sealed,

restarted, or stopped, you must supply at least 3 of these keys to unseal it

before it can start servicing requests.

Vault does not store the generated root key. Without at least 3 keys to

reconstruct the root key, Vault will remain permanently sealed!

It is possible to generate new unseal keys, provided you have a quorum of

existing unseal keys shares. See "vault operator rekey" for more information.

# 再起動時は seal されるので unseal する

# HA(Raft) の場合 Leader のみ実行

$ vault operator unseal # Unseal Key のいずれかを入力する

Unseal Key (will be hidden): # 上記でスキップした場合は、ここで Unseal Key のいずれかを入力する

Key Value

--- -----

Seal Type shamir

Initialized true

Sealed true

Total Shares 1 # Unseal Key の数(-n)

Threshold 1 # Unseal するための Key 数(-t)

Unseal Nonce d5c65d46-2fa3-1c31-bbee-3cc1941d2d65

Version 1.11.2

Build Date 2022-07-29T09:48:47Z

Storage Type file

HA Enabled false

# HA(Raft) の場合 Follower のみ実行

$ vault operator unseal

# vault-0

$ vault login

$ vault operator members list

ログイン確認

Seed

ENT 版なら自動スナップショット機能がある

code: (bash)

# kubernetes 認証方式を有効にする

vault auth enable kubernetes

# 認証設定をする

vault write auth/kubernetes/config \

kubernetes_ca_cert=@ca.crt # kubectl exec vault-0 -- cat /var/run/secrets/kubernetes.io/serviceaccount/ca.crt > ca.crt

# token_reviewer_jwt="<your service account JWT>" なくても OK

# role

vault write auth/kubernetes/role/argocd \

bound_service_account_names=argo-cd-argocd-repo-server \

bound_service_account_namespaces=argocd \

policies=argocd \

ttl=1h

kv

code: (bash)

# kv

vault secrets enable -path kv -version=2 kv

# policy

echo 'path "kv/*" {

}' | vault policy write argocd -

# example

vault kv put kv/example/example-auth password=changeme

transit

外部の Vault を利用して Auto Unseal するための key を作成する

code: (bash)

❯ vault secrets enable transit

Success! Enabled the transit secrets engine at: transit/

❯ vault write -f transit/keys/unseal_key

Success! Data written to: transit/keys/unseal_key

backup / restore

単一ファイルなのが嬉しい

新しいクラスターに restore する場合

初めに unseal と login をする

この時のトークンは一時的なものであり、リストアした後は以前のもので unseal と login する。

code: (bash)

# HA

vault operator raft snapshot save backup.snap

vault operator raft snapshot restore -force backup.snap

# （新しいクラスターの場合は）この時点で seal されていた

Secrets Engines

Reference

approle で role_id, secret_id を払い出す

Cronjob で snapshot を作成する

詳細まで書かれていて助かった。

メモ