
シークレット管理、暗号化サービス、特権アクセス管理のためのツール
注意: 当社はVaultのセキュリティとユーザーの信頼を非常に重視しています。Vaultでセキュリティ上の問題を発見されたと思われる場合は、[email protected]までご連絡いただき、責任ある開示をお願いいたします。
Vaultは、シークレットに安全にアクセスするためのツールです。シークレットとは、APIキー、パスワード、証明書など、アクセスを厳密に制御したいものです。Vaultは、あらゆるシークレットへの統一されたインターフェースを提供するとともに、厳格なアクセス制御と詳細な監査ログの記録を提供します。
現代のシステムでは、データベースの認証情報、外部サービスのAPIキー、サービス指向アーキテクチャの通信のための認証情報など、多数のシークレットへのアクセスが必要です。誰がどのシークレットにアクセスしているかを把握することは、すでに非常に困難でプラットフォーム固有です。さらに、キーローテーション、安全なストレージ、詳細な監査ログを追加することは、カスタムソリューションなしではほぼ不可能です。そこでVaultが活躍します。
Vaultの主な機能は次のとおりです:
安全なシークレットストレージ: Vaultは任意のキーと値のペアを保存できます。Vaultはデータを永続ストレージに書き込む前に暗号化するため、生のストレージにアクセスできてもシークレットにアクセスするには十分ではありません。Vaultはディスク、Consulなどに書き込むことができます。
動的シークレット: Vaultは、AWSやSQLデータベースなどの一部のシステムに対して、オンデマンドでシークレットを生成できます。例えば、アプリケーションがS3バケットにアクセスする必要がある場合、Vaultに認証情報を要求し、Vaultは有効な権限を持つAWSキーペアをオンデマンドで生成します。これらの動的シークレットを作成した後、Vaultはリース期間が終了すると自動的にそれらを失効させます。
データ暗号化: Vaultはデータを保存せずに暗号化および復号化できます。これにより、セキュリティチームは暗号化パラメータを定義し、開発者は独自の暗号化方法を設計することなく、SQLデータベースなどの場所に暗号化データを保存できます。
リースと更新: Vaultは各シークレットにリースを関連付けます。リースの終了時に、Vaultは自動的にシークレットを失効させます。クライアントは組み込みの更新APIを使用してリースを更新できます。
失効: Vaultはシークレットの失効を組み込みでサポートしています。Vaultは単一のシークレットだけでなく、シークレットのツリー(例えば、特定のユーザーが読み取ったすべてのシークレット、または特定のタイプのすべてのシークレット)を失効させることができます。失効は、キーローテーションや侵入時のシステムロックダウンに役立ちます。
ドキュメントはVaultウェブサイトで入手できます。
Vaultを初めて使用し、セキュリティ自動化を始めたい場合は、HashiCorpの学習プラットフォームにあるはじめにガイドをご確認ください。学習を続けるための追加ガイドもあります。
さまざまなプログラミング言語でアプリケーション内からVaultとやり取りする方法の例については、vault-examplesリポジトリを参照してください。すぐに使えるサンプルアプリケーションも利用可能です。
認定試験に合格してVaultの知識を証明しましょう。試験の情報は認定ページを、学習教材はHashiCorpの学習プラットフォームの学習教材をご覧ください。
Vault自体またはその組み込みシステムのいずれかを開発する場合は、まずマシンにGoをインストールする必要があります。
ローカル開発のために、まずGoが正しくインストールされていることを確認し、GOPATHを設定してから、GOBIN変数を$GOPATH/binに設定します。$GOPATH/binがパスに含まれていることを確認してください。一部のディストリビューションでは古いバージョンのビルドツールがバンドルされているためです。
次に、このリポジトリをクローンします。VaultはGo Modulesを使用しているため、リポジトリをGOPATHの外側にクローンすることをお勧めします。その後、環境をブートストラップすることで必要なビルドツールをダウンロードできます:
$ make bootstrap
...
Vaultの開発バージョンをコンパイルするには、makeまたはmake devを実行します。これにより、Vaultバイナリがbinおよび$GOPATH/binフォルダに配置されます:
$ make dev
...
$ bin/vault
...
UI付きのVault開発バージョンをコンパイルするには、make static-dist dev-uiを実行します。これにより、Vaultバイナリがbinおよび$GOPATH/binフォルダに配置されます:
$ make static-dist dev-ui
...
$ bin/vault
...
テストを実行するには、make testと入力します。注意: Dockerがインストールされている必要があります。これが終了ステータス0で終了すれば、すべて正常に動作しています!
$ make test
...
特定のパッケージを開発している場合は、TEST変数を指定してそのパッケージのみのテストを実行できます。例えば、以下の例ではvaultパッケージのテストのみが実行されます。
$ make test TEST=./vault
...
could not read Username for 'https://github.com'のようなエラーが発生した場合は、以下のようにgit設定を調整する必要があります:
$ git config --global --add url."[email protected]:".insteadOf "https://github.com/"
このリポジトリは、他のプロジェクトからインポート可能な2つのライブラリを公開しています: github.com/hashicorp/vault/api および github.com/hashicorp/vault/sdk。
このリポジトリにはVault(製品)も含まれており、ほとんどのGoプロジェクトと同様に、Vaultは依存関係の管理にGoモジュールを使用しています。そのメカニズムはgo.modファイルです。その結果、このファイルが存在することで、Vaultを他のプロジェクトの依存関係としてインポートすることも理論的には可能になります。一部の他のプロジェクトでは、Vault自体のテスト用に開発されたテストツールを利用するために、そのようにする慣行があります。これは、Vaultプロジェクトのサポートされた使用方法ではなく、これまで一度もありません。github.com/hashicorp/vaultをプロジェクトにインポートできないことに関するバグを修正する予定はありません。
以下の「Dockerベースのテスト」のセクションも参照してください。
Vaultには、シークレットおよび認証方式のほとんどの機能をカバーする包括的な受け入れテストがあります。
シークレットまたは認証方式の機能に取り組んでいて、それが機能していること(および他の何も壊していないこと)を確認したい場合は、受け入れテストを実行することをお勧めします。
警告: 受け入れテストは実際のリソースを作成/破棄/変更するため、場合によっては実際のコストが発生する可能性があります。バグが存在する場合、壊れたバックエンドがデータを残す可能性があります。したがって、受け入れテストは自己責任で実行してください。少なくとも、テストするバックエンド用のプライベートアカウントで実行することをお勧めします。
受け入れテストを実行するには、make testaccを呼び出します:
$ make testacc TEST=./builtin/logical/consul
...
TEST変数は必須で、バックエンドがあるフォルダを指定する必要があります。TESTARGS変数は、特定のリソースにフィルタリングするために推奨されます。すべてを一度にテストすると非常に時間がかかることがあるためです。
受け入れテストでは通常、アクセスキーなどのために他の環境変数を設定する必要があります。テスト自体が早期にエラーを出力し、何を設定すべきかを教えてくれるため、ここでは文書化しません。
Vault Enterprise機能の詳細については、Vault Enterpriseサイトをご覧ください。
NewTestClusterに触発された実験的な新しいテストメカニズムを作成しました。使用方法の例:
import (
"testing"
"github.com/hashicorp/vault/sdk/helper/testcluster/docker"
)
func Test_Something_With_Docker(t *testing.T) {
opts := &docker.DockerClusterOptions{
ImageRepo: "hashicorp/vault", // または "hashicorp/vault-enterprise"
ImageTag: "latest",
}
cluster := docker.NewTestDockerCluster(t, opts)
client := cluster.Nodes()[0].APIClient()
_, err := client.Logical().Read("sys/storage/raft/configuration")
if err != nil {
t.Fatal(err)
}
}
またはEnterpriseの場合:
import (
"testing"
"github.com/hashicorp/vault/sdk/helper/testcluster/docker"
)
func Test_Something_With_Docker(t *testing.T) {
opts := &docker.DockerClusterOptions{
ImageRepo: "hashicorp/vault-enterprise",
ImageTag: "latest",
VaultLicense: licenseString, // パスではなく、実際のライセンスのバイト列
}
cluster := docker.NewTestDockerCluster(t, opts)
}
以下は、実際の使用例です。DefaultOptionsはリポジトリとタグに hashicorp/vault:latest を使用しますが、環境変数VAULT_BINARYも参照します。設定されている場合、VAULT_BINARYが参照するローカルファイルをコンテナにコピーします。これは、ローカルの変更をテストする場合に便利です。
VaultLicenseオプションを設定する代わりに、VAULT_LICENSE_CI環境変数を設定することもできます。これはライセンスをバージョン管理にコミットするよりも優れています。
オプションでCOMMIT_SHAを設定できます。これはデバッグの便宜上、ビルドするイメージ名に追加されます。
func Test_Custom_Build_With_Docker(t *testing.T) {
opts := docker.DefaultOptions(t)
cluster := docker.NewTestDockerCluster(t, opts)
}
github.com/hashicorp/vault/sdk/helper/testclusterパッケージにはさまざまなヘルパーがあります。例えば、以下のテストは3ノードのクラスタのペアを作成し、それぞれPRまたはDRレプリケーションを使用してリンクし、渡されたコンテキストが期限切れになる前にレプリケーション状態が健全にならなければ失敗します。
繰り返しますが、これらのテストは、Vault Enterpriseバイナリがローカルにあり、環境変数VAULT_BINARYがそれを指すように設定されていること、およびVAULT_LICENSE_CIが設定されていることに依存しています。
func TestStandardPerfReplication_Docker(t *testing.T) {
opts := docker.DefaultOptions(t)
r, err := docker.NewReplicationSetDocker(t, opts)
if err != nil {
t.Fatal(err)
}
defer r.Cleanup()
ctx, cancel := context.WithTimeout(context.Background(), time.Minute)
defer cancel()
err = r.StandardPerfReplication(ctx)
if err != nil {
t.Fatal(err)
}
}
func TestStandardDRReplication_Docker(t *testing.T) {
opts := docker.DefaultOptions(t)
r, err := docker.NewReplicationSetDocker(t, opts)
if err != nil {
t.Fatal(err)
}
defer r.Cleanup()
ctx, cancel := context.WithTimeout(context.Background(), time.Minute)
defer cancel()
err = r.StandardDRReplication(ctx)
if err != nil {
t.Fatal(err)
}
}
最後に、カスタムバイナリで既存のOSS Dockerテストを実行する例を示します:
$ GOOS=linux make dev
$ VAULT_BINARY=$(pwd)/bin/vault go test -run 'TestRaft_Configuration_Docker' ./vault/external_tests/raft/raft_binary
ok github.com/hashicorp/vault/vault/external_tests/raft/raft_binary 20.960s