本番環境でも使えるVaultクラスタをAWS上に構築する（5分以内で！）

機密情報の暗号化や証明書の管理など、シークレット管理で利用するVaultを本番環境で利用するには、クラスタ構成を組むことを推奨します。クラスタ構成を組むことで可用性と耐障害性を高めることができます。今回は、「本番環境として利用できるVaultクラスタをAWS上に構築する（5分以内で！）」と題した記事を日本語訳してお届けします。著者のSean CarolanはHashiCorp社のテクノロジー・スペシャリストで、技術者だけでなくビジネスサイドにもわかりやすく技術を説明することを得意としています。

---

ところで、Vaultをご存じですか？

HashiCorp社のVaultは、マルチクラウド環境で利用可能なAPIベースのシークレット管理システムで、パスワードや鍵、証明書を安全に管理します。Vaultは様々な暗号化やクレデンシャル管理を提供します。一時的に必要になるクラウドのクレデンシャルの配布やクレジットカード番号などの機密情報の暗号化、アプリケーションのSSL証明書の管理などがVaultで行えます。Vaultで利用可能なシークレットエンジンについてはVaultのホームページをご覧ください。

[訳注1] クレデンシャル：IDやパスワードをはじめとした認証に必要な情報の総称

Vaultは、例えるならば、シークレット管理におけるスイス・アーミーナイフのようなものです。

どうです？カッコいいでしょ！？では、この多用途で気の利いたシークレットエンジンをクラウド環境で利用するにはどうすれば良いでしょうか。いくつか考慮すべきポイントがあるので、簡単というわけにはいきません。Vaultはシステムに認証機能を提供するため、高可用性が求められます。つまり、クラスタ構成されたマシン上で実行するようにVaultを構成する必要があるのです。クラスタ構成されたシステムでは、1台か2台のマシンが停止しても、全体としては動作し続けます。正しく構成されたVaultクラスタであれば、竜巻や隕石の衝突などの自然災害が起きても動作し続けるでしょう。もっとも、小さな隕石ならですが・・・。

高可用性と耐障害性

典型的なVaultクラスタの構成を次の図に示します。この構成では3つのゾーンでVaultクラスタを構成しています。

この図には8つのサーバがあります。そのうち3つはVaultのサーバで、残りの5つはConsulが稼働するサーバです。この構成では、Consulサーバはストレージとして機能します。これらConsulサーバは、低レイテンシの（パフォーマンスの良い）分散ストレージだと捉えてください。SANやRAIDアレイのようなものですね。この構成の基本的な考え方は、データを分散して配置することで、3つのうち2つのゾーンが停止してもクラスタとしては動作し続けるようにする、というものです。すべてのデータは暗号化され、障害に備えて5つの場所（Consulサーバ上）に分散して保存されます。

このように、Vaultクラスタを本番環境で使う標準構成では8つのインスタンスを必要としますが、他にも設定が必要な箇所があります。安全な通信を行うにはSSL証明書が必要です。また、Vaultクラスタの前にロードバランサを設置して、適切なノードに通信が振り分けられるようにする必要があります。

備考：高可用性を維持しつつ、もっとコンパクトなValutクラスタの方が望ましい場合には、Valutの新しいストレージオプションを検討してみてください。この新しいストレージオプションでは3つのノードでVaultクラスタを構成しますが、1ノードの停止までであれば可用性を維持することができます。ただし、この機能は本稿執筆時点ではまだベータ版です。

[訳注2] このオプションは2020年4月リリースのVault1.4で正式にサポート。Vault1.4ではシークレットを保管するためのストレージがVaultサーバに内蔵され、運用管理に要する費用と手間を大幅に軽減できるようになった。
LAC WATCH：HashiCorp Vaultの最新バージョン1.4がリリース、ラックが注目する2つの新機能とは？

複雑な課題でも、解決策は複雑とは限らない

世の中には複雑な課題があります。それら（例えば、シークレットをどこかのネットワークで安全に管理するとか）を解決しようとすると、複雑なソリューションが必要になるときがあります。ただ、課題が複雑なものであっても、Vaultのインストールは複雑ではありません。Infrastructure as Codeを活用すれば、複雑な構築手順が必要であっても、あるべき状態を定義するだけで済みます。

[訳注3] Infrastructure as Code：構築・運用に関わる作業をコード化、自動化するアプローチ

もしかしたら、「なんでTerraformを使わないの？」と思っているかもしれないですね。Terraformは、Infrastructure as Codeを実現するツールで、あらゆるクラウド環境で利用できます。ですから、Terraformを使ってVaultをインストールすることももちろんできます。しかし、TerraformだけがInfrastructure as Codeを実現するツールではありません。すでにCloudformationを使っているという方もいるかもしれませんね。HashiCorp社の製品群がすごいのは、個々の製品を単独で使うこともできるし、組み合わせて使うこともできる、というところです。要するに、Terraformのエキスパートの力を借りなくとも、Vaultをセットアップして使用できるのです。

