9/28、Vault の新バージョンのリリースに関する HashiCorp のブログ投稿がありました。今回の目玉はSSHバックエンドで鍵の動的生成サポートです。例によって参考訳です。
■ Vault 0.3
私達は Vault 0.3 をリリース出来ることを誇りに思います。Vault はシークレット（訳者注；認証鍵やAPI鍵など、秘密にしておくべき情報を総称したもの）の管理ツールです。証明書や API 鍵といった機密事項を扱うデータを暗号化して保管することで、Vault は全てのシークレット管理に必用なソリューションとなるつもりです。
Vault 0.3 は多くの新機能が提供されています。新機能は「ssh」バックエンド、「cubbyhole」バックエンド、新機能や「transit」バックエンドの改良、グローバルまたはマウントごとのデフォルト／最大 TTL の設定、アンシール鍵（unseal keys；訳者注：封印前の鍵のこと）のPGP 暗号化、「generic」バックエンドの大幅な性能改善、Duo Multi-Factor 認証のサポート等々です。私達は全ての改良点をここでリスト化できないため、より詳細については Vault 0.3 CHANGELOG をご覧ください。
なお、バージョン 0.2 の時点において、コード基盤の全てがセキュリティ専門家である iSEC パートナーによる監査を受けていました。しかしながら、先の時点ではこのことを公開せず、iSEC によるフィードバックを尊重し、更なる一般的なセキュリティ監査を目指し続けることとしました。それにより、Vault は組織が大いに注意を払うべきシークレットの扱いに対し、信頼できるものになります。
いつもながら、私達のコミュニティにおけるアイディア、バグ報告、プル・リクエストに対する大きな感謝をしています。
プロジェクトのウェブサイトから Vault 0.3 をダウンロードできます。
Vault 0.3 の主な新機能について学びたい場合は、このまま読み進めてください。
■ SSH バックエンド
Vault の新しい「ssh」バックエンドにより、Vault がマシンへの SSH を仲介し、ワンタイム・パスワード（OTPs）や SSH 鍵の動的生成を行います。
典型的な組織において、SSH 接続の権限委譲には多くの方法があります。最も安全なのは、特定のホスト上のユーザに対するアクセス・トークン（パスワードや鍵）を共有する方法です。この方法を行うと、実際に誰がそのアカウントを操作しているのか知るのが大変になります。これを強化するには、各マシンと各ユーザごとに別々のアカウントを作成することで、誰が操作しているか追跡しやすくなります。しかし、運用的には悪夢です。３つめの手法としては、踏み台ホスト（bastion host）で SSH 接続をプロキシすることで設定を集約することですが、パフォーマンスに影響があります。
Vault の「ssh」バックエンドはこの問題を解決するものです。Vault の柔軟なポリシー／ACL 機能と柔軟なロール定義を結び付けることで、Vault によって認証されたユーザは Vault を集中設定ポイントとして証明書のリクエストを行えます。ですが、ユーザはホストに直接接続できますし、パフォーマンスの影響もありません。ロールでユーザ名が一致するかや、その他のパラメータで CIDR 範囲や除外リストを扱えます。
以下の例は、お薦めのワンタイム・パスワード型のバックエンドを使う例です。これにより、全てのアクセスは異なったワンタイム・パスワードで行われます。Vault の監査ログによって、誰がトークンを使ってシステムにログインしたのか正確に把握できます。これはログイン先のユーザが同じだとしてもです。
$ vault write ssh/roles/otp_key_role key_type=otp default_user=username cidr_list=x.x.x.x/y,m.m.m.m/n Success! Data written to: ssh/roles/otp_key_role
$ vault write ssh/creds/otp_key_role ip=x.x.x.x Key Value lease_id ssh/creds/otp_key_role/73bbf513-9606-4bec-816c-5a2f009765a5 lease_duration 600 lease_renewable false port 22 username username ip x.x.x.x key 2f7e25a2-24c9-4b7b-0d35-27d5e5203a5c key_type otp
ワンタイム・パスワードは直接 SSH のパスワードとして利用できます：
$ ssh username@localhost Password: <ワンタイム・パスワードの入力> username@ip:~$
あるいは、新しい「vault ssh」コマンドを使うことで、自動化できます：
$ vault ssh -role otp_key_role username@x.x.x.x username@ip:~$
Vault の「ssh」バックエンドが、セキュリティ基盤になりうるという別の例として、シークレット・データの保管があげられます。「ssh」バックエンドを使えば、ゼロトラスト・データセンタ（訳者注；ゼロトラストとは、”誰も信頼しない”ので常に検証する）に移行するのを簡単にするでしょう。
■ Cubbyhole （隠れ家）バックエンド
Vault の新しい「cubbyhole」シークレット・バックエンドは「generic」シークレット・バックエンドが変わったものですが、大きな違いがあります。空間全体が特定のトークンにによって制約されており、各トークンごとにデータを隠すために「cubbyhole」（隠れ家）が与えられます。トークンのが期限切れになったり無効になると、対象の cubbyhole は削除され、中のデータには一切アクセスできなくなります。
これにより、これまでの認証シナリオでは実現が困難だった、多くの便利なワークフローが実現できるようになります。たとえば、コンテナに他のシークレットや認証鍵を用意するために、 Vault のトークンを与える場合を考えてみます。一般的な方法の１つは、トークンをコンテナ環境の中に入れることです。ですが欠点として、その環境はコンテナ実行時にあらゆるプロセスから読み込み可能になります。読み込まれるのはコンテナ管理システムのログ、ホスト、またはコンテナ自身からです。
しかしながら、ログのように多くの状況では、すぐにアクセスできない場合があります。そこで「cubbyhole」バックエンドを使うことで、Vault のセキュリティに関する基本命令のいくつか（証明書の利用制限、証明書の有効期限）を利用して、次のような認証ワークフローを構築できます：
1. プロセスは Vault の認証トークンによって作成された２つのトークンに対して責任を持ちます。２つのトークンとは、永続（perm）トークンと一時（temp）トークンです。「perm」トークンには、コンテナ内のアプリケーションが必用とするポリシーの、最終的なセットが含まれます。「temp」トークンは15秒間かつ最大2回カウントされるまで使われます。
2. 「temp」トークンは「perm」トークンをcubbyholeストレージに書き込むために使います。ここでは、単純に書き出すという必用な作業が実行され、「temp」の残り利用回数が1回に減ります。
3. 実行されたプロセスは「temp」トークンをコンテナ管理エンジンに渡します。エンジンはコンテナを起動し、「temp」トークンの値をコンテナ環境に投入します。
4. コンテナ内のアプリケーションは「temp」トークンをコンテナ環境から読み込み、それを cubbyhole から「perm」トークンを取得するために使います。この読み込み作業によって「temp」トークンの利用上限に達してしまうので、「temp」トークンは無効化されます。そして cubbyhole は破棄されます。
5. もしアプリケーションが「temp」トークンを使えない場合、 cubbyhole へのアクセスができないという内容の警告が Vault の監査ログに記録されます。オペレータはこのログを見ることで、アプリケーションの起動に時間がかかっているか（それと、tempトークンのタイムアウトの影響）、あるいは、別のプロセスがトークンを使っているかどうかが分かります。
初期の認証管理における”鶏か先か、卵が先かの問題”を完全に解決する方法はありません。しかしながら、短い有効期限と、初期の共有証明書の利用を制限することにより、多くのチームがセキュリティ・ポリシーを管理するにあたって、私達はこれが受け入れ可能な方法と考えています。
■ 柔軟な TTL（Flexible TTLs）
Vault はマウントするたびに提供（リース）されるまでの TTL や、デフォルトまたは最大の期間を調整可能なシステムをサポートしています。
システムの設定は Vault の設定ファイルを通して行います。マウントごとの設定は新しいコマンド「mount-tune」で行います。「mount」コマンドを実行した時の結果にも反映されます：
$ vault mounts Path Type Default TTL Max TTL Description cubbyhole/ cubbyhole n/a n/a per-token private secret storage secret/ generic system system generic secret storage sys/ system n/a n/a system endpoints used for control, policy and debugging $ vault mount-tune -default-lease-ttl=4h -max-lease-ttl=24h secret Successfully tuned mount 'secret'! $ vault mounts Path Type Default TTL Max TTL Description cubbyhole/ cubbyhole n/a n/a per-token private secret storage secret/ generic 14400 86400 generic secret storage sys/ system n/a n/a system endpoints used for control, policy and debugging
この機能の重要なところは、マウントごとのデフォルト TTL は、マウントごとの最大 TTL より小さい必要があり（あるいは、マウントごとの最大 TTL を指定しなければ、システムの最大 TTL を使用）、マウントごとの最大 TTL はシステム値を上書きします（システム値とは「root」トークンか、「sudo｣に適切にアクセスできるトークンです）。実際には、大部分のバックエンドは複数のパスをマウントして使うため、この方法により管理の柔軟性が非常に高くなります。
より詳細な情報は mounts API ドキュメントをお読みください。
メモ：各々のバックエンドごとにデフォルトが設定されています。いくつかのバックエンドは無視するかもしれません。（たとえば）ロールごとにデフォルトを指定されている場合です。しかしながら、最大数の設定は Vault のコアによって強制されるため、最大数に関しては常に信頼できます。
■ アンシール鍵の PGP 暗号化
「pgp_keys」パラメータによって、Vault の初期化時や、マスター鍵の入れ替え時に、base64 暗号化 PGP 鍵の文字列形式を扱えます。文字列の長さは「secret_shares」パラメータと一致する必要があります。この指定があれば、アンシール鍵の処理ごとに、対象となる公開鍵は暗号化されたまま、命令が維持されます。
より詳細な情報は init API ドキュメントをお読みください。
■ Geeric バックエンドのパフォーマンス改善
｢generic」バックエンドは TTL の概念をサポートしていますが、TTL に到達しても実際のデータを破棄しません。この概念は、データ書き込みのためと、データの利用者が新しい値かどうか確認するためのものです。しかしながら、読み込むたびに利用（リース）できる TTL の値を割り当てられるため、読み込み数がスケールアップした場合、膨大な時間が発生する操作になりました。
バージョン 0.3 では、値の読み込み時に利用期間（リース）の設定をしません。TTL はシステムまたはマウントごとのデフォルト値を返すだけです。あるいは特定のキーで TTL の設定が明示されたとしても、Vault のコアによって利用期間は登録されません。Vault がこの機能をサポートした結果、読み込みごとのベンチマーク性能は10倍に増えました。
■ 多要素（Duo Multi-Factor）の認証サポート
認証バックエンド（現時点では「ldap」と「userpass」）のサポートにおいて、Vault の「mfa」認証サポートは、新しく duo を利用可能です。「mfa」の詳細については、ドキュメントをお読みください。
■ アップグレードの詳細
Vault 0.3 はいくつかの変更を導入しました。データをどこに保管するかの設計や、Vault が物理保管しなくても改竄を検出できるよう、将来的な拡張ができるようにするためです。
その結果、Vault 0.3 によって書かれたデータは、以前のバージョンの Vault で読み込むことができません。もしバージョンを差し戻す事を考えているのであれば、ストレージのバックエンド・データを複製して保管してください。
数点の変更点が存在しています。詳細については Vault メーリングリストにおいてアナウンスした通りです：
* Vault 0.3 CHANGELOG で扱っているように、今後は cookie 認証をサポートしません。認証ヘッダに「X-Vault-Token」を使う必要があります。
* 「lease」（リース、貸し出す）という言葉は混同されがちです。これはメタデータの収拾までの期間であり、また自身の期間でもあります。私達は生存時間・Tilme-To-Live（”ttl”）の期間を表すものを lease とするようにします。現時点では API が使用している「lease_duration」を置き換えるつもりはありません。これは JSON 形式で、より冗長かつ正確なレスポンスを行うためのものです。しかしながら、私達はバックエンドの処理における “lease” という言葉を今後使いません。バージョン 0.3 において「lease」とは、「generic」「token」「pke」バックエンドにおいて利用される期間のことですが、いずれ「ttl」におきかえられます。バージョン 0.4 では「ttl」のみ扱います。他のバックエンドにおいては、将来的なリリースで移行します。
■ ロードマップ
バージョン 0.4 のロードマップにむけては、現在も検討中ですが、以下の新機能の追加を考えています。
* 「pki」バックエンドの能力向上です。Vault の自己署名や、中間 CA 証明書の生成や、CSR による認証リクエスト機能です。Vault を X.609 PKI ワークフローで始めから最後まで利用できるようになるでしょう。
* LDAP 認証B各エンドの書き直しにより、柔軟性の改良や、更なる LDAP サーバ設定との互換性をもたらします。
* 「tls」バックエンドに CRL リストを送れるようにすることで、チェックを廃止し、Chrome の CRLSets のようになります。
もちろん、その他の改良やバグフィックスも含まれます！
いつものように、私達は本バージョンへのアップグレードやテストにあたり、独立した環境での利用を推奨します。もし何か問題があれば、Vault GitHub issue tracker または Vault メーリングリストにご報告願います。
■ 原文
Vault 0.3 – HashiCorp
https://www.hashicorp.com/blog/vault-0.3.html
—-
今回、HashiConf 2015 に参加して、HashiCorp 中の人に、ブログの翻訳について認知していただきました。今後も自重せずに続けていくつもりです。
