Vaultにはsecretにアクセスするための認証方式が複数用意されています。そのうち、アプリケーションやサーバーへの組み込み用途にAppRoleという認証方式が実装されています。
この記事では、AppRoleの認証を使って、Vaultに保存したsecretを読み出すまでの一連の流れについて紹介します。
AppRole認証の概要
画像元: Authenticating Applications with HashiCorp Vault AppRole
AppRole認証の概要について、HashiCorpのチュートリアルを元に説明します。この認証は、RoleIDとSecretIDによって構成されています。
- RoleID: secretへのアクセス権限(ポリシー)をまとめたロールのID。事前に定義する
- SecretID: RoleIDで認証するためのパスワード。利用の都度払い出す
上の図をシーケンス図で書いてみると、下図のようになるでしょうか。大まかな流れとしては、
- 事前にアクセス権限を定義したRoleIDを作っておき、
- CIなどでSecretIDを生成してsecretにアクセスする
という形になります。
CLIで試してみる
それでは、チュートリアルに沿って実際にAppRole認証をVault CLIを使って試してみます。
事前準備
事前に、VaultでAppRole認証を有効にします。
$ vault auth enable approle
Success! Enabled approle auth method at: approle/
ロールを定義する
まず、適当なポリシー(hello-world.hcl)を作成し、それを割り当てたhello-worldというロールを発行します。
$ cat hello-world.hcl
path "secret/hello-world" {
capabilities = ["read", "list"]
}
#ポリシーの作成
$ vault policy write hello-world hello-world.hcl
#ロールの作成
$ vault write auth/approle/role/hello-world \
secret_id_ttl=120m \
token_ttl=60m \
token_max_tll=120m \
policies="hello-world"
作成したロールには、前述したRoleID(role_id)が付与されます。
$ vault read auth/approle/role/hello-world/role-id
Key Value
--- -----
role_id 69050b5d-347e-e94f-5d10-2b1a3a550111
実運用では、ロールの作成までを事前に行っておき、CIではSecretIDだけ払い出すようにするとよいでしょう。
SecretIDの払い出し
認証に必要なSecretIDは以下のコマンドによって生成できます。
$ vault write -f auth/approle/role/hello-world/secret-id
Key Value
--- -----
secret_id 2001d4ac-95d6-e473-e34d-e470ff70cd41
secret_id_accessor 7f0f6a44-7485-179a-ab45-88ec8f1ca639dbb43618d95
RoleIDとSecretIDで認証する
先の手順で得られたRoleID/SecretIDで認証が通ることを確認します。
$ vault write auth/approle/login role_id=${ROLE_ID} secret_id=${SECRET_ID}
Key Value
--- -----
token s.6lN6yzXjW3srMYqiXs8zyFW0
token_accessor 5ATZpJ4GMbLoLEdXdUAZ4KNC
token_duration 1h
token_renewable true
token_policies ["default" "hello-world"]
identity_policies []
policies ["default" "hello-world"]
token_meta_role_name hello-world
CIの場合は、生成したSecretID(secret_id)を、認証が必要なセットアップ対象に渡す必要があります。SecretIDを直接送りたくない場合は、Response Wrappingを使用すると、SecretIDを通信経路に直接露出しない形での受け渡しが可能です。
# -wrap-ttl=${TTL}を指定するとwrapping_tokenでラップされたレスポンスが返る
# CIでは、SecretIDの代わりにwrapping_tokenをセットアップ対象に送る
$ vault write --wrap-ttl=1440s -f auth/approle/role/hello-world/secret-id
Key Value
--- -----
wrapping_token: s.4iHbPgQKO9I7bPekP4cMgKlm
wrapping_accessor: 7aiuYHBf4m78Vk1fQMTj3kOY
wrapping_token_ttl: 24m
wrapping_token_creation_time: 2018-12-10 10:58:13.59285441 +0000 UTC
wrapping_token_creation_path: auth/approle/role/hello-world/secret-id
# セットアップ先でwrapping_tokenを使ってレスポンスを復号し、SecretIDを得る
$ vault unwrap s.4iHbPgQKO9I7bPekP4cMgKlm
Key Value
--- -----
secret_id 52c631bc-f70a-6d56-3fa5-3826639ee6fa
secret_id_accessor 0714e06e-cf01-5dc2-35a1-749b9ddbb354
まとめ
AppRole認証を利用することで、予め定義しておいたロールで認証トークンの払い出しをほしいタイミングで都度行えます。また、ロールの作成オプションでip制限の仕組みやトークンの最大利用回数を設定することで、より強固な認証を組むこともできます。これまで説明したとおり、AppRoleは外部システムに依存せずにVaultのみで認証を完結できるので、小回りの効くシークレット管理の仕組みを作る場合に有用なのではないかと思います。
今回はAppRole認証の紹介でしたが、プラグインを開発すればVaultに独自の認証を組み込むことも可能です。例えば、AppRoleの拡張としてインスタンスメタデータのようなインスタンス情報と連携して、認証時にマシンを識別する、というようなことができます。プラグインの具体的な開発方法については、また機会があれば紹介したいと思います。