[訳注4] HashiCorpのビジョン、ロードマップ、プロダクト設計のガイドラインは「The Tao of HashiCorp（HashiCorp道）」として公開されている。そのうちの1つに「Simple, Modular, Composable（シンプルで、モジュール型で、組み合わせ可能な）」というものがある。これはUnixのツールのように、ひとつひとつのコマンドはシンプルでも、組み合わせて使うことで大きな仕事ができる製品群を目指す、ということである。

Vaultの簡易自動デプロイメント

この記事は、素早くかつ安全に、最小の労力とセットアップ時間でHashiCorp Vaultを準備したい初中級のAWS経験者を対象にしています。当社では、いくつかの質問に答えるだけでVaultクラスタがセットアップできる、AWS Cloudformationのテンプレートを用意しました。できるだけ、AWSのネイティブ・サービスを利用しています。例えば、Route 53、Key Management Service（KMS）、Secrets ManagerそしてAWS Certificate Managerなどです。このテンプレートとPackerスクリプトはこちらからダウンロードできます。

GitHub - scarolan/vault-aws-cf: AWS Cloudformation Template for standing up a reference architecture Vault cluster

このテンプレートを使うとどんなものが構築されるかを簡単に説明します。

• 3つのパブリックサブネットと3つのプライベートサブネットを持つVPC
• Vault とConsulのOS（基本ソフト）にはCentOS 7を使用
• 踏み台サーバのOS（基本ソフト）にはAWS Linux（最新版）を使用
• 3台のVaultサーバ と5台のConsulサーバをプライベートサブネットに分散
• インターネットから直接アクセスさせないサーバには踏み台サーバを経由
• AWS Certificate Managerが管理する、FQDNに対応するSSL証明書
• VaultをUnsealするためのキーはAWS Key Management Service に保存し、AWS Key Management Service を使ってVaultのUnsealを実行
• Vaultクラスタが起動するまでの所要時間は約10分から15分。クラスタは初期化されていない状態で起動。VaultのAPIは8200番ポートを使い、インターネットから接続可能

[訳注5] Unseal：Vaultの利用を開始する時に、Vaultが暗号化して保存したシークレットを復号するためのキーを取得する手順のこと。Vaultは、起動時には復号に必要なキーを持っておらず、シークレットの読み取りができないため、この手順が必要になる。

インストールを始める前に

このテンプレートを使うにあたっては、いくつかの前提条件があります。第一に、AMI（Amazonマシンイメージ）を構築しておく必要があります。HashiCorp社ではVault以外にもPackerという素晴らしいツールを提供しており、これを使えば、必要なソフトウエアのインストールと設定を施したオリジナルのAMIを簡単に構築できます。Packerを使ったことがなければ、まずはイメージを構築することにチャレンジしてみてください。Packerのテンプレートを使って、Vault用のAMIと、Consul用のAMIを作ってみましょう。なお、この記事ではPackerの詳細については触れません。

二つ目の前提条件は、DNSゾーンをAWS Route 53で管理していることです。ドメインをAWSから購入していれば、DNSゾーンもRoute 53で自動的に管理されています。Route 53ではDNSホスト名とSSL証明書を自動で生成します。この記事のサンプルでは「fto.hashidemos.io」というDNSゾーンを利用しています。

Packerを使ってAMIを構築し、ドメインもしくはサブドメインがRoute 53で管理されていれば、Cloudformationのテンプレートを使う準備が整っています。テンプレートの「Mappings」セクションで、構築したAMIが指定されているのを確認してください。もしVaultクラスタを異なるリージョンで構築したいのであれば、それぞれのリージョンごとにAMIを構築しておく必要があります。この記事のサンプルでは「us-east-1」リージョンを使用します。

AWSコンソールでVaultクラスタを構築する

ここから先の作業はAWSコンソールから行います。ざっと手順を見てみましょう。まず、AWSコンソールにログインし、Route 53の管理画面を開いてください。そして、Vaultクラスタで利用する「ホストゾーンID」を探してください。このホストゾーンIDは、すぐに必要になるのでメモしておきましょう。

次に、Cloudformationの管理画面を開いて「スタックの作成」をクリックします。テンプレートはすでに用意してあるので「テンプレートの準備完了」を選択します。テンプレートはAmazon S3に保存しておくこともできますし、手元のパソコンにあるものをアップロードすることもできます。手元のパソコンからアップロードするには、aws_vault_cf.ymlファイルを選択してAWSコンソールからアップロードしてください。

「Next」をクリックして、必要なパラメータを入力していきます。最初に、Cloudformationスタックに名前を付けましょう。ここで設定した名前はコンソールに表示されます。名前に使えるのはアルファベット、数字、ダッシュ（-）だけです。

