Vaultを使ってMySQLアカウントのダイナミック発行の仕組みを構築
ではVaultを使うとどんなことが可能になるのか。それを説明するため守永氏はMySQLアカウントのダイナミック発行の方法を例にとって紹介した。この仕組みのターゲットは次の通りだ。
- 毎日実行するバッチ処理でMySQLにアクセスするシステムで、バッチ処理はLL言語で記述されている。
- MySQLの接続情報が環境変数に書かれている。
- 調査時以外は誰もMy SQLにアクセスできないようにしたい。
- MySQLのクレデンシャルは定期的に変更したい。
Vaultを使うと、下図のようになる。
まずアプリケーションがVaultにMySQLのクレデンシャルを要求する。するとVaultがMySQLのアカウントを発行して、アプリケーションはMySQLにログインできる。そしてリースが切れたら、Vaultはアクセスできないようにアカウントを削除するという仕組みだ。これは、次の要素で構成することができる。
Actor
- Applicationサーバ
- MySQLサーバ
- Vaultサーバ
Application
- Vault Token（埋め込み）
MySQL
- Vault用アカウント
Vault
- Application Token Policy
- Database Secret Engine / Role
「ポイントはアプリケーションが直接Vaultにアクセスするので、アプリケーションにはVaultのTokenが必要な点。またVaultがMySQLアカウントを発行するので、MySQLにはVault用のアカウントが必要となる。Vaultの要素としては、Database Secret Engineが使われるということがわかればよい」と守永氏は説明する。
構築方法は次の通りだ。まずアプリケーションサーバがVaultにログインするためのTokenを作成する。次にアプリケーションサーバが利用するVault Tokenを発行し、アプリケーションサーバに配置する。そしてMySQLのアカウントをVaultが発行できるようにするために、Database Secret Engineを有効化し、Database Secret Engine Config、Database Secret Engine Roleを設定する。このような仕組みにすることで、アプリケーションがMySQLにアクセスしたいタイミングでVaultがアカウントをマネジメントしてくれるというわけだ。
「だが、この仕組みには課題がある」と守永氏。というのもMySQLでTTLを設定し、消してくれるのはよいが、アプリケーションサーバに入れる人は誰もがMySQLに入れることになるからだ。つまりVault用のMySQLアカウントもセキュリティホールになるという懸念がある。それを解決する仕組みが以下だ。
CIサーバを設置し、VaultにログインするためのSecret IDを取得するようにするのである。
「CIサーバはAppRoleログインのためのSecret IDをアプリケーションに送る。Secret IDはラップした状態でアプリケーションに渡されるので、それをアンラップする。次にアプリケーションサーバがAppRoleと言う機能を使ってVaultにログインする。そうするとVaultのTokenが返ってくるので、そのTokenを使ってMySQLアカウント発行の命令を実行する。その後のシーケンスは前回と同じだ」（守永氏）
構成要素
Actor
- Applicationサーバ
- CIサーバ
- MySQLサーバ
- Vaultサーバ
Application
- Role ID for App Role
- Vault Token for Unwrap
- Vault Token for AppRole Login
CI
- Vault Token for obtain wrapped Secret ID
- MySQL
- Vault Account
Vault
- AppRole
- Unwrap Token Policy
- Obtain Wrapped Token Policy
- Database Secret Engine / Role
「今回の構成要素で注目なのは、Auth MethodのためのAppRoleというものだ」と守永氏は説明する。構築するためにまず実施することはAppRole Auth Methodを使って、AppRole Auth Methodを有効化し、アンラップおよびAppRole用のポリシーを作成する。次にToken（Secret IDをアンラップするためのVault TokenとAuth MethodでログインするためのToken、CI用のVault Token）を発行する。この後の構築方法は前回同様となる。
この構成にすることによって、アプリケーションサーバにログインできても、MySQLアカウントは発行できなくなることはもちろん、CIサーバにログインできてもMySQLアカウントは発行できなくなる。「VaultがMySQLにログインするためのアカウントは、二度とログインできないくらいの状態にすることができる。それぐらい強力にクレデンシャル情報を管理できる」と守永氏は言い切る。
GCP上にVaultクラスタを構築する方法についても解説した。必要となるリソースは各種API（GCP用）、KMS、GCS、GCE VMインスタンス、GCE サービスアカウント、GCE IAM、HashiCorp Terraform。Vaultはバックエンドが選定できるので、High availability（HA）連携のバックエンドにはConsul、記憶容量用にはGCSを選定した。手順は次の通り。
- 各種API有効化
- KMS設定
- GCS Bucket作成
- IAMカスタムRole作成
- サービスアカウント作成
- VMインスタンス構築
- Consulセットアップ
- Vaultセットアップ
守永氏はさらに、Vaultの便利な機能の解説を行った。最初に紹介したのは「Storage Stanza」。つまり「利用できるストレージがたくさんあるということだ」と守永氏は語る。
次にSeal機構を持っていること。「この機能によってVaultへのAPIアクセスをコントロールすることができる。Sealed Statusだとほぼ何もリクエストできない状態になる」と守永氏は言う。
サーバ起動時はシール状態。アンシールにするには、アンシールコマンドを使うのだが、5つ用意されているキーのうち、3つを利用することでようやくアンシールできる仕組みになっているのだ。一方、シールする際は一発でできるという。「情報漏えいが発覚した際は、sealと打つだけで、誰もアクセスできなくなる。最悪の時に使える機能だと思う」と守永氏。
Auth Methodも複数ある。また、Vaultを使う主要因であり、同期のメイン機能となる「Secret Engine」を使うと、VaultのTokenとTokenにひも付いたポリシーを利用して機能させることができるようになる。Secret Engineも複数用意されているという。
「Vaultを使うとかえって面倒くさそうだなと思ったかもしれない。確かに私もVaultを扱うのは難しいと感じている。だが、Vaultがあると、クレデンシャル管理にまつわる課題の多くが解決できると考えている。Vaultがもっと注目される日が近々くると感じている。興味のある人はぜひ、試してほしい」
最後に守永氏はこう会場の参加者に呼びかけ、セッションを締めくくった。
お問い合わせ
株式会社grasys
