前回の導入ガイドに引き続き、Getting Started の日本語（参考訳）です。今回は実践編です。実際に Vault をインスト－ルし、開発用サーバ（dev mode）を起動し、シークレットの作成・削除、AWS 上のアクセス・トークンの動的な生成、GitHub認証、認証とポリシー設定など、Vaultの基本的な動作を試す＆理解の手助けになればと思っています。
内容には十分配慮していますが、意味が分かりづらい所や、間違っているところがありましたら、ご指摘いただけると助かります。
—
■ Vault のインストール
https://www.vaultproject.io/intro/getting-started/install.html
まずはじめに Vault を自分のマシンにインストールする必要があります。Vault がサポートしているプラットフォームやアーキテクチャ向けのバイナリ・パッケージが配布されています。このページでは Vault をソースからコンパイルする方法は扱いませんが、ドキュメンテーションでは確実に信頼できる最終的なバイナリを、ソースからどのようにしてコンパイルするかを説明しています。
■ Vault インストール
Vault をインストールするには、自分のシステムに対する適切なパッケージを探し、ダウンロードします。Vault は zip アーカイブでパッケージされています。
Vault をダウンロードしたら、パッケージを unzip します。Vault は「 vault 」という名前の単一バイナリだけです。パッケージの中には別のファイルがあるかもしれませんが、Vaultの動作には支障なく、どれも削除できるものです。
手順の最後に、「 vault 」をパスの通った場所に置きます。こちらのページは Linux と Mac におけるパスの設定方法の説明です。こちらのページは Windows でのパスの通し方の説明です。
■ インストールの確認
Vault のインストール後は、インストールが正常に終わったから確認するために、新しいターミナルセッションを開き、「 vault 」コマンドが利用可能かどうかを確認します。「 vault 」コマンドを実行すると、次のようなヘルプ出力が表示されます：
$ vault usage: vault [-version] [-help] <command> [args] Common commands: delete Delete operation on secrets in Vault help Look up the help for a path read Read data or secrets from Vault renew Renew the lease of a secret revoke Revoke a secret. server Start a Vault server status Outputs status of whether Vault is sealed and if HA mode is enabled write Write secrets or configuration into Vault All other commands: audit-disable Disable an audit backend audit-enable Enable an audit backend audit-list Lists enabled audit backends in Vault auth Prints information about how to authenticate with Vault auth-disable Disable an auth provider auth-enable Enable a new auth provider init Initialize a new Vault server mount Mount a logical backend mounts Lists mounted backends in Vault policies List the policies on the server policy-delete Delete a policy from the server policy-write Write a policy to the server remount Remount a secret backend to a new path seal Seals the vault server token-create Create a new auth token token-renew Renew an auth token token-revoke Revoke one or more auth tokens unmount Unmount a secret backend unseal Unseals the vault server version Prints the Vault version
Vault が見つからないというエラーが出る場合は、環境変数 PATH が適切に設定されているか確認します。前の手順に戻り、環境変数 PATH で指定されたディレクトリのいずれかに、Vault がインストールされているか確認します。
問題なければ Vault のインストールは完了です。それでは使ってみましょう！
■ Vault サーバの起動
https://www.vaultproject.io/intro/getting-started/dev-server.html
Vault のインストールができれば、次の手順で Vault サーバを起動しましょう。Vault はクライアント・サーバ型アプリケーションとして稼働します。Vault サーバは Vault のアーキテクチャを構成する一部分であり、データストレージやバックエンドと通信します。全ての操作は Vault CLI を通して行われ、サーバとの通信には TLS 接続を用います。
このページでは、Vault サーバを起動・通信することで、どのようにしてサーバを開始できるのかを理解し、seal（シール；封印）・unseal（アンシール；封印解除） に至る手続きを理解します。
■ dev サーバの起動
はじめに、Vaultの「 dev サーバ 」を起動します（訳者注；dev = 開発向けのテスト・モードとしての起動です）。dev サーバとは、設定済みのサーバを起動するための固定フラグです。これは全く以て安全ではありませんが Vault をローカルで遊ぶには使いやすいものです。当ガイドの後方で、実際のサーバを起動する設定を扱います。
Vault dev サーバを起動するには、「 vault server -dev 」を実行します（訳者注： OS によっては root 権限が必要です）：
$ vault server -dev WARNING: Dev mode is enabled! In this mode, Vault is completely in-memory and unsealed. Vault is configured to only have a single unseal key. The root token has already been authenticated with the CLI, so you can immediately begin using the Vault CLI. The only step you need to take is to set the following environment variable since Vault will be taking without TLS: export VAULT_ADDR='http://127.0.0.1:8200' The unseal key and root token are reproduced below in case you want to seal/unseal the Vault or play with authentication. Unseal Key: 2252546b1a8551e8411502501719c4b3 Root Token: 79bd8011-af5a-f147-557e-c58be4fedf6c ==> Vault server configuration: Log Level: info Backend: inmem Listener 1: tcp (addr: "127.0.0.1:8200", tls: "disabled") ...
実行すると、上記のような出力が見えているでしょう。見ての通り dev サーバを起動すると、Vault は派手に警告を表示します。dev サーバでは全てのデータをメモリ上に保管し（暗号化はされています）、ローカルホストからは TLS 無しでポートを開き、自動的なアンシール（封印解除）を実施し、unseal キーと root アクセスキーを表示します。この状態の意味するところは、後述します。
重要なのは、dev サーバとは開発専用である点です。dev サーバを本番環境で使わないでください。もし本番環境で動かしたとしても、データはメモリ上にしか保管されないため不便ですし、再起動によってシークレットは全て消えます。
dev サーバが起動したら、何よりもまず、以下の３点を確認します：
1. ターミナル出力の「 export VAULT_ADDR … 」コマンドの部分をコピーして実行します。これは Vault クライアントが私達の dev サーバに通信するための設定です。
2. unseal key をどこかに保存します。これをどうやって安全に保存したらよいのか、心配しないでください。今は、どこかにそのまま保存します。
3. 手順 2 と同様に root token も保存します。この情報は後ほど使います。
■ サーバ稼働の確認
サーバが稼働しているかどうかを確認するために、「 vault status 」コマンドを実行します。成功すると、終了コード 0 の状態で終わるでしょう。もし接続したときにエラーが表示される場合は、先ほど表示されていた適切な「export VAULT_ADDR …」コマンドを再度確認し、確実にコピーして実行します。
実行に成功すると、次のように表示されます：
$ vault status Sealed: false Key Shares: 1 Key Threshold: 1 Unseal Progress: 0 High-Availability Enabled: false
出力内容が異なっていたとしても、数字が違っていたり Vault がシールされているかが違う程度です。それらの場合は dev サーバの再起動を試してみてください。もし表示内容が違うとすると、このガイドを読むよりも前に、dev サーバを実行したことがあれば、それが唯一の理由でしょう。
出力内容の意味は、このガイドの先で扱います。
■ 次へ
おめでとうございます！ はじめての Vault サーバを起動しました。まだシークレットを保管していませんが、それは次のセクションで扱います。
■ 初めてのシークレット
https://www.vaultproject.io/intro/getting-started/first-secret.html
dev サーバが立ち上がり動き始めたので、本題である初めてのシークレットを読み書きしてみましょう。
Vault の中心機能の１つは、任意のシークレットを安全に読み書きする能力です。このページでは CLI を使いますが、Vault のあらゆる機能全てがHTTP API を使うことで、プログラム的に扱うこともできます。
Vault に書き込まれたシークレットは暗号化された後、バックエンド・ストレージに書き込まれます。dev サーバのバックエンド・ストレージはメモリ上のものですが、本番環境ではディスク上や Consul に置くことができます。Vault によるデータ暗号化は、ストレージ・ドライバによって扱われる前に処理されます。バックエンド・ストレージの仕組み上、暗号化されていないデータは決して見ることができず、Vault 無しに復号化できないことも意味します。
■ シークレットの書き込み
シークレットを書き込んでみましょう。「 vault write 」コマンドを使えば、とても簡単にできます。次のように表示されます：
$ vault write secret/hello value=world Success! Data written to: secret/hello
これは「 value=world 」のペアを「 secret/hello 」のパスに書き込むものです。パスに関する詳細は後述しますが、現時点で大切なのはパスが「 secret/ 」で始まることであり、他のパスの場合には動作しません。接頭辞「 secret/ 」は任意のシークレットを読み書きできる場所なのです。
必要であれば、複数のデータを書き込むこともできます：
「 vault write 」は非常に強力なコマンドです。コマンドラインからデータを直接書き込めることに加え、値やキーペアをファイルだけでなく、標準入力からも同様に読み込めます。詳細については vault write documentation をご覧ください。
警告：このドキュメントでは「 key=value 」形式を基本に扱いますが、必要であればファイルを使って更に安全にできます。CLI を使ったデータ送信を行うと、それらはシェル上の履歴に残ります。実際のシークレットを扱う場合はファイルをお使いください。先のリンクにある詳細情報をご覧ください。
■ シークレットの読み込み
予想しているかもしれませんが、シークレットの読み込みには「 vault read 」コマンドを使います：
$ vault read secret/hello Key Value lease_id secret/hello/d57fe039-1eef-9f4a-f3c9-63e2b29002b8 lease_duration 2592000 excited yes value world
このように、先ほど書き込んだ値が再び表示されました。Vault はデータをストレージから読み込み、復号化します。出力形式は意図的に空白スペースで区切られており、「 awk 」のようなツールに簡単にパイプできます。
この表形式の出力に加えて、マシンと連携したり「 jq 」のようなツールを使う場合、データの出力を JSON 形式にすることもできます：
$ vault read -format=json secret/hello
{
"lease_id": "secret/hello/25f33857-15ed-b62b-dac6-4b29bb8e8bef",
"lease_duration": 2592000,
"renewable": false,
"data": {
"excited": "yes",
"value": "world"
}
}
複数の追加情報が表示されていますが、先ほど入力したデータも表示されています。スクリプトにとって JSON 出力は非常に使いやすいものです。次の例では「 jq 」ツールを使って “excited” 値を抽出します：
$ vault read -format=json secret/hello | jq -r .data.excited yes
■ シークレットの削除
どのようにシークレットを読み書きするか学びましたので、次は削除してみましょう。データを消すには「 vault delete 」を使います：
$ vault delete secret/hello Success! Deleted 'secret/hello'
■ 次へ
このセクションでは Vault の強力な CRUD 機能を使い、どのように任意のシークレットを保存するかを学びました。使いやすいものではありますが、基本的な機能にすぎません。
次は、シークレットのバックエンドに関する基本を学びましょう。
■ シークレットのバックエンド
https://www.vaultproject.io/intro/getting-started/secret-backends.html
これまでは、任意のシークレットを Vault で読み書きする方法を見て来ました。それには「 secret/ 」接頭辞を使います。この接頭辞によって、どの「 secret backend」（シークレット・バックエンド）を使うか指定するもので、Vault の標準では「 generic 」（一般）バックエンドとして「 secret/ 」をマウントします。generic バックエンドは、バックエンド・ストレージに対する raw データの読み書きを行います。
Vault は “generic” 以外のバックエンドもサポートしており、この機能がまさに Vault をユニークにしている点です。例えば、”aws” バックエンドを使えばオンデマンドで AWS アクセスキーを動的に生成します。他の例としては、（まだ現時点では存在していませんが、）HSM から直接データの読み書きを行うバックエンドがあげられます。Vault が成長しますと、更に多くのバックエンドが追加されるでしょう。
Vault においてバックエンドと表現されているものは、ファイルシステムのような動作をします。言い替えますと、バックエンドとはマウントされた特定のパスです。例えば “generic” バックエンドは接頭辞「 secret/」にマウントされます。
このページでは、システムのマウントし、操作することによって、どのように機能するかを学びます。これは、次のページで動的なシークレットを作成する時に前提となる知識だからです。
■ バックエンドのマウント
はじめに “generic” バックエンドをマウントしてみましょう。通常のファイルシステムのように、Vault は複数回、異なったマウントポイントにマウントできます。これは子緒となったアクセス制御ポリシー（後述します）を使いたい時や、異なったパスに設定したい時に役立ちます。
バックエンドをマウントするには：
$ vault mount generic Successfully mounted 'generic' at 'generic'!
標準では、マウントポイントはバックエンドと同じ名前になります。こうなっているのは、99% の割合でマウントポイントを変更したいとは思わないでしょう。この例では、私達は “generic” バックエンドを「 generic/ 」にマウントします。
マウント状況を調べるには「 vault mounts 」を使います：
$ vault mounts Path Type Description generic/ generic secret/ generic generic secret storage sys/ system system endpoints used for control, policy and debugging
予め作成されている secret パスと同じように、「 generic/ 」パスの情報を参照できます。更に「 sys/ 」パスも見えます。この導入ガイドでは扱いませんが、Vault の中心システムと対話する時に使うものです。
自分自身で確認のため、新しいマウントポイントで読み書きをするには多少の時間がかかります。余裕があれば、「 secret/ 」エンドポイントに書き込んでも、それらが「 generic/ 」から値の参照ができないことを確認しましょう。これらは同じバックエンドを持っていますが、データは共有していません。更に付け加えると、バックエンド（同じタイプでも、それ以外でも）は他のバックエンドのデータにアクセスできません。つまり各々のマウントポイントにあるデータしかアクセスできません。
■ バックエンドのアンマウント
これまでマウントのふるまいについて詳しく見て来ましたので、次はアンマウントしましょう。バックエンドがアンマウントされると、全てのシークレットは無効化（ revoked ）され、データが削除されます。もしどちらの作業が失敗するなら、バックエンドはマウントされたままになります。
$ vault unmount generic/ Successfully unmounted 'generic/'!
アンマウントについて付け加えると、バックエンドは再マウント（ remount ）できます。再マウントとは、バックエンドのマウントポイントを変更します。これはまだ破滅的なコマンドであり、保存されたデータは保持されていますが、同じパスにマウントされない限り、全てのシークレットは無効化されたままです。
■ シークレット・バックエンドとは何？
バックエンドのマウントとアンマウントができるようになると、こう考えるかもしれません。「シークレット・バックエンドは何なのでしょうか？ このマウントされているシステムの重要な点とは？」
Vault は virtual filesystem （仮想ファイルシステム）のような振る舞いをします。読み込み・書き込み・削除といった作業はバックエンドに転送され、反応したバックエンドが適切な処理を行います。例えば、”generic” バックエンドはストレージ・バックエンド（データが暗号化された直後）に単純に送るだけです。
しかし、”aws” バックエンドであれば（この後すぐ登場します）、IAM ポリシーやアクセストークンの読み書きができます。そのために「 vault read aws/deploy 」コマンドを実行しますが、これは物理的な “aws/deploy” パスから読み込むものではありません。そのかわり、AWS バックエンドは “deploy” ポリシーに基づき、動的にアクセスキーを生成します。
このような抽象化は、とても強力です。Vault は SQL データベースや HSM 等のバックエンドと、物理システムによって直接対話できるようになります。これらの物理システムだけでなく、現時点でユニークなのは、AWS IAM、ダイナミック SQL ユーザ作成等でも、同じ read/write インターフェースを使います。
■ 次へ
シークレット・バックエンドと、マウントテーブルをどのように操作するか学びました。これは次に進み、他のシークレット・バックエンドを操作するにあたって重要な知識です。
次は AWS バックエンドで動的なシークレットを生成します。
■ 動的なシークレット（ Dynamic secret；ダイナミック・シークレット）
https://www.vaultproject.io/intro/getting-started/dynamic-secrets.html
これまでは Vault の基本的なシークレットについて書いたものであり、マウントシステムを理解してきました。次は Vault の中核機能である動的なシークレットをみていきましょう。
動的なシークレットとは、アクセスした時点で生成されるシークレットのことであり、はじめて作成したシークレットのように静的なものではありません。このページでは、ビルトインの AWS シークレット・バックエンドを使い、AWS アクセスキーを動的に生成します。
動的なシークレットの力により、これまで読んできたような単純さはありません。ですが、誰かに盗まれる危険性や、同じシークレットが他のクライアントから使われる気ks遠征はありません。これらは Vault が無効化機能（revocation mechanisms）を持っているためであり（詳細は後述）、動的なシークレットは使用後に廃止されるため、保持するシークレットは最小量となります。
メモ：このページを読み始める前に、AWS アカウントを登録してください。お金がかかるような機能を使うつもりはありませんので、課金されることはないでしょう。しかしながら、あらゆる課金が発生しないという責任は持てません。
■ AWS バックエンドのマウント
それでは、はじめての動的なシークレットを生成しましょう。AWS バックエンドを使い、動的に AWS アクセスキーのペアを生成してみます。はじめに、AWS バックエンドをマウントします：
$ vault mount aws Successfully mounted 'aws' at 'aws'!
AWS バックエンドは「 aws/ 」にマウントされました。前のセクションで暑かった通り、シークレット・バックエンドとは異なった振る舞いを行うものであり、ここでの AWS バックエンドとは、AWS アクセス credentials を動的に生成するバックエンドです。
■ AWS バックエンドの設定
AWS バックエンドをマウントしたら、他の AWS credential を作成するための credential を設定します。ここでは、あなたの AWS アカウントの root key を使います。
バックエンドを設定するには「 vault write」 コマンドを使い、「 aws/config/root 」という特別なパスを使います。
$ vault write aws/config/root \ access_key=AKIAI4SGLQPBX6CSENIQ \ secret_key=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 Success! Data written to: aws/config/root
シークレット・バックエンドのパスも、必要に応じて読み書きできることを覚えておいてください。設定保存のため、後ほど使います。情報を読み返せませんので、注意してください。
$ vault read aws/config/root TODO （訳者注：実装中なので、まだ使えません。"Code: 500. Errors:"と表示されます)
セキュリティ認証情報（credentials ）は安全な状態にするよう努めてください。AWS バックエンドは ルートアカウント認証情報（root credential）を使ったとしても、読み返すことはできません。
■ Role 作成
次のステップは AWS バックエンドを使って IAM ポリシーを設定します。IAM でシステム用 AWS ユーザによって、API 権限を限定した新しい認証情報を作成します。
AWS バックエンドでは作成した認証情報と関連づけるための IAM ポリシーが必要になります。ここの例では１つの書き込みポリシーしか持ちませんが、私達は複数のポリシーをバックエンドと関連づけられます。”policy.json” という名称でファイルを保存し、次のような内容にします：
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1426528957000",
"Effect": "Allow",
"Action": [
"ec2:*"
],
"Resource": [
"*"
]
}
]
}
こちらはユーザが Amazon EC2 に対してあらゆる操作を可能とする IAM ポリシーです。ポリシーを保存し、Vault に書き込むことで、新しいロールを作成します：
$ vault write aws/roles/deploy policy=@policy.json Success! Data written to: aws/roles/deploy
再び、「 aws/roles/<NAME> 」という特別なパスを使うことによって、IAM ポリシーを Vault に書き込みます。この時、「 vault write 」コマンドに「 @ファイル名 」という特別な文法を使い、ファイルに書かれた内容を書き込みます。
■ シークレットの生成
これまで AWS バックエンドの設定とロールの作成を行いました。次はロールに対するアクセスキーのペアをリクエストしてみましょう。実行するには「 aws/creds/<名前> 」という特別なパスを使い、「<名前>」の場所にロール名を書きます。
$ vault read aws/creds/deploy Key Value lease_id aws/creds/deploy/0d042c53-aa8a-7ce7-9dfd-310351c465e5 access_key AKIAJFN42DVCQWDHQYHQ secret_key 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
成功しました！ このアクセスキーとシークレットキーは AWS 上の EC2 に関するあらゆる操作を行えるものです。必要があれば、正常に動くかどうか確認してみてください。また、これらのキーは新規作成されたものであり、先ほど入力したものとは別であることにもご注意ください。
上で表示された「 lease_id 」は Vault が更新・廃止する時などに使う特別な ID です。リース ID（ lease ID ）をコピーして、どこかに保管します。
■ シークレットの廃止
手順の最後として、これまで利用していたシークレットを無効化しましょう。シークレットを無効化すると、アクセスキーは動作しなくなります。
シークレットの無効化は「 vault revoke 」コマンドと、「 vault read 」を実行した時のリース ID を使います：
$ vault revoke aws/creds/deploy/0d042c53-aa8a-7ce7-9dfd-310351c465e5 Key revoked with ID 'aws/creds/deploy/0d042c53-aa8a-7ce7-9dfd-310351c465e5'.
完了しました！ AWS アカウントでマネジメント・コンソールを表示すると、IAM ユーザが居なくなったことが分かります（訳者注：先ほどの作業時に、自動的にユーザが作成されています）。先ほど生成したアクセスキーを使おうとしても、もう動作しないことが分かります。
このように、動的な生成・無効化が簡単に行えますので、特定の期間だけ必要な場合に、動的なシークレット作成を簡単に行えることが期待できます。
■ 次へ
このページでは初めて動的なシークレットを作成し、システムで無効化するまでの動作を見て来ました。動的なシークレットは極めて強力です。そのうち、同様の API をサポートする更に多くのシステムでアクセス認証の生成をサポートし、Vault はこのページの例にとどまらず、より価値を得られるようになるでしょう。
更に踏み込む前に、ちょっと回り道をして、ビルトイン・ヘルプシステムに関して学びましょう。
■ ビルトイン・ヘルプ
https://www.vaultproject.io/intro/getting-started/help.html
これまで「 vault write 」や「 vault read 」を複数のパスで使ってきました。generic シークレット・バックエンドを「 secret/ 」で使いましたし、動的な AWS 認証情報の作成には AWS バックエンド・プロバイダとして「 aws/ 」を使いました。いずれも読み書きの仕方やパスが異なります。特に AWS の場合は「 aws/config 」のような特別なパスがあります。
どこのパスを使うべきか、記憶したりドキュメントを定期的に読み直す代わりに、私達は Vault に直接ヘルプシステムを組み込みました。ヘルプシステムは API やコマンドラインでアクセスすることができ、あらゆるマウントのバックエンドに対して、人間が読めるヘルプを作成します。
このページでは、このヘルプシステムをどのように使うかを学びます。Vault を使い続ける上で有益なツールとなるでしょう。
■ バックエンドの概要
まず、AWS バックエンドのマウントを想定します。マウントしていなければ、「 vault mount aws 」でマウントします。もし AWS アカウントを持っていなくても、AWS バックエンドのマウントは可能です。
バックエンドのマウントに関して知りたい場合は、「 vault help 」を実行します：
$ vault help aws ## DESCRIPTION The AWS backend dynamically generates AWS access keys for a set of IAM policies. The AWS access keys have a configurable lease set and are automatically revoked at the end of the lease. After mounting this backend, credentials to generate IAM keys must be configured with the "root" path and policies must be written using the "roles/" endpoints before any access keys can be generated. ## PATHS The following paths are supported by this backend. To view help for any of the paths below, use the help command with any route matching the path pattern. Note that depending on the policy of your auth token, you may or may not be able to access certain paths. ^config/lease$ Configure the default lease information for generated credentials. ^config/root$ Configure the root credentials that are used to manage IAM. ^creds/(?P<name>\w+)$ Generate an access key pair for a specific role. ^roles/(?P<name>\w+)$ Read and write IAM policies that access keys can be made for.
「 vault help 」コマンドはパスも扱えます。マウントのルートパスを決めるにあたり、マウントの概要を知ることができます。ヘルプには説明が含まれるだけでなく、正確な正規表現を使ったマッチする条件（route）、これにはバックエンドにどのよう繋ぐべきかという、細かな説明に関する記述もあります。
■ パスのヘルプ
概要を読んだ後は、より詳しい個々のパスに関する情報を見てみましょう。そのためには、「 vaule help 」コマンドでパスを指定します。パスは正規表現に一致するようにします。ヘルプを読むために、パスが実際に有効になっている必要はありません。例えば、「 aws/cred/operator 」に関するヘルプを参照したい時は、「 operator 」ロールを作成する必要がありません。
$ vault help aws/creds/operator Request: creds/operator Matching Route: ^creds/(?P<name>\w+)$ Generate an access key pair for a specific role. ## PARAMETERS name (string) Name of the role ## DESCRIPTION This path will generate a new, never before used key pair for accessing AWS. The IAM policy used to back this key pair will be the "name" parameter. For example, if this backend is mounted at "aws", then "aws/creds/deploy" would generate access keys for the "deploy" role. The access keys will have a lease associated with them. The access keys can be revoked by using the lease ID.
パスには必要とするパラメータを指定することもできます。パラメータによっては自分自身に route するものもあります。この例における「 name 」パラメータは、正規表現の一致する名前を持つものを明示します。
更に、パスとは何なのかの説明もあります。
もっと多くのパスを調べてみましょう！ ヘルプシステムを横断し、マウントや他のバックエンドが何をするものなのか学べます。例えば、「 secret/ 」パスについて学んでみましょう。
■ 次へ
ヘルプシステムは Vault の中では最もエキサイティングな機能ではないかもしれません。しかし、Vault を日々使う上で不可欠なものです。このヘルプシステムによって、Vault のコマンドラインから離れることなく、どのようにバックエンドを使えば良いのか学ぶ手助けになるでしょう。
次は認証 について学びます。
■ 認証（ Authentication ）
https://www.vaultproject.io/intro/getting-started/authentication.html
これまで Vault の基本的な使い方について学んできました。Vault 自身の認証について理解することは重要です。これまでの Vault サーバ は dev モードとして起動していました。自動的に root あると記録していたため、認証を必要としていません。実際には、ほぼ必ず手動で認証することになります。
このページでは、特定の「 authentication（認証）」に関して扱います。次のページでは、「 authorization（権限付与）」を扱います。認証とは、Vault ユーザを認識するために使う仕組みです。各ユーザに対するアクセス制御と権限の関連付け（ACL）とは権限付与であり、このページでは扱いません。
Vault はプラグ化できる複数の認証バックエンドを持っており、Vault を使って簡単に認証を実装できるので、どのような組織でも効果を発揮するでしょう。このページでは token バックエンドと GitHub バックエンドを扱います。
■ トークン（ token ）
まずトークン認証（ token authentication ）について、あらゆる認証バックエンドよりも先に説明します。トークン認証は Vault では標準で有効化されており、無効にはできません。そのため、これをまず取り上げる理由でもあります。
dev サーバを「 vault server -dev 」で起動すると、自分の root トークン（ root token ）が表示されます。root トークンは Vault に初回接続して設定するためのものです。これは root 権限（ root privileges）を持っているため、Vault における全ての作業を行えます。権限の制限方法については、次のセクションで扱います。
トークンを作成するには「 vault token-create 」コマンドを使います：
$ vault token-create 6c38f603-6441-2161-c543-ee15b7206563
標準では現在のトークンに対する子トークン（ child token ）を生成します。これは現在のトークンを全て継承するもので、アクセス制御ポリシーが同じです。ここにおける「子」（ child ）の概念は重要です。トークンは常に親（ parent ）を持っており、ある作業により親トークンが無効化されると、子トークンも自動的に無効化されます。これにより、ユーザに対するアクセス権の削除を容易にし、ユーザによって作成されたサブトークンも同様に削除できるのです。
トークンが作成された後、無効化するには「 vault token-revoke 」コマンドを使います：
$ vault token-revoke 6c38f603-6441-2161-c543-ee15b7206563 Revocation successful.
前のセクションでは「 vault revoke 」コマンドを使いました。このコマンドは”シークレット”を無効化するために使います。”トークン”を無効化するには「 vault token-revoke 」コマンドを必ず使います。
トークンで認証するには、「 vault auth 」コマンドを使います。
$ vault auth d08e2bd5-ffb0-440d-6486-b8f650ec8c0c Successfully authenticated! The policies that are associated with this token are listed below: root
これが Vault による認証です。自分のトークンを使って、どのようなアクセスポリシーがトークンに関連づけられているか確認できます。テストには「 vault auth 」コマンドを実行し、新しいトークンを作成して確認しましょう。
■ 認証バックエンド（ Auth Backends ）
トークンだけでなく、その他の認証バックエンドも有効化できます。識別（ identifying ）の代替手段として、Vault の認証バックエンドを有効にできます。そうすると、トークンのように、アクセスポリシー群を１つに束ねられます。
利用者の環境にあわせて認証を簡単にできるように、Vault は他にも認証バックエンドを備えています。例えば、デスクトップ環境において、プライベート・キーや GitHub を基盤とした認証が簡単です。サーバ環境では、複数のシークレットを共有することがベストでしょう。認証バックエンドによって、自分が使いたい認証方式をフレキシブルに選択できます。
例えば、GitHub を使った認証をしてみましょう。まず、GitHub 認証バックエンドを有効化します：
$ vault auth-enable github Successfully enabled 'github' at 'github'!
認証バックエンドがマウントされると、シークレット・バックエンドのように、認証バックエンドは常に接頭辞「 auth/ 」ではじまります。そのため、GitHub バックエンドとしてマウントされた所は、「 auth/github 」としてアクセスできます。詳細は「 vault help 」で学べます。
バックエンドが有効化されると、次は設定です。GitHub の場合は、ユーザが何という組織に属するか（訳者注：組織とは、GitHub 上に実在する “organization” であり、そこに GitHub 利用者が含まれている必要があります）と、チームに対するポリシーを割り当て（ map し）ます：
$ vault write auth/github/config organization=hashicorp Success! Data written to: auth/github/config $ vault write auth/github/map/teams/default value=root Success! Data written to: auth/github/map/teams/default
上の設定は、私達の GitHub バックエンドは “hasihcorp” 組織（先ほど organization で入力した箇所）からのみ受け入れるもので、チームを “root” ポリシーにマップ（割り当て）しています。ここで指定したポリシーについては、次のセクションで説明します。
GitHub が有効化されると、「 vault auth 」コマンドを使って認証できるようになります：
$ vault auth -method=github token=e6919b17dd654f2b64e67b6369d61cddc0bcc7d5 Successfully authenticated! The policies that are associated with this token are listed below: root
成功しました！ GitHub を使った認証に成功しました。”root” ポリシーは先ほど認識されたユーザ情報にマップされています。”token” には自分自身の personal access token を入れてください。
認証バックエンドで認証を無効化したい場合は「 vault token-revoke 」コマンドを同様に使い、パスの接頭辞で何を無効化するか指定します。例えば、全ての GitHub トークンを無効化したいなら、次のように実行してください。他の root token を持たない状態でコマンドを絶対実行しないでください。実行するとロックアウトされて操作不能になります。
$ vault token-revoke -mode=path auth/github
完了後は、「 vault auth-disable 」によって認証バックエンドを無効化できます。こちらを実行すると、指定したバックエンドに関する全ての認証情報が、ただちに無効化されます。
$ vault auth-disable github Disabled auth provider at path 'github'!
このコマンドを実行すると、もしかすると他の root トークンを使って Vault へアクセスできなくなるかもしれません。それは先ほど GitHub で認証した時のものであれば、自身のセッションが無効化されるためです。とはいえ、これまでは開発モードとして Vault を動かしてきましたので、dev サーバを再起動することによって直ります。
■ 次へ
このページでは、Vault のユーザ認証について学びました。ビルトインのトークン・システムは他の認証バックエンドと同様に有効化できます。つまり、この時点で分かったのは、Vault に特定のユーザをどのように割り当てるかです。
複数の認証バックエンドを Vault が提供しますので、各々の組織にあわせて、最も適切な認証機構を選ぶことができます。
次のセクションでは、アクセス制御ポリシーについて学びましょう。
■ アクセス制御ポリシー（ ACLs ; Access Control Policies ）
https://www.vaultproject.io/intro/getting-started/acl.html
Vault におけるアクセス制御ポリシーは、ユーザが何にアクセスできるかを制御します。直前のセクションでは “authentication”（認証）を学びました。このセクションでは、”authorization”（権限付与）について学びます。
Vault の認証は複数のオプションやバックエンドが提供されており。これらを有効化することによって利用します。一方、権限付与や Vault のポリシーでは、常に同じ形式を使います。全ての認証バックエンドは、コアとなるポリシーによって権限を割り当てなくてはいけません。設定は Vault を通して行います。
Vault の初期化時、「 root 」ポリシーという削除できない特殊なポリシーが常に作成されます。このポリシーは、Vault の全てにアクセス可能なスーパーユーザを与えるものです。root ポリシーが権限にマップされると、何でもできるようになります。
■ ポリシーの書式
Vault のポリシーは HCL 形式です。HCL は人間が読める設定形式であり、JSON と互換性があるため、JSON も使えます。次はポリシーの記載例です：
path "sys" {
policy = "deny"
}
path "secret" {
policy = "write"
}
path "secret/foo" {
policy = "read"
}
ポリシーの書式は、アクセス制御を決定するにあたり、API のパスに対する最長プレフィックスマッチ・システムを使います（訳者注：設定ファイル上の path と、文字列が最長マッチするものが適用）。Vault に対しては、全て API を経由してアクセスする必要があるため、Vault の全ての状態に対する厳密な制御を提供します。ここには、マウントのバックエンド、認証、シークレットに関するアクセスも同様に含まれます。
先ほどのポリシーでは、ユーザはシークレットを「 secret/ 」に書き込み可能ですが、「 secret/foo 」では読み込みだけ許可されます。ポリシーは標準では拒否（deny）ですので、明示しないパスに対するアクセスは許可されません。
上のポリシーを「 acl.hcl 」という名前でファイルに保存します。
■ ポリシーの書き込み
ポリシーを書き込むには、「 vault policy-write 」コマンドを使います：
$ vault policy-write secret acl.hcl Policy 'secret' written.
ポリシーは「 vault policies 」コマンドでポリシーを見られます。ポリシーの内容は「 vault policies <名前> 」で見られます。これを実行できるのは root ユーザのみです。
■ ポリシーのテスト
ポリシーを使うには、トークンを作ってポリシーを割り当ててみましょう。どこかに root トークンを確実に保存し、あとで root ユーザに戻ってこられるようにします：
$ vault token-create -policy="secret" d97ef000-48cf-45d9-1907-3ea6ce298a29 $ vault auth d97ef000-48cf-45d9-1907-3ea6ce298a29 Successfully authenticated! The policies that are associated with this token are listed below: secret
これで「 secret/ 」にデータを書き込めることが確認でき、一方で「 secret/foo 」は読み込みしかできないことが分かります。
$ vault write secret/bar value=yes Success! Data written to: secret/bar $ vault write secret/foo value=yes Error writing data to secret/foo: Error making API request. URL: PUT http://127.0.0.1:8200/v1/secret/foo Code: 400. Errors: * permission denied
また、ポリシーによって「 sys 」に対してもアクセスできないため、「 vault mounts 」のようなコマンドも、同様に機能しません。
■ 認証バックエンドに対するポリシーの割り当て
Vault は複数のバックエンドが認証に使えるのとは違い、単一のポリシー権威しか持ちません。これらのコア・ポリシーを使い、マウントできるあらゆる認証バックエンドに対する権限の割り当てもできます。
各々のバックエンドを決定する前に「 vault help 」システムを使うことで、認証バックエンドに権限をどう割り当てるか確認できます。例えば、GitHub を使う場合は「 map/teams/<チーム名> 」パスを使います：
$ vault write auth/github/map/teams/default value=secret
Success! Data written to: auth/github/map/teams/default
GitHub における “default” のチームとは、どのチームに割り当てられても問題なく利用可能なポリシーです。
他の認証バックエンドでは別の方法が使われたとしても、権限をポリシーに割り当てるのは似たような仕組みです。
■ 次へ
ポリシーは Vault における重要な部分です。root トークンは使い始めるのに最も簡単ですが、Vault に素早くアクセス制限をかけたい時や、ポリシー・システムを同様に使いたい時もあるでしょう。
構文やポリシーの機能は理解しやすく使いやすいものです。そのため、認証バックエンドは、全て中央ポリシーシステム（ central policy system ）に割り当てる必要があります。しかし、その時に学ばなくてはいけないのは、このポリシーシステムだけです。
次は Vault のデプロイについて扱います。
■ Vault のデプロイ
https://www.vaultproject.io/intro/getting-started/deploy.html
これまで dev サーバを使い、自動的な認証や、セットアップ、メモリ上のストレージ、等をみてきました。Vault の基本が分かりましたので、実際の環境で Vault をどのようにデプロイするかを学ぶことは重要です。
このページでは、Vault をどのように設定して起動するか、seal・unseal 手順、Vault のスケールについて学びます。
■ Vault の設定
Vault の設定には HCL ファイルを用います。繰り返しになりますが、これらのファイルは JSON 互換です。Vault 向けの設定ファイルは比較的シンプルです。以下は記述例です：
backend "consul" {
address = "demo.consul.io:80"
path = "vault"
}
listener "tcp" {
address = "127.0.0.1:8200"
tls_disable = 1
}
設定ファイルの中で、主に２つの設定を行います：
* 「 backend 」- Vault がストレージのために使う物理的なバックエンドを指定します。これまで dev サーバは “inmem”（メモリ上）で使っていましたが、上の例では Consul を使っています。Cosnul は、より本番環境に対応したバックエンドです。
* 「 listener 」- Vault が API リクエストを受け付けるために、１つまたは複数のリスナーを指定します。上の例では、ローカルホスト上のポート 8200 を TLS 無しで受け付け（ listen し ）ます。
それでは、上の設定をコピー＆ペーストしましょう。Consul の「 path 」を書き換え、このガイドに書かれているものと重複しないよう、ユニークな Consul サーバのパスを指定してください。以後、私達はこのデモ用クラスタを使って、どのように Vault をデプロイするか学んでいきます。
警告：このデモ用 Consul クラスタは 30 分毎にデータを削除します。そのため、Vault を使って学んでいる間に、データが消える可能性があります。その場合は、Vault を起動しなおした直後であれば、もう30分間はデータが確保されることになります。
■ サーバの起動
適切に設定をした後は、サーバの起動は以下に示すようにシンプルです。先ほど作成・
保存した設定ファイルのパスを、「 -config 」フラグの場所に適切に書き換えてください。
$ vault server -config=example.hcl ==> Vault server configuration: Log Level: info Backend: consul Listener 1: tcp (addr: "127.0.0.1:8200", tls: "disabled") ==> Vault server started! Log data will stream in below:
設定ファイルと同じものが、Vault が出力する情報の一角に表示されます。この手順は systemd や upstart などのリソース・マネージャを使って実行されるべきです。
あらゆるコマンドが実行できないことに気をつけてください。これはまだ、何ら認証情報を持っていないからです！ Vault サーバを始めてセットアップする時は、「 初期化 」する必要があります。
■ Vault の初期化
初期化（ initialization ）は Vault の設定における一番目の手順です。サーバは、これまで Vault 用として使われたことがない新しいバックエンドを使おうとする時、一度だけ実行します。
初期化中は、暗号化キーの生成、unseal キーの生成、そして初期 root トークンがセットアップされます。Vault を初期化するには「 vault init 」を使います。これは認証されていないリクエストですが、データを全く持たない新しい Vault の時のみ動作します。
$ vault init Key 1: 427cd2c310be3b84fe69372e683a790e01 Key 2: 0e2b8f3555b42a232f7ace6fe0e68eaf02 Key 3: 37837e5559b322d0585a6e411614695403 Key 4: 8dd72fd7d1af254de5f82d1270fd87ab04 Key 5: b47fdeb7dda82dbe92d88d3c860f605005 Initial Root Token: eaf5cc32-b48f-7785-5c94-90b5ce300e9b Vault initialized with 5 keys and a key threshold of 3! Please securely distribute the above keys. Whenever a Vault server is started, it must be unsealed with 3 (the threshold) of the keys above (any of the keys, as long as the total number equals the threshold). Vault does not store the original master key. If you lose the keys above such that you no longer have the minimum number (the threshold), then your Vault will not be able to be unsealed.
初期化時の出力には、２つの重要な情報が含まれています。「 unseal keys 」と「 initial Root Token 」です。これは Vault のデータの中でも初回しか表示されないものであり、unseal key がこのように集まるのも一度だけです。
この理由により、この入門ガイドでは、これら全ての鍵を何処かに保存するものとして進めます。実際のデプロイ手順では、決してこれらの鍵を同じ場所に保存しないでください。
■ シールとアンシール
初期化された Vault サーバは、全て 「 sealed 」（シール済み、封印された）状態で起動します。設定によって、Vault は物理ストレージにアクセスできますが、どのように復号化するのか分からないため、一切のデータを読み込むことができません。Vault に対して、データをどのように復号化するか教える手続きが必要で、これは「 unsealing 」（シール解除、封印解除）と呼ばれます。
アンシールは Vault 起動時に毎回行わなくてはいけません。これは API かコマンドラインを通して実行できます。Vault をアンシールするには、「 閾値 」として指定した数の unseal キーが必要です。先の出力結果における「 key threshold 」（鍵の閾値）は 3 です。つまり Vault のアンシールには、生成された 5 つの鍵のうち 3 つが必要であることを意味しています。
メモ：Vault は unseal key の断片だけでなく、一切の情報を保管しません。Vault は Shamir’s Secret Sharing （シャミアの秘密分散法；日本語ではこちらが詳しい）として知られているアルゴリズムを使用し、マスターキーを断片に分割します。閾値の鍵が揃った時にのみ、データにアクセスできるようになります。
アンシールを始めるには「 vault unseal 」コマンドを使います：
$ vault unseal Key (will be hidden): Sealed: true Key Shares: 5 Key Threshold: 3 Unseal Progress: 1
それから有効なキーを貼り付け、確認すると、Vault がシールされているように見えるかもしれませんが、アンシールが進行します。Vault は 3 つのキーのうちの 1 つであると識別します。アルゴリズムの性質により、Vault は閾値に到達するまで正しいキーの情報が分かりません。
アンシールの手続きはステートフルです（状態を保存しません）。同じサーバを使っているのであれば、他のコンピュータ上で「 vault unseal 」を実行してもアンシールの手続きは行われます。これはアンシールの手続きにおける極めて重要な設計です。つまり、複数の鍵を用いた複数の人々によって、Vault をアンシールする必要があります。Vault は複数のコンピュータからアンシールできますが、キーは一緒にしておくべきではありません。悪意のあるオペレータが一人いたとしても、攻撃のために十分なキーを持っていないのです。
「 vault unseal 」が進行すると、Vault のアンシールが完了します。3つの鍵は全て異なっている必要がありますが、違っていれば他は何でも構わないことを覚えておいてください。キーが正しければ、次のような出力が見られます：
$ vault unseal Key (will be hidden): Sealed: false Key Shares: 5 Key Threshold: 3 Unseal Progress: 0
「 Sealed: false 」（シール失敗）が意味するのは、Vault がアンシールされました！
これで遠慮なく無効なキーを入れて遊んだり、異なったキーを入れたりできます。アンシールの手順を理解することは非常に重要です。「 vault auth 」で root トークンを認証に使う方法から、移行する準備が整いました。
root ユーザであれば、「 vault seal 」によって Vault を再びシールできます。単一のオペレータのみで実行できます。これにより、緊急時に他のオペレータに相談することなく、一人のオペレータによって Vault をロックダウン（閉鎖）できます。
Vault が再びシールされると、メモリ上のあらゆる情報（暗号化キーを含みます）がクリアされます。Vault は安全になり、アクセスからロックダウンします。
■ 次へ
これまで、どのように設定するか、初期化するか、Vault をシール・アンシールするか分かりました。これらは実際の環境に Vault をデプロイするにあたって、必要な基礎知識です。Vault がアンシールされた場合は、（ Vault をアンシール状態で動作させた）この入門ガイドで辿ったようにアクセスしてみてください。
おめでとうございます！ これで Vault を使い始めるための、全ての基本が分かりました。
それでは、次のステップという、あなたが達成したい何らかに関する説明ページを用意しました。
■ 次のステップ
https://www.vaultproject.io/intro/getting-started/next-steps.html
Vault 入門ガイドの結びです。願わくは、あなたに Vault の可能性に対してエキサイトしていただき、この知識が、あなたの環境改善に用いられるための準備になればと思います。
私達は、このガイドを通して Vault の基本的な全ての機能を扱いました。シークレットを安全にすることは重要なので、次のステップとして、私達は以下をお読みになることをお勧めします。
* Documentaiton – Vault の全機能に対する詳細なリファレンス・ガイドです。
—-
