Vault の認証について入門してみる

まず、Authenticationとは何なのかについて説明したいと思います。AuthenticationはVaultを利用するために認証する仕組みです。 dev modeで起動したときにRoot TokenをVAULT_DEV_ROOT_TOKEN_ID環境変数として設定しましたが、これはToken認証をするために設定したものです。 Vaultは様々なAuthenticatuonをサポートしており、Token認証以外でもGitHub、AWS、GCPなどがあります。

Token認証はデフォルトでenableになっており、これはdisabledにすることはできません。必須のものとなります。

4. Tokenでの認証

ざっくりとAuthenticationについて説明したので、Tokenを作って認証をしたいと思います。コマンドでTokenを作ることができるので早速作ってみましょう。

$ vault token create
Key                  Value
---                  -----
token                s.b52A1xP2YGDWbZ71eE5qkPMw
token_accessor       rQyxtgb35LXZDIryQLCJaG3G
token_duration       ∞
token_renewable      false
token_policies       ["root"]
identity_policies    []
policies             ["root"]

作成が完了しました。Tokenの大事な要素としてTokenは親子関係があります。新規に作成されたTokenはログイン中のアカウント、いわゆるログイン中のTokenの子Tokenとして作成されたことになります。

policiesのところに ["root"] とありますが、これはログイン中のTokenのポリシーになり、子Tokenには同じポリシーが当たるようになっています。ポリシーとはVaultを構成する要素の一つです。ここでは詳しくは記載しませんが、下記リンクを見てもらえばわかりやすいかと思います。

HashiCorp Vaultのポリシーを使いこなす｜ Developers.IO

ここで、大事なのが作成された子Tokenは親となるTokenが削除されたときに一緒に削除されてしまいます。なのでTokenを扱うときは親子関係を意識しながら扱うよう気を付けましょう。補足としてTokenを作成するときに -orphan オプションを指定すれば親をなしの状態でTokenを作成できます。

では先ほど作成したTokenでログインしてみたいと思います。

$ vault login  s.b52A1xP2YGDWbZ71eE5qkPMw
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.b52A1xP2YGDWbZ71eE5qkPMw
token_accessor       rQyxtgb35LXZDIryQLCJaG3G
token_duration       ∞
token_renewable      false
token_policies       ["root"]
identity_policies    []
policies             ["root"]

ちなみに lookup サブコマンドでログイン中のToken情報が確認できます。

$ vault token lookup
Key                 Value
---                 -----
accessor            rQyxtgb35LXZDIryQLCJaG3G
creation_time       1577099915
creation_ttl        0s
display_name        token
entity_id           n/a
expire_time         <nil>
explicit_max_ttl    0s
id                  s.b52A1xP2YGDWbZ71eE5qkPMw
issue_time          2019-12-23T11:18:35.458299285Z
meta                <nil>
num_uses            0
orphan              false
path                auth/token/create
policies            [root]
renewable           false
ttl                 0s
type                service

無事にログインすることができました。次にTokenを削除してみたいと思います。

$ vault token revoke s.b52A1xP2YGDWbZ71eE5qkPMw
Success! Revoked token (if it existed)

これでTokenの削除が完了しました。ちなみに、Tokenの削除はログインしているTokenでも削除することが可能です。

5. GCPで認証

管理サービスアカウントの作成

Tokenでの認証について記述してきました。ただこれからVaultを運用していくとなると毎回Tokenを作成するのは面倒ですし、管理が煩雑になるかと思います。ですのでここからはGCPを使って認証をしたいと思います。

GCPで認証を行うには二つの方法があります。IAMでの認証とGCEでの認証とあります。今回はローカル環境でVaultを動かしているのでIAMでの認証をしてみたいと思います。 IAMで認証するために作成するリソースは以下のものになります。

* GCP
  * Service Account
    * 管理用Service Account
    * 認証用Service Account
  * IAM Role
    * 管理用Service AccountのRole
* Vault
  * Policy
  * GCP認証
    * config
    * role

認証用Service AccountはこのService Accountを使ってVaultに対して認証、ログインをします。管理用Service AccountはログインしてきたSerivce Accountが正しいかどうかをGCPに対してリクエストを送ります。それで問題なければ認証成功となります。

では早速、認証の準備をしていきましょう。下準備としてGCPで認証をするためにAMI APIアクセスを許可あげないといけません。

