Policy as Codeを実現するVaultの「Sentinel Integration」とは

ラックは、2019年8月7日に、HashiCorp社のシークレット管理製品「Vault（ヴォルト）」の販売を開始しました。
この記事では、HashiConf'19^※1でも取り上げられた、Vaultのエンタープライズ版の機能の一つである「Sentinel Integration」をご紹介します。

※1 2019年9月にアメリカのシアトルで開催されたHashiCorp社主催のカンファレンス

Vaultとは

Vaultは、マルチクラウド環境におけるシークレット（例えば、Azureなどにアクセスするための認証情報等）を、発行・更新・削除のすべてのライフサイクルにわたって一元管理できる製品です。ユーザが対象のサービスにアクセスする際に、Vaultからシークレットの払い出しを受けるため、シークレットをソースコードにハードコーディングする（埋め込む）必要がないという利点があります。また、Vaultの管理者はシークレットの払い出しに必要なアクセスキーに有効期限を設けることができ、万が一アクセスキーが漏洩した場合にも即座に停止することができるため、セキュアな運用を担保することができます。

OSS版Vaultにおけるポリシー管理とその限界

システム管理者がVaultでシークレットを管理する場合には、「誰が」「どのシークレットに」「どのようにアクセスできるか」というポリシーを定義します。オープンソース（OSS）版のVaultでは、アクセスコントロールリスト（ACL）でユーザがアクセス可能なシークレットとそれに対する操作を定義します。

例えば、あるユーザにシークレット"personal"の読み込み「のみ」を許可するACLを作成する場合には、コマンドラインから次のように入力します（ファイルから読み込むこともできます）。

このポリシーを適用したユーザは、"personal"への「読み込み」はできますが、「書き込み」や"personal"以外へのシークレットへのアクセスはできなくなります。

しかしVaultをチームや組織で運用する場合には、ユーザが所属するグループやアクセス対象のシークレットの性質に応じてより細かいコントロールが要求されるでしょう。例えば、以下のようなことが考えられます。

• 本番環境にアクセスするためのシークレットは、特定の開発チームに所属するメンバーにのみ払い出したい
• GDPRへの対応から、個人情報を取り扱うシステムのシークレットに対するアクセス元は、EU圏以外のIPアドレスに制限したい

また、上記のような複雑なポリシーを定義する場合には、例えば、シークレットへのアクセス権限を持つべきでないグループのユーザに対し権限を与えてしまった、というような設定誤りへの配慮も必要です。

Policy as Code

実際の開発現場で要求される、このように複雑なポリシーを管理する一つの考え方として「Policy as Code」があります。

Policy as Codeとは、ポリシーをコードベースで管理することです。コードベースで管理したポリシーを環境に適用することで、組織が定めたポリシーと実際のポリシーが一致し、権限の設定誤りや漏れを防ぐことができます。また、履歴管理も可能になります。そのため、ポリシーに問題があった場合には以前のバージョンを適用することで、復元が容易という利点もあります。

Sentinel Integrationによる解決

エンタープライズ版のVaultは、「Policy as Code」の考え方に基づき、複雑なポリシーを適切に管理するための機能「Sentinel Integration」を備えています。^※2

※2 より正確には、HashiCorp社の「Sentinel」というOSSフレームワークを統合（Integration）する機能です。また、この機能はOSS版のACL機能と併用することができます。

具体的には、下記2つのポリシー制御をコードにより実現します。

Role Governing Policies（以下、RGPs）

RGPsは、Vault上の識別子（トークン、エンティティまたはグループ単位）でポリシーを定義します。
例えば、特定のグループ名やグループIDに該当するユーザにアクセスを認める場合には、次のように記述します。

この場合、"develop-team"に所属しないユーザは、対象のシークレットにアクセスすることができません。

Endpoint Governing Policies（以下、EGPs）

EGPsは、エンドポイントすなわちアクセス元やアクセス対象のリソース単位でポリシーを定義します。 例えば、アクセスを営業時間内（9時～17時）に限り許可したい場合には、次のように記述します。

また、LDAP認証を利用したログインについて、特定の接続元IPに制限したい場合は、次のように記述します。

上記いずれの場合も、条件を満たさないアクセスは拒否されます（403エラー）。

なお、Sentinelの機能はCLIだけでなくGUIからも利用することができます。

Sentinel Simulator

Sentinelにより作成したポリシーは、HashiCorp社のOSS「Sentinel Simulator」によりテストすることができます。
例えば、特定のシークレットに対してIP"122.22.3.4"からのアクセスのみ許可するポリシーを定義した場合、当該ポリシーに対する正常系のテストケースは次のようにJSON形式で記述します。

作成したテストケースは、sentinelコマンドでテストすることができます。テストに成功すると、次のように「PASS」が表示されます。

このように作成したポリシーに対してテストを実施することで、ポリシーの設定内容が意図したものであるかどうかを確認することができます。

まとめ

マルチクラウド時代の開発において、採用するクラウドサービスやそれを利用する開発者が増えるほど、シークレットを適切に管理するためのポリシー運用コストも増えていきます。
Vaultエンタープライズ版の「Sentinel Integration」を適切に利用することで、組織の複雑化したポリシー管理に大いに役立つでしょう。