HashiCorp社が出したVaultとはどういうものなのか

HashiCorp 社から、新たなソフトウェアである Vault by HashiCorp がリリースされました。 - HashiCorp Blog: Vault この Vault について、Getting Started を一通り実施した後に Docs の一部を確認してみたので、簡単にその内容をまとめてみます。

Vault とは何なのか

Vault を一言で言うと、機密情報(Secret) を管理するツールです。

これだけ IT が広がっている現在、機密情報の範囲も広がり続けており、データベースにアクセスするためのユーザ/パスワードや、連携するシステムの API キー等、多岐に渡ります。こういった情報、おまえのところのシステムではどう管理してた？XML に生で書いてる、あるよねそういうの。jdbc.properties に直書き、うんうんわかるわかる。ちょっとがんばったら crypt で暗号化、そうだねそうだね。

このように、これまで機密情報は - 格納される場所、メディアがバラバラ - その管理体系もバラバラ - アクセス権限もバラバラ - 誰がアクセスしたかの監査もできないという状態でした。これらを統合的に扱えるようにするシステムが Vault です。

こうやってしまうと Vault は "Credential" を管理するシステムである、と矮小化されてしまう気もしますが、Vault が定義している "Secret" はもっと広範です。機密情報すべてを管理する、と言って良い。

A secret is the term for anything returned by Vault which contains confidential or cryptographic material.

Architecture | Vault by HashiCorp >

まずは実際に使ってみましょう

インストールはクソ簡単、zip をダウンロードして解凍したら実行ファイル 1 つだけであり、適切な場所に置いてから PATH を通すだけです。このあたりは Install Vault | Vault by HashiCorp を読んで頂くとして、まずは開発モードでサーバを立ち上げて、機密情報を入力してみます。

% vault server -dev

はい、このとおり、Vault はクライアント/サーバモデルのアーキテクチャを取るソフトウェアです。Vault のサーバは API を持っており、Vault の CLI コマンドを発行すると、内部で API を呼び出すことで機能を実現します。このため、独自に作ったアプリから(CLI でなく) API 経由で Vault と連携することも可能です。とはいえまずは、CLI で。

# Vault に機密情報を書き込んでみようぜ
% vault write secret/hello value=hello to=world
Success! Data written to: secret/hello

# Vault から機密情報を読み出してみようぜ
% vault read secret/hello
Key             Value
lease_id        secret/hello/62df1732-6dfc-2d72-a1c0-c4c75bb6a33b
lease_duration  2592000
to              world
value           hello

# JSON で読んでみようぜ
% vault read --format=json secret/hello
{
        "lease_id": "secret/hello/dfd31c39-b492-c7a0-b750-915c598f5267",
        "lease_duration": 2592000,
        "renewable": false,
        "data": {
                "to": "world",
                "value": "hello"
        }
}

このように、key=value 形式で機密情報を書き込むことが可能です。

ちなみにですが、このようにコマンドラインで機密情報を入力するのは、シェルのヒストリに残ってしまうなどの理由で、Vault でも非推奨です。Vault はファイルからの入力、STDIN からの入力をサポートしていますので、このあたりは Docs を参照してください。

ただ、出力を見るといくつか気になる用語がでてきました。"lease" とは何でしょう。また、"secret/hello" の意味するところは？これって単なる key-value store と何が違うの？

lease

Lease については Lease, Renew, and Revoke | Vault by HashiCorp を読めば良いと思うよ、ではあまりに乱暴なので、理解しているところを書き下します。

Lease というのは、Vault が「この機密情報は xxxx まで有効だよ」と約束する時間です。これを過ぎて、Vault に Revoke (無効化) されても文句は言えません。この Lease を適切に管理し、必要があれば Renew (更新) するのは基本的にはクライアントの責任です。このように有効期間を設けることで、万が一機密情報が漏れたとしても、その影響範囲が軽減されますし、Vault が自動的にとってくれる監査ログも意味を成すようになります。当然、明示的に機密情報を無効化することも可能です。もちろん API/CLI 経由でできます。

おやおや、そうすると、先程ぼくが入力したような "value=hello to=world" というようなデータが、Vault で勝手に Revoke されてしまうんでしょうか。この回答は、Secret Backend に依存します。

Secret Backend

Vault では様々なコンポーネントが抽象化されていますが、そのうちの 1 つ、"Secret" の管理レイヤも抽象化されており、それが "Secret Backend" です。

http://vaultproject.io/docs/internals/architecture.html

Architecture - Vault by HashiCorp via kwout

上図が Vault のアーキテクチャ概要です。実は、先程ぼくが機密情報を書き込んでいたのは、"generic" と呼ばれる Secret Backend でした。

% vault write secret/hello value=hello to=world

ここで secret と指定しているのが、generic と呼ばれる Secret Backend をマウントしたマウントポイントです。そう、Vault では、Secret Backend を特定のパスにマウントするという概念を用いているわけです。

% vault mounts
Path     Type     Description
secret/  generic  generic secret storage
sys/     system   system endpoints used for control, policy and debugging

上の出力を見て頂ければ分かるように、secrets/ というパスは generic という Secret Backend をマウントしています。もちろん、マウントポイントを増やすこともできて、個々のマウントポイントによって、アクセスできるユーザを制御する(認可制御を別にする) ようなことも可能です。

% vault mount -path=kiririmode generic
Successfully mounted 'generic' at 'kiririmode'!
% vault mounts
Path         Type     Description
kiririmode/  generic
secret/      generic  generic secret storage
sys/         system   system endpoints used for control, policy and debugging

もう一度アーキテクチャの図に目を向けて欲しいのですが、Path Routing から Secret Backend にルーティングが行われていました。このルーティングは、パス(secret/ や kiririmode/) も含めて行われるため、どの Secret Backend に "Secret" の管理をお願いするかが分かるわけです。現時点で、Secret Backend には以下の 7 つがあります。 1. AWS 1. Consul 1. PostgreSQL 1. MySQL 1. Transit 1. Generic 1. Custom "Secret" の管理は、個々の Secret Backend に完全に任されます。例えば AWS は(諸々の設定を Vault に行ったことを前提に)以下のようにして AWS のアクセスキーを IAM を利用して動的に発行できます。

$ vault read aws/creds/deploy
Key
lease_id     blahblah
access_key   fugafuga
secret_key   hogehoge

当然、このようにして動的に発行された secret は、lease の有効時間が経過すると revoke されます。一方で、Secret Backend の "secret" は自動的に revoke はされません。従って、さきほどの勝手に Revoke されるのか？という質問に対しては、"Secret Backend" に依る、が回答になると思います。

このように、Storage Backend を増やすことで、Vault の提供する統一したインタフェースを元にして様々かつ柔軟な「機密情報(Secret)」の管理ができる、というわけですね。