$ gcloud services enable iam.googleapis.com

APIアクセスが許可できたら早速GCP上にIAMを作成していきます。

まずは管理用のService Accountを作成していきます。これはVault ServerがGCPに対して

$ gcloud iam service-accounts create vaultadmin
$ gcloud iam service-accounts keys create vaultadmin-key.json --iam-account=vaultadmin@sample-project.iam.gserviceaccount.com

次に管理Service Account用のRoleを作成し、関連付けます。

$ gcloud iam roles create vaultAdmin --permissions="iam.serviceAccounts.get,iam.serviceAccountKeys.get" --project="sample-project"
$ gcloud projects add-iam-policy-binding sample-project --member="serviceAccount:vaultadmin@sample-project.iam.gserviceaccount.com" --role="projects/sample-project/roles/vaultAdmin"

認証用サービスアカウントの作成

では、次は実際に認証で使うService Accountを作っていきましょう

$ gcloud iam service-accounts create user01
gcloud iam service-accounts keys create user01-key.json --iam-account=user01@sample-project.iam.gserviceaccount.com

認証用で利用するService AccountはJWTの署名をすることができる権限が必要になります。ですので iam.serviceAccountTokenCreator をRoleとして指定してあげましょう。

$ gcloud iam service-accounts add-iam-policy-binding user01@sample-project.iam.gserviceaccount.com --member="serviceAccount:user01@sample-project.iam.gserviceaccount.com" --role="roles/iam.serviceAccountTokenCreator"

ここまでで最低限のGCP上での準備ができました。次はVault側の設定を進めていきます。

GCP認証の設定

まずは認証をenableにします

$ vault auth enable gcp
Success! Enabled gcp auth method at: gcp/

次にGCP認証のConfigに管理用Service Accountの認証情報を追加します。

$ vault write auth/gcp/config credentials=@vaultadmin-key.json

ここで認証用のアカウントのPolicyを作り、Roleの追加をします。

$ vault write sys/policy/test policy=-<<EOF 
path "secret/data/test/*" {
  capabilities = ["read"]
}
EOF

$ vault write auth/gcp/role/my-role type="iam" project_id=sample-project policies="test" bound_service_accounts=user01@sample-project.iam.gserviceaccount.com

これで一通り準備が完了しました。

実際に認証してログインしてみましょう。

$ vault login -method=gcp role="gcp-role" credentials=@user01-key.json project="sample-project" service_account="user01@sample-project.iam.gserviceaccount.com"
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.kJSMSVXWsiCsd03hVXuE0lmt
token_accessor                      StawLc2yWqhX47QPhEnuVpzX
token_duration                      768h
token_renewable                     true
token_policies                      ["default" "test"]
identity_policies                   []
policies                            ["default" "test"]
token_meta_project_id               sample-project
token_meta_role                     gcp-role
token_meta_service_account_email    user01@sample-project.iam.gserviceaccount.com
token_meta_service_account_id       115673907101952887930

無事にログインすることができました。

最後に作成したリソースを確認してみましょう。

* GCP
  * Service Account
    * 管理用Service Account: vaultadmin@sample-project.iam.gserviceaccount.com
    * 認証用Service Account: user01@sample-project.iam.gserviceaccount.com
  * IAM Role
    * 管理用Service AccountのRole: vaultAdmin
* Vault
  * Policy: sys/policy/test
  * GCP認証
    * config: auth/gcp/config
    * role: auth/gcp/role/my-role

6. 終わりに

今回は認証を行ってみました。HashiCorp LearnではGitHubで認証をしていたのですが、GCPでの認証に挑戦してみました。途中Service Accountの権限周りでうまく進めることができませんでしたが、最終的にはちゃんとログインするところまで持っていけました。

VaultをKubernetes上でサイドカーとして動かすこともでき、その時にKubernetesで認証することができます。マイクロサービス化が進むことでAPIキーやユーザ/パスワードなどの機密情報をVaultに持たせ、サイドカーとして実装することで機密情報をアプリケーションに持たせることなく実装することができるのでより機密情報をセキュアに管理できるんじゃないかと思います。

認証をKubernetesで行い、Kubernetes上でサイドカーかし動かす実装もいつかやってみようと思います。

自宅インフラ屋さん