HashiCorp Vault 導入・初期設定手順の確認

Last updated at 2026-04-19Posted at 2026-03-29

はじめに

証明書管理を行う HashiCorp Vault をVM上に導入・設定した記録です。

HashiCorp Vault は、パスワード・APIキー・TLS証明書などの機密情報（シークレット）を一元管理するためのツールです。アプリケーションのコード内や設定ファイルに直接認証情報を書かずに済むため、セキュリティリスクを大きく低減できます。

動画

当記事を元にした動画です。

環境

RHEL OS 9.6 (AWS環境 EC2 )

TCP 8200, 443, 22 ポートをセキュリティ・グループで Inbound で許可

【前提条件・事前準備】

ライセンスファイル: あらかじめライセンスファイル（vault-mar.hclic）を用意し、サーバー上の /opt/vault/ に配置している前提で進めます。

TLS証明書: Vaultのインストール時に自動生成される自己署名証明書（/opt/vault/tls/配下）を使用します（※本番環境では正規の証明書の使用を推奨します）。

HashiCorp Vault インストール

参照doc: https://developer.hashicorp.com/vault/install

Vault は HashiCorp 公式リポジトリから yum/dnf でインストールできます。インストール時に TLS 用の自己署名証明書が /opt/vault/tls/ に自動生成されます。本番環境では後述の手順で信頼済み CA の証明書に差し替えることを推奨されます。

1: yum-utils インストール

# yum install -y yum-utils

2: RHEL 用の hashicorp repository 設定

# yum-config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo

3: 登録リポジトリ確認

# dnf repolist

repo id                        repo name
hashicorp                      Hashicorp Stable - x86_64
rhel-9-appstream-rhui-rpms     Red Hat Enterprise Linux 9 for x86_64 - AppStream from RHUI (RPMs)
rhel-9-baseos-rhui-rpms        Red Hat Enterprise Linux 9 for x86_64 - BaseOS from RHUI (RPMs)
rhui-client-config-server-9    Red Hat Enterprise Linux 9 Client Configuration

-> hashicorp が追加されたことを確認します。

4: Vault インストール

# yum -y install vault

実行ログ

# yum -y install vault
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server. You can use "rhc" or "subscription-manager" to register.

Hashicorp Stable - x86_64                                            27 MB/s | 2.1 MB     00:00
Last metadata expiration check: 0:00:01 ago on Sun 22 Mar 2026 12:08:20 PM UTC.
Dependencies resolved.
====================================================================================================
 Package              Architecture          Version                  Repository                Size
====================================================================================================
Installing:
 vault                x86_64                1.21.4-1                 hashicorp                168 M

Transaction Summary
====================================================================================================
Install  1 Package

Total download size: 168 M
Installed size: 493 M
Downloading Packages:
vault-1.21.4-1.x86_64.rpm                                            47 MB/s | 168 MB     00:03
----------------------------------------------------------------------------------------------------
Total                                                                47 MB/s | 168 MB     00:03
Hashicorp Stable - x86_64                                           7.9 kB/s | 3.9 kB     00:00
Importing GPG key 0xA621E701:
 Userid     : "HashiCorp Security (HashiCorp Package Signing) <security+packaging@hashicorp.com>"
 Fingerprint: 798A EC65 4E5C 1542 8C8E 42EE AA16 FCBC A621 E701
 From       : https://rpm.releases.hashicorp.com/gpg
Key imported successfully
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                            1/1
  Running scriptlet: vault-1.21.4-1.x86_64                                                      1/1
  Installing       : vault-1.21.4-1.x86_64                                                      1/1
  Running scriptlet: vault-1.21.4-1.x86_64                                                      1/1
