HashiCorp Vault 1.10 がリリースされました (主要アップデートまとめ)
HashiCorp Vault 1.10 GA release
Vault version 1.10.0 がリリースされました！
この記事では、新しいバージョンに含まれる主要なアップデートを紹介します。
MFA (Multi-Factor Authentication) によるログイン認証が OSS 版でも利用可能に
これまで Enterprise ライセンスのみで提供されていた MFA によるログイン機能ですが、1.10 から OSS 版でも利用が可能になりました！これは多くのユーザーにとって待望の機能追加ではないでしょうか。
- TOTP (Time-based One-time Password)
- Okta
- Duo
- PingID
が現状ではサポートされています。TOTP 以外は全て外部プロバイダを利用した MFA 連携です。
注意点として、OSS 版でこれまで利用可能だった古い Legacy MFA auth method は、今回のリリースによって deprecated (非推奨) 扱いとなり、将来の Vault 1.11 リリースで廃止される予定です。もしこの古い MFA 機能を利用している場合は、今回のリリースによって追加された新しい MFA 機能へ移行してください。
また、Step-up Enterprise MFA 機能は、引き続き Enterprise 版でのみの提供になります。この機能は、単純なログインに対して MFA を強制するのではなく、Vault 内に保存されるデータの中でも特に高い機密性が求められる一部のリソースへのアクセスに対して、ユーザーからの要求時に個別に MFA を強制するような機能です。
Secrets Engines/Auth Methods の mount path 変更がより簡単に
これまでも Secrets Engines の mount path move (vault secrets move) は可能でしたが、Vault version 1.10 からは Auth Methods の mount path move も可能になりました。さらに、namespace をまたいでの move も可能になっています。これにより、例えば OSS -> Enterprise ライセンス移行時の migration 作業や、組織改編に伴う namespace 名の変更などが従来に比べて簡単になりました。
ただし mount path の変更については、いくつかの注意点もあります。
- 移行元 namespace の Identity entities や entity aliases は引き継がれないため、移行先の namespace で再作成する必要がある
- 全ての lease (secret engines/auth methods) は move 時に expire し、移行先には引き継がれない
- ACL Policy の設定 (path) は自動的に更新されないため、移行後にアップデートが必要
Vault as an OIDC Provider
Vault version 1.9.0 で tech preview として追加されていた、Vault 自身を OIDC provider として動作させることができる Vault OIDC identity providerが、GA 機能として正式にリリースされました。また GA リリースにともない、PKCE も新たにサポートされました。
Vault -> 外部の OIDC provider に対しての認証は以前からサポートされていましたが、この機能では反対に、任意のアプリケーション・サービスから Vault OIDC provider に対して認証要求を行うことができます。これにより、例えば Okta のように、任意のサービスからのログイン時に Vault の認証ページにリダイレクトし、Vault server 上に既に設定されている任意の auth method を使ってログイン認証することで、その結果を使って呼び出し元のサービスへのログイン処理などを行うことができます。
参考までに、下記は Vault OIDC provider を使って、HashiCorp Boundary のログイン認証に Vault を利用する設定例です:
Server Side Consistent Tokens 機能導入にともなう token format の変更
新たに Server Side Consistent Tokens という機能が導入されました。
Vault で replication を運用している場合、Vault では Eventual Consistency (結果整合性) モデルによって cluster 間の同期が取られています。これにより、一部のケースでは read-after-write が保証できないという既知の問題がありました。
例えば、Integrated Storage Backend を利用する Performance Standby node に対して、払い出された token を使ったクライアントリクエストが送られてきた際に、その node がまだ払い出された token に関するデータを保持していない場合 (replication が完了していない)、このリクエストは失敗してしまいます (e.g., permission denied 系の HTTP ステータスコード)。
この問題の対策として、以前に Vault version 1.7 でクライアント側での回避策が実装されました。しかしながらこの方法では、Vault を利用するクライアント側で条件に応じて追加の HTTP ヘッダーを送信してリトライを行う (または Vault Agent を利用する)といった実装変更が必至となり、採用にはハードルが高いものでした。
このため、Vault version 1.10 では、この Consistency の問題をサーバーサイドで解決するための Server Side Consistent Tokens 機能が追加されました。これにより、クライアントアクセスが同様の理由で失敗した場合、Vault server (performance standbys) からクライアントには HTTP 412 エラーが新たに返されるようになります。クライアントはこのエラーを受け取ると、リクエストを改変することなくリトライすることができます。
クライアント側実装でのリトライが難しい場合、新たに追加された allow_forwarding_via_token replication 設定を使うことで、失敗時にクライアントリクエストを active node へ転送することもできます。
Token format の変更
重要な点として、この機能の実装にあたり、token 自体に WAL (Write-Ahead-Log) state 情報を埋め込む必要があったため、これに伴って token のフォーマットが変更されることになりました。Vault version 1.10 以降では、Service token は最低でも 95 bytes~ のデータ長を持つことになります (これまでは 25 bytes~)。
また、全ての種類の token の prefix が下記の通り変更されています。
| Token Type | Vault 1.9.x 以前 | Vault 1.10 以降 |
|---|---|---|
| Service tokens | s. |
hvs. |
| Batch tokens | b. |
hvb. |
| Recovery tokens | r. |
hvr. |
これらの token format の変更は、OSS/Enterprise 版に関わらずデフォルトで有効になっています。後方互換性が保たれているため、Vault version 1.10 でも引き続き以前の token format を正しく認識することができます。
その他詳細については、下記の FAQ ガイドもご覧ください。
Vault Lambda Extension でキャッシュが利用可能に
AWS Lambda 実行環境から Vault に格納されている secrets の取得を簡単に行うことができる HashiCorp official の Vault Lambda Extension で、キャッシングがサポートされました。
これにより、大量の Lambda 実行が発生する環境下でも Vault server への負荷を大幅に削減することが可能です。詳細は下記のドキュメントからご確認ください。
Client Count の改善
Vault version 1.9 で行われた Client Count の改善に引き続き、1.10 でもいくつかの改善が行われました。
- namespace に加え、auth mount ごとの client count を確認できるようになった (UI/API)
- UI から auth mount ごとの client count を export できるようになった
- 選択された billing period の月ごと (month-on-month) の client count を取得できるようになった (API only)
などなど、その他にも軽微な改善がいくつか行われています。詳細については下記も合わせてご確認ください。
Transit Key auto-rotation (time-based)
Transi secret engine によって利用される暗号化キーは定期的に rotate (更新) することが推奨されていますが、これまで手動で rotate する方法しか提供されていませんでした (CLI/API)。
Vault version 1.10 では、新たに追加された auto_rotate_period parameter によって、暗号化キーを指定した時間が経過すると自動的に Vault server 自身によって rotate させることが可能になりました。これにより、今までは外部ツールなどを利用して rotate を行っていたケースでは、そうした運用がそもそも不要になります。
この機能はデフォルトでは無効です。有効にする場合、設定できる最小の period は1時間です。
Transit secret engine SHA-3 サポート
Transit secret engine で利用可能なハッシュアルゴリズムに SHA-3 が新たに加わりました。
Vault Agent の Telemetry サポート
Vault Agent から、いくつかの runtime に関する metrics の取得ができるようになりました。
取得できる metrics は今後のリリースでさらに追加されていく予定です。
(e.g., Agent 自体の health 情報や、auth/secret/lease/token に関するより詳細な metrics など)
PKI secret engine における HSM サポート
PKI secret engine の一部のオペレーションに HSM を利用可能になりました。
Vault version 1.10 では、key の発行、および certificate へのサインといったオペレーションを HSM にオフロードできます。PKCS#11 HSMs、Azure Key Vault、AWS KMS がサポートされています。
その他アップデート
その他にも、上記では紹介しきれなかったアップデートがたくさんあります。興味がある方は下記のリンクからご確認ください。
Discussion