VaultのStorage BackendにGCSを使ってみる
目次
- 初めに
- 動作環境
- VaultのStorage Backend
- GCSを使ってみる
- 終わりに
1. 初めに
VaultにはStorage Backendっというものがあります。今回はそのStorage BackendにGCSを利用してみたいと思います。 下記がVaultのStorage Backendのドキュメントになりますので、より詳しく知りたい方はドキュメントを見てみてください。
2. 動作環境
3. VaultのStorage Backend
まずはVaultのStorage Backendについてですが、簡単に説明するとSecretなどの情報を保存しておく場所になります。 仮にdev modeで起動したときのStorage Backendはin memoryとなります。こうしたデータの保存場所をVaultでは指定することができ、例えばファイル、S3、ConsulやEtcdにも保存することができます。
保存されたデータは暗号化してあるので直接データを見に行っても中を見ることができない状態になっています。
4. GCSを使ってみる
早速GCSを使ってみようと思います。GCSを使うにあたって一般的にはGCSを使えるよう権限を与える必要があります。 ですので権限周りについて詳しく見ていきましょう。
GCSバケットの作成
まずは保存先となるGCSのバケットを作成していきます。
$ gsutil mb gs://my-storage-bucket
これだけで作成完了です。
GCSをStorage Backendとして扱うにはVaultからGCSに対してアクセスできる権限がないといけないので専用のService Accountを作成したいと思います。
Service Accountの作成
GCSにアクセスするためService AccountにはGCSへのアクセス権限を割り当てる必要があります。
アクセス権限はVaultのドキュメントに書いてある通り、 roles/storage.objectAdmin のロールを割り当ててあげれば大丈夫でしょう。
今回は vaultstorage っという名前でService Accountを作成します。
$ gcloud iam service-accounts create vaultstorage
ロールの割り当て
$ gcloud projects add-iam-policy-binding ${GOOGLE_CLOUD_PROJECT} --member="serviceAccount:vaultstorage@${GOOGLE_CLOUD_PROJECT}.iam.gserviceaccount.com" --role="roles/storage.objectAdmin"
作成が終わったら次は作成したService Accountの鍵を作成していきます。
$ gcloud iam service-accounts keys create vaultstorage-key.json --iam-account=vaultstorage@${GOOGLE_CLOUD_PROJECT}.iam.gserviceaccount.com
次に作成した鍵のパスをGOOGLE_APPLICATION_CREDENTIALS環境変数に保存しましょう。
export GOOGLE_APPLICATION_CREDENTIALS=/home/hogehoge/vaultstorage-key.json
これで準備が完了しました。次にVaultを起動していきます。
Vaultの起動
Vaultの起動する際にGCSをStorage Backendとして使うようconfigに記載していきます。
storage "gcs" {
bucket = "my-storage-bucket"
}
・・・
storage に gcs としていしてあげます。bucketは先ほど作成したバケット名を入れてあげます。
configの設定はこれだけあれば十分ですので実際に起動させてみたいと思います。
$ vault server -config=config/config.hcl
==> Vault server configuration:
Cgo: disabled
Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "127.0.0.1:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled")
Log Level: info
Mlock: supported: true, enabled: false
Recovery Mode: false
Storage: gcs (HA disabled)
Version: Vault v1.3.0
Version Sha: 4083c36aa0630faafb7c04be62c4940299880bc9+CHANGES
==> Vault server started! Log data will stream in below:
Vaultの初期化処理
起動が完了したら別のターミナルを立ち上げてvault CLIで操作していきましょう。 ただ、CLIで操作する前にVAULT_ADDR環境変数にVault Serverのエンドポイントを指定してあげる必要があります。
$ export VAULT_ADDR=http://127.0.0.1:8200
では初期化処理です。ここでVault Serverは起動したばかりでSealed状態になっているのでUnsealにしていきます。
$ vault operator init Unseal Key 1: UK7ktKGdZldIjiwZtVYVDKIl8GeZaeKS+joCjBc5eaYJ Unseal Key 2: auZJoO8HRUYYQ553BY8aecyA2UjrO1X/jY3eeF8aiDFx Unseal Key 3: LvN54zcqTctERCEnKvX7xPbpous9QraLu5453WRE59NH Unseal Key 4: uAQb//JNOMvwXhrtDAK9Kvxz02+yIbiMBxanPrxdorRG Unseal Key 5: yjItUqqRvn1wrUmqbFmRdjP8xP6CUGzgf/2YHdkaAvRd Initial Root Token: s.MAXpmLCdMGUBqWGMyyAU4DSF 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 master key. Without at least 3 key to reconstruct the master 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.
$ vault operator unseal Unseal Key (will be hidden): Key Value --- ----- Seal Type shamir Initialized true Sealed true Total Shares 5 Threshold 3 Unseal Progress 1/3 Unseal Nonce ea5a56b5-5044-3f6a-d7a2-af25bc0ac7f3 Version 1.3.0 HA Enabled false $ vault operator unseal Unseal Key (will be hidden): Key Value --- ----- Seal Type shamir Initialized true Sealed true Total Shares 5 Threshold 3 Unseal Progress 2/3 Unseal Nonce ea5a56b5-5044-3f6a-d7a2-af25bc0ac7f3 Version 1.3.0 HA Enabled false $ vault operator unseal Unseal Key (will be hidden): Key Value --- ----- Seal Type shamir Initialized true Sealed false Total Shares 5 Threshold 3 Version 1.3.0 Cluster Name vault-cluster-4769ee3e Cluster ID a5994982-e32d-459e-bf27-d5f4eaec10bc HA Enabled false
初期化処理もすべて完了しました。 ここで一度バケットの中を見てみて実際にデータが入っているか見てみましょう。
$ gsutil ls gs://my-storage-bucket/ gs://my-storage-bucket/core/ gs://my-storage-bucket/logical/ gs://my-storage-bucket/sys/
実際に値が入っていますね。 ちなみに中のデータはちゃんと暗号化されていました。
ではここでVault CLIでVault Serverにログインしてみましょう。
# root tokenを指定
$ export VAULT_TOKEN= s.MAXpmLCdMGUBqWGMyyAU4DSF
$ vault login ${VAULT_TOKEN}
WARNING! The VAULT_TOKEN environment variable is set! This takes precedence
over the value set by this command. To use the value set by this command,
unset the VAULT_TOKEN environment variable or set it to the token displayed
below.
Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.
Key Value
--- -----
token s.MAXpmLCdMGUBqWGMyyAU4DSF
token_accessor EHkhj5RZZyo9qlg6xcKrPV5A
token_duration ∞
token_renewable false
token_policies ["root"]
identity_policies []
policies ["root"]
ログインまで完了した。 試しにKV Secrets Engineを許可し、値を入れてみてみましょう。
$ vault secrets enable -path=kv kv Success! Enabled the kv secrets engine at: kv/
$ vault write kv/hello foo=bar Success! Data written to: kv/hello $ vault read kv/hello Key Value --- ----- refresh_interval 768h foo bar
値も無事に入っているのが確認できました。ではここでVault Serverを停止させ、もう一度保存したデータが取得できるか確認してみましょう。 一度Vault Serverは起動しなおした時はSealed状態で立ち上がっているのでもう一度Unsealにする必要があります。
初期化処理をした時と同様 vault operator unseal コマンドでUnseal処理をした後は今まで通りコマンドからVaultを操作することができます。
停止する前に入れたデータが残っているか確認してみましょう。
$ vault read kv/hello Key Value --- ----- refresh_interval 768h foo bar
無事にデータが残っていることが確認でき、閲覧するところまで確認できました。
5. 終わりに
Storage BackendにGCSを使ってみました。実際にデータが保存されるところまで確認でき再起動後もデータが残っていることまで確認でました。GCSの中のデータ自体は暗号化されているので直接Secret情報が見られることがないので安心ですね。
ただ、このままですと中の情報は見られることはないですが、GCSのデータ自体は削除や直接追加などできてしまうので、 実運用するときはVault Serverだけバケットにアクセスできるような制限なども必要かもしれないですね。
S3や別のストレージにも保存するやり方があるので機会があるときにそちらも試してみたいと思います。