Generating Vault TLS key and self-signed certificate...
...+++++++++++++++++++++++++++++++++++++++++++++*.+............+....+.....+...+...+.......+...+.....+....+...+..+...............+...+...+............................+..............+.+...........+....+..+...+....+...+...+++++++++++++++++++++++++++++++++++++++++++++*.....................+..+.+............+....................+....+.........+.....+....+.....+...............+...+..........+.....+....+......+.........+......+............+............+...+...+.....+.........+...+.......+.....+...+...............+.+..+....+........+.+......+...........+...............+...+.......+..................+...........+......+...+....+...............+..+...............+.+...+....................+++++
.+.....+++++++++++++++++++++++++++++++++++++++++++++*...+.....+......+....+...+...............+..............+...+...+.........+......+.........+.+..+..........+..+.........+....+...........+......+....+.....+.+...........+...+......+...+...+.......+..+.+...+.........+..+...+.......+...........+.......+...+..+...+...+...............+............+....+...+..+++++++++++++++++++++++++++++++++++++++++++++*.................+...+........+.+.........+..+...+.......+.....+..........+........+....+..+.+.......................................+...+.....+......+.+......+.....+..........+..+...+....+......+...+...............+......+...+..+....+..+.......+......+..+.........+...+.+...........+................+..+...+.........+.+........+......+..........+.....+..........+......+............+...+..+......+............+...+....+............+.........+...........+...+.+.........+..+....+......+....................+..........+.....+....+++++
-----
Vault TLS key and self-signed certificate have been generated in '/opt/vault/tls'.

  Verifying        : vault-1.21.4-1.x86_64                                                      1/1
Installed products updated.

Installed:
  vault-1.21.4-1.x86_64

Complete!

ライセンスファイルの準備と配置

設定ファイル編集（バックアップを取得してから編集します）

# cp -p /etc/vault.d/vault.hcl /etc/vault.d/vault.hcl_org

# vi /etc/vault.d/vault.hcl

/etc/vault.d/vault.hcl

# cat /etc/vault.d/vault.hcl | grep -v ^#

license_path = "/opt/vault/vault-mar.hclic"    # ライセンスファイルのパス


ui = true   # Web UI を有効化（ブラウザからアクセス可能にする）

# Integrated Storage（内蔵 Raft）を使用。外部 DB 不要でクラスタ構成が可能
storage "raft" {
  path    = "/opt/vault/data"    # データ保存先
  node_id = "vault-node1"        # クラスタ内でのノード識別子
}


listener "tcp" {
  address       = "0.0.0.0:8200"     # 全インターフェースで 8200 番を待ち受け
  tls_cert_file = "/opt/vault/tls/tls.crt"
  tls_key_file  = "/opt/vault/tls/tls.key"
}

api_addr = "https://xx.xx.xx.xxx:8200" 　# 外部から到達可能なアドレス（クラスタ参加時に使用）

システム起動時のサービス有効化と起動確認

# systemctl enable vault
# systemctl start vault
# systemctl status vault

vault サービス・ステータス確認 (ログは折りたたんでいます)

 systemctl status vault
● vault.service - "HashiCorp Vault - A tool for managing secrets"
     Loaded: loaded (/usr/lib/systemd/system/vault.service; enabled; preset: disabled)
     Active: active (running) since Tue 2026-03-24 08:53:41 UTC; 7s ago
       Docs: https://developer.hashicorp.com/vault/docs
   Main PID: 1891 (vault)
      Tasks: 7 (limit: 47791)
     Memory: 24.1M (peak: 26.1M)
        CPU: 101ms
     CGroup: /system.slice/vault.service
             └─1891 /usr/bin/vault server -config=/etc/vault.d/vault.hcl

Mar 24 08:53:41 ip-10-0-0-13.ap-northeast-1.compute.internal vault[1891]:            Recovery Mode: false
Mar 24 08:53:41 ip-10-0-0-13.ap-northeast-1.compute.internal vault[1891]:                  Storage: raft (HA available)

~ 省略 ~

TLS/HTTPS 設定

CLIなどからアクセスする際に自己署名証明書でエラーにならないよう、CA証明書を信頼させます（クライアント側の設定）。

 cp /opt/vault/tls/tls.crt /etc/pki/ca-trust/source/anchors/vault-ca.crt
# update-ca-trust

インストール時に生成される証明書は自己署名のため、クライアント（ブラウザや vault CLI）はデフォルトで信頼しません。
上記の手順で OS のトラストストアに登録することで、VAULT_SKIP_VERIFY=true を使わずに安全に通信できるようになります。
CLIでも同様に環境変数 VAULT_CACERT で証明書を指定する方法があります。
( export VAULT_CACERT=/opt/vault/tls/tls.crt)