Vaultクラスタのホスト名を設定します。ホスト名は完全修飾ドメイン名（FQDN）が必要です。例えば、「vaultdemo.fto.hashidemos.io」といったものです。次に、ドロップダウンリストからアベイラビリティゾーンを3つ選択します。どのアベイラビリティゾーンを選択しても構いませんが、3つを選択する必要があります。そして、ドロップダウンリストからSSHキーを選択します。これは踏み台サーバにSSH接続する場合に使用します。インターネット経由では、踏み台サーバを通して他のサーバに接続します。最後に、ドロップダウンリストから今回使用するホスト名を選択します。先ほど設定したVaultクラスタのFQDNと合致していることを確認してください。

ここまでの作業で主なセットアップ手順は終わりです！「Next」をクリックして、必要に応じてオプションを設定してください。残りの設定はデフォルトで問題ありません。

「Create stack」ボタンをクリックする前に、図6にあるチェックボックスにチェックする必要があります。これにチェックを入れることで、テンプレートによるIAM作成を許可したことにます。このテンプレートが作成するロールは、VaultとConsulのインスタンスがAWSのサービス（Secrets ManagerやKMSなど）と対話することを許可するためです。Cloudformationのテンプレートを調べれば、ロールに付与されるパーミッションを確認できます。

Vaultクラスタの構築完了まで、あと少しです。次に説明する手順は、ドメイン名ごとに1回ずつ実行する必要があります。AWS Certificate Managerの画面に移動すると、「検証保留中」 の状態にある新しいドメイン名が見つかると思います。小さな下矢印をクリックして、青色の 「Route 53でのレコードの作成」ボタンを表示してください。このボタンをクリックしてDNSレコードを作成し、SSL証明書を検証します。この操作は、このドメイン名で最初にクラスタを作成するときだけ必要です。同じドメイン名でクラスタを再構築する場合には、すでに検証済みのDNSレコードが使用されるので、この手順は不要になります。

それでは、Cloudformationの画面に戻って構築が完了するのを待ちましょう。構築が完了するまで30分程度かかるかもしれません。・・・ええ、もちろん皆さんのお気持ちはわかりますよ、きっと「5分で出来るって言ったじゃないか！」って思ってるんでしょ！

まあ落ち着いてください！この手順が必要なのは、新しいDNSネームとAWS Certificate Managerの証明書を使って構築する最初の1回だけです。DNSレコードとSSL証明書を作成し検証してしまえば、同じDNSネームを使う限り、クラスタの再構築はもっと手短に終えることができます。初回の手順に時間がかかってしまうのはどうしようもありません。障害対応の一環として、手早くクラスタを起動する必要がある場合には、この手順を事前に行っておくと良いでしょう。私たちの検証では、ちょうど5分くらいでCloudformationの構築を完了できました。

Cloudformation スタックのリソースタブをクリックすると、Vaultクラスタが構築されているのを確認することができます。テンプレートには72のコンポーネントが定義されており、順番に構築されていきます。最初にネットワークが敷設され、次に証明書、仮想マシン、DNSレコードそしてロードバランサという順番で構築されます。

スタックの構築が完了すると、ステータスがCREATE_COMPLETEに変わります。これで核となる環境は構築されたのですが、Vaultクラスタの設定が残っています。出力タブをクリックして、VaultクラスタにアクセスするためのURLを確認してください。

このURLをクリックしてVaultにアクセスします。次のようなVaultセットアップ画面が表示されるはずです。

この画面では、Vaultをunsealする際に使うマスターキーを作ります。ここでは、Key sharesと Key thresholdにはいずれも「1」を入力しておきます。これはマスターキーを分割しない、ということです。「Initialize」ボタンをクリックしてマスターキーを作成します。

作成したマスターキーは、安全な場所に保管しておきましょう。印刷するかUSBドライブにコピーして、安全な場所に物理的に保管しておきましょう。こうしたマスターキーの物理的なコピーは、障害対応や緊急時に役に立ちます。もちろん、マスターキーは暗号化してストレージに保存され、対応するAWS KMSキーでしか復号できません。

マスターキーが作成されれば、Vaultクラスタの稼働まではあと2、3分です。Continue to Authenticateをクリックしてログインします。もし「もうしばらくお待ちください」というエラー画面が表示されたら、1、2分待って画面を再読み込みし、改めてログインしてみてください。ロードバランサがプライマリのVaultノードを発見すれば、クラスタは安定し、APIリクエストを受け付ける準備が整います。ログインして次の画面が表示されれば、Vaultクラスタが起動していることになります。

おめでとうございます！これでVaultクラスタの初期設定と導入が完了しました。他にもたくさんのチュートリアルを用意しています。今回構築したVaultクラスタでどんなことができるかを学ぶにはこちらのコンテンツをおススメします。

注意：この記事で使われているソフトウエアはオープンソースです。本番環境で利用することもできますが、利用される方ご自身の責任の下でお使いください。Vaultの商用サポートが必要な場合はラックまでお問い合わせください。