参考文書

Vaultの設定パラメータ

GUI 設定

Step 1: Web UIへのアクセス

Vaultサーバーを起動した状態で、ブラウザを開きます。

アドレスバーに設定ファイルで入力した api_addr の http://xx.xx.xx.xx:8200 を入力してアクセスします。

Create a new Raft cluster を選択して新しい Raft cluster を作成します。

Step 2: Vaultの初期化 (Initialization)

初期化（Initialization）は Vault の生涯で 1回だけ実行する操作です。ここでマスターキーが生成され、暗号化されたストレージへのアクセスに必要な Unseal Key と Root Token が払い出されます。

未初期化の状態の場合、アクセスすると自動的に「Initialization」の画面が表示されます。

Key shares: 発行するマスターキーの分割数（デフォルトは5）を入力します。
Key threshold: 封印解除（Unseal）に必要なキーの数（デフォルトは3）を入力します。

「Initialize」ボタンをクリックします。

Step 3: キーとトークンの保存（※超重要）

Shamir's Secret Sharing（シャミアの秘密分散）という仕組みを使っています。マスターキーを Key shares 個に分割し、そのうち Key threshold 個が揃わないと復元できません。例えばデフォルト（5分割・3個必要）なら、担当者3名がそれぞれ1つずつ保管し、誰か1人が欠けても運用を継続できます。

初期化が完了すると、Unseal Key（封印解除キー）と Initial Root Token が画面に表示されます。

「Download Keys」 ボタンをクリックしてJSONファイルとしてダウンロードするか、「Copy」 ボタンを使って安全なパスワードマネージャーなどに記録します。

この画面を閉じると二度とキーは確認できないため、確実に保存したことを確認してから、「Continue to Unseal」 をクリックします。

Step 4: Vaultの封印解除 (Unseal)

Vaultは起動直後、データが暗号化されてアクセスできない「Sealed（封印）」状態になっています。これを解除（Unseal）しないと一切の操作ができないため、初期化時に発行されたUnseal Keyを使って封印を解く必要があります。

参考：https://developer.hashicorp.com/vault/docs/concepts/seal

「Unseal Vault」 という画面が表示されます。

Key portion の入力欄に、先ほど保存した Unseal Key のうち1つを貼り付けて「Unseal」をクリックします。

画面の指示に従い、設定した Threshold（デフォルトなら3回）の数だけ、異なるキーを入力して「Unseal」を繰り返します。(今回はKey入力を3回実施しました)

Step 5: Root token でのログイン

封印が解除されると、自動的にログイン画面（Sign in to Vault）に遷移します。

Method のプルダウンが Token になっていることを確認します。

Token の入力欄に、前の手順で保存した Initial Root Token を貼り付けます。

「Sign in」 をクリックしてログインします。

GUI 確認

ログイン後、Vaultのダッシュボードが表示されました。

Raft Storage に移動すると、構成されていることが確認できました。

admin ポリシー作成

Vault のポリシー（ACL Policy）は「どのパスに対してどの操作を許可するか」を HCL 形式で記述します。Root Token は全権限を持つため、日常運用では必要最小限の権限を持つポリシーを作成し、そのポリシーを紐付けたユーザーやトークンで操作するのがベストプラクティスです。

認証設定の有効化を実施します。

新しい ACL ポリシーの作成

参考：https://developer.hashicorp.com/vault/tutorials/get-started/learn-ui#enable-and-configure-an-auth-method

ACL Policies に移動

Create ACL policy で新しいポリシーを作成します。

追加されました。

新しいアクセスを作成

ナビゲーションパネル - "Access" - "Authentication Methods" に移動

Userpass を指定

CLI で admin01 にパスワードと admin ポリシーを設定します

# vault write auth/userpass/users/admin01 \
  password="xxxxxRxxxxx" \
  policies="admin"
Success! Data written to: auth/userpass/users/admin01

ログイン確認(GUI)

一度 GUI からログアウトして、再度ログインします。

Method で Userpass を選択し admin01 ユーザーでログインします。

無事にログインできました。

監査ログの有効化

監査ログ（Audit Log）は Vault への全リクエストとレスポンスを記録します。有効化すると、監査デバイスへの書き込みに失敗した場合 Vault 自体がリクエストを拒否する仕様になっています（セキュリティ優先の設計）。そのため、ログの書き込み先ディスクの空き容量には注意が必要です。

本記事の logrotate 設定により、30日分のログを自動で圧縮・ローテートします。

# mkdir -p /var/log/vault
# chown vault:vault /var/log/vault
# chmod 750 /var/log/vault
#

# export VAULT_ADDR=https://127.0.0.1:8200
# echo $VAULT_ADDR
https://127.0.0.1:8200

※ 自己署名証明書による検証エラーを回避するため、ここでは検証をスキップしています（本番環境では非推奨）

# export VAULT_SKIP_VERIFY=true

CLI でログインします。token を指定します。

# vault login

<tokenを入力>

Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.

Key                  Value
---                  -----
token                xxxx.xxxxxx
token_accessor       pxxxxxxY5KGbxxxxxx
token_duration       ∞
token_renewable      false
token_policies       ["root"]
identity_policies    []
policies             ["root"]

autdit の有効化

# vault audit enable file file_path=/var/log/vault/audit.log
Success! Enabled the file audit device at: file/
#

有効化された audit の確認

# vault audit list
Path     Type    Description
----     ----    -----------
file/    file    n:::note alert

ローテート設定 (RHEL)

ログが肥大化しないよう、logrotate の設定を行います。

# vi /etc/logrotate.d/vault-audit

# cat /etc/logrotate.d/vault-audit
/var/log/vault/audit.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
    create 0640 vault vault
}

dry run の実行

# logrotate -d /etc/logrotate.d/vault-audit
WARNING: logrotate in debug mode does nothing except printing debug messages!  Consider using verbose mode (-v) instead if this is not what you want.

reading config file /etc/logrotate.d/vault-audit
Reading state from file: /var/lib/logrotate/logrotate.status
Allocating hash table for state file, size 64 entries
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state

Handling 1 logs

rotating pattern: /var/log/vault/audit.log  after 1 days (30 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/vault/audit.log
Creating new state
  Now: 2026-03-26 08:01
  Last rotated at 2026-03-26 08:00
  log does not need rotating (log has already been rotated)```

強制実行して動作確認

# logrotate -f /etc/logrotate.d/vault-audit
# ls -l /var/log/vault
total 8
-rw-------. 1 vault vault    0 Mar 26 08:03 audit.log
-rw-------. 1 vault vault 4413 Mar 26 08:03 audit.log.1

Key Value(KV) シークレットエンジンの設定

「シークレットエンジン」は Vault でシークレット（機密情報）を管理する機能の単位です。
KV（Key-Value）エンジンはパスワードや API キーなどを key=value 形式で格納します。

左側のメニューから「Secrets Engines」を選択します。

画面右上の「Enable new engine」をクリックします。

リストの中から「KV」（または KV Version 2）を選択し、画面下部の「Next」をクリックします。

Path（デフォルトは kv）などを確認し、「Enable Engine」をクリックします。

Create secret

test secret が作成されました。

AppRole認証の設定

AppRole は人（ユーザー）ではなくマシンやアプリケーションが Vault に認証するための仕組みです。
Role ID（アプリの識別子）と Secret ID（ワンタイムパスワードに近い概念）の2つを組み合わせてトークンを取得します。
Ansible Automation Platform (AAP) のように自動化ツールから Vault のシークレットを取得する際によく使われます。

コマンドライン(CLI)で実行しています。

AAP 用ポリシーの作成

# cat > /tmp/aap-policy.hcl <<'EOF'
# KVv2 シークレットの読み取り
path "secret/data/aap/*" {
  capabilities = ["read", "list"]
}

# cat > /tmp/aap-policy.hcl <<'EOF'
# KVv2 シークレットの読み取り
path "secret/data/aap/*" {
  capabilities = ["read", "list"]
}

# KVv2 メタデータの読み取り（バージョン確認用）
path "secret/metadata/aap/*" {
  capabilities = ["read", "list"]
}

# AppRole の Secret ID 自己更新（AAP による自動ローテーション）
path "auth/approle/role/aap-role/secret-id" {
  capabilities = ["create", "update"]
}
EOF

# vault policy write aap-policy /tmp/aap-policy.hcl
Success! Uploaded policy: aap-policy

app-policy にポリシーをロード

# vault policy write aap-policy /tmp/aap-policy.hcl
Success! Uploaded policy: aap-policy

GUI の Policies 画面でも確認できます。

AppRole 認証メソッドの有効化

token_ttl: AAP ジョブの最長実行時間を考慮して設定（例: 1h）
secret_id_ttl: Secret ID の有効期限（定期ローテーション推奨, 今回は未設定)
token_policies: 上記で作成したポリシーを紐付け

# vault auth enable approle
Success! Enabled approle auth method at: approle/

# vault write auth/approle/role/aap-role \
  token_ttl=1h \
  token_max_ttl=4h \
  token_policies=aap-policy \
  secret_id_num_uses=0 \
  bind_secret_id=true
Success! Data written to: auth/approle/role/aap-role

作成確認

# vault read auth/approle/role/aap-role
Key                        Value
---                        -----
alias_metadata             map[]
bind_secret_id             true
local_secret_ids           false
secret_id_bound_cidrs      <nil>
secret_id_num_uses         0
secret_id_ttl              0s
token_bound_cidrs          []
token_explicit_max_ttl     0s
token_max_ttl              4h
token_no_default_policy    false
token_num_uses             0
token_period               0s
token_policies             [aap-policy]
token_ttl                  1h
token_type                 default
#

GUIで確認

Role ID と Secret ID の取得

# vault read auth/approle/role/aap-role/role-id
Key        Value
---        -----
role_id    54xf-06xxx56-89xx-0b20-eda4xxxx

Secret ID の生成（AAP の認証情報設定画面に入力）
※ Secret ID は一度しか表示されないため必ず保存が必要です

# vault write -f auth/approle/role/aap-role/secret-id
Key                   Value
---                   -----
secret_id             xx-6xxb-8ef6-xx-30b3axxxxxx
secret_id_accessor    xx-f190-xx-c1e1-b6xxxxd2620
secret_id_num_uses    0
secret_id_ttl         720h

動作確認 token 発行

# vault write auth/approle/login \
  role_id="54xf-06xxx56-89xx-0b20-eda4xxxx" \
  secret_id="xx-6xxb-8ef6-xx-30b3axxxxxx"
Key                     Value
---                     -----
token                   hvs.CxxxxxX85updndoxxxxxE6hzI5P1rbP0pxxxxpeVFZdGpJVm5yMlFxxxxNEdSbxxxxDk
token_accessor          24JKxxxxxznEhdDexxxx
token_duration          1h
token_renewable         true
token_policies          ["aap-policy" "default"]
identity_policies       []
policies                ["aap-policy" "default"]
token_meta_role_name    aap-role

Root Token Revoke

Root Token は Vault の全操作が可能なスーパーユーザートークンです。
初期設定完了後は必ず無効化し、日常運用では admin ポリシーや AppRole など権限を絞ったトークンを使うようにします。
将来的に Root Token が再度必要になった場合は、Unseal Key を一定数集めることで再生成できます（vault operator generate-root）。

Root Token を無効化します。

#  vault token revoke hvs.gxxxxry8aNRfxxxxx(RootToken)
Success! Revoked token (if it existed)

セキュリティのベストプラクティスについて

今回は初期構築の動作確認のため最小限の手順を実施しましたが、本稼働に向けては以下の対応を推奨します。

Root Tokenの無効化: 初期設定が終わり次第、速やかに Revoke する（※本記事の手順で実施済み）。
TLS証明書: VAULT_SKIP_VERIFY=true は検証環境のみに留め、本番では正規のTLS証明書を利用する。
Unseal Keyの管理: 初期化時に発行される Unseal Key は、複数の管理者に分散して安全なパスワードマネージャー等に保管する。

おわりに

HashiCorp Vault の初期設定から Ansible Automation Platform 連携のための AppRole 設定、および運用を考慮したセキュリティ設定（監査ログ、Root Token破棄）までを確認しました。

以上です。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up