HCP Vault 無料枠でつくる学習用環境: Associate / Ops 向け実践

Vault Associate / Operations の試験範囲は、ポリシー、認証方式、シークレットエンジン、トークン/リース、監査などの基礎を広く問います。ローカル開発モードだけでなく、HCP Vault（マネージド）を使ってクラウド環境で手を動かすと、ネットワーク公開や最小権限設計まで含めて理解が深まります。

ここでは、HCP Vault の無料トライアル/無料枠を前提に、できるだけ安全に始める方法、CLI での初期設定、最小構成の演習（KV と AppRole）までを、試験で狙われやすいポイントと紐づけて解説します。機能や料金・プラン名称は時期により変わることがあるため、最終的には HCP コンソールおよび公式ドキュメントで確認してください。

無料枠の前提と安全な使い方

HCP Vault は HashiCorp Cloud Platform 上のマネージド Vault クラスタです。無料トライアルや開発（非本番）向けのプランでは、単一ノード・機能制限・期間/クレジット制限などが設けられる場合があります。最新の提供条件は HCP コンソールと公式ドキュメント（developer.hashicorp.com/vault）で必ず確認してください。

学習目的でも、公開設定とトークン運用には注意が必要です。最小権限のポリシーを作り、パブリックエンドポイントを使う場合は IP 許可リストで自分の端末のグローバル IP のみに絞るのが安全です。初期の強権トークンはブートストラップと検証後に速やかに無効化・保管ルール徹底が基本です。

• 公開は最小限: パブリックエンドポイントを使う場合は IP 許可リストで自分のグローバル IP のみに限定
• 最小権限: root/管理トークンはブートストラップ後に使い回さない
• コスト管理: 使い終わったらクラスタ削除。無料枠の時間/クレジットを超えないよう注意
• 試験意識: ポリシー（path ルール）、Auth Method（userpass/AppRole/OIDC）、KV v2、トークンTTL/リース、監査を触れる構成にする

HCP Vault クラスタの作成手順（無料枠向け）

HCP コンソールでプロジェクトを作成し、Vault クラスタを新規作成します。学習ではリージョンは近い場所を選び、公開を急ぐ場合はパブリックエンドポイントを有効化したうえで、IP 許可リストを自分のグローバル IP のみに限定します。HVN（HashiCorp Virtual Network）は自動作成でも手動でも構いません。

Terraform で再現性を持たせる場合は HCP プロバイダを使います。provider と resource の属性はバージョンにより変わる可能性があるため、実行前に developer.hashicorp.com の最新リファレンスを参照してください。

• HCP にログイン → Project 作成 → Vault → Create cluster
• Plan/ティアは学習・非本番向けのものを選択（無料枠/開発プランを想定）
• Public endpoint を有効化 → Allowed CIDR に自端末のグローバルIP/32を登録
• クラスタ作成後に、初期トークン（表示は一度限りの場合あり）を安全に控える

参考: Terraform（HCP プロバイダ）で開発用クラスタを作る最小例

terraform {
  required_providers {
    hcp = {
      source  = "hashicorp/hcp"
      version = ">= 0.88.0"
    }
  }
}

provider "hcp" {}

# 学習用の HVN（必要に応じて）
resource "hcp_hvn" "lab" {
  hvn_id         = "hvn-lab"
  cloud_provider = "aws"
  region         = "us-west-2"
  cidr_block     = "172.25.16.0/20"
}

# 開発/無料枠相当のクラスタ（属性名はプロバイダ版数で変わる可能性あり）
resource "hcp_vault_cluster" "lab" {
  cluster_id       = "vault-lab-01"
  hvn_id           = hcp_hvn.lab.hvn_id
  tier             = "dev"        # 学習用ティア例。実際はコンソールの名称に合わせる
  public_endpoint  = true          # 学習の簡便さ重視
  # IP 許可リストはコンソールまたは専用リソースで設定（プロバイダの最新docs参照）
}

output "vault_public_address" {
  value = hcp_vault_cluster.lab.public_endpoint_url
}

CLIでの接続と初期セットアップ

ローカル端末に Vault CLI を導入し、環境変数 VAULT_ADDR と VAULT_TOKEN を設定します。HCP の初期トークンは強権です。ポリシー/ロールのブートストラップにのみ使い、学習用の限定トークンに早めに置き換えます。

接続構成は下記のようになります。学習ではパブリックエンドポイント+IP 許可でシンプルに開始し、慣れてきたら HVN/Private Link へ移行すると運用寄りの観点が身につきます。

• VAULT_ADDR は HCP コンソールに表示される https://...:8200 を使用
• IP 許可リストに自分のグローバルIP/32のみを登録（出先を変えるなら都度更新）
• 初期トークンは保管せず、限定ポリシーのトークンへ切替

学習用の最小接続イメージ

CLI 初回接続と最小ブートストラップ

# macOS 例: CLI インストール
brew tap hashicorp/tap && brew install hashicorp/tap/vault

# HCP 表示のアドレスと初期トークンを設定（初期トークンは一時利用）
export VAULT_ADDR="https://<your-cluster>.<region>.aws.hashicorp.cloud:8200"
export VAULT_TOKEN="hvs.<initial-root-or-admin-token>"

# 接続確認
vault status

# 学習用の読み取り専用ポリシー例（kv v2 の read に限定）
cat > app-read.hcl <<'EOF'
path "secret/data/app/*" {
  capabilities = ["read"]
}
EOF

vault policy write app-read app-read.hcl

# 最小権限のトークンを発行（例: 1h 生存、再新可）
vault token create -policy=app-read -ttl=1h -renewable=true

学習で必須のVault機能セット（Associate / Ops 直結）

試験と実務の両方で頻出なのは、KV v2、Auth Method（userpass/AppRole/OIDC）、ポリシー、トークン/リース、監査です。まずは KV v2 を有効化し、ポリシーでアクセスを絞り、AppRole でアプリ向け認証を作る流れを押さえましょう。

監査デバイスは本番で重要ですが、学習環境でもファイル監査の基本を体験しておくと設計問題に強くなります（HCP では監査先の取り扱いに制約がある場合があるため、ローカル dev でも一度試すと理解が進みます）。

• KV v2: バージョン管理つきのキー/バリュー。APIパスは data/ と metadata/
• ポリシー: path ごとの capabilities（read, create, update, delete, list, sudo）
• Auth: userpass は人、AppRole はアプリに向く（ID/SecretID）
• トークン/リース: TTL、Renew、Revoke、Orphan の区別
• 監査: request/response のメタデータを記録。PII 取り扱い方針を理解

KV v2 と AppRole を有効化して基本を確認

# KV v2（secret/）を有効化
vault secrets enable -path=secret -version=2 kv

# シークレット投入と参照（v2 は data/ を使う）
vault kv put secret/app/config db_user=demo db_pass=s3cr3t
vault kv get secret/app/config

# AppRole を有効化し、ポリシーを付与
vault auth enable approle

cat > app.hcl <<'EOF'
path "secret/data/app/*" {
  capabilities = ["read", "list"]
}
EOF

vault policy write app app.hcl

vault write auth/approle/role/myapp \
  token_policies="app" \
  token_ttl="30m" \
  token_max_ttl="4h" \
  secret_id_ttl="30m" \
  secret_id_num_uses=1

演習: AppRoleでアプリがシークレットを取得する

この演習では、AppRole の RoleID/SecretID を使ってクライアントトークンを得て、KV v2 からシークレットを読む一連の流れを確認します。試験では、どのトークン/リースがどこで発行され、何を Renew/Revoke できるかを図解できると強いです。

SecretID の使い捨て（num_uses=1）や短い TTL は、学習でも実務でも基本戦術です。漏えい面積を小さく保ち、ローテーションを前提に設計してください。

• RoleID は識別子、SecretID は提示用クレデンシャル（配布は安全チャネルで）
• AppRole ログインで得たクライアントトークンに、ポリシーの権限が付与される
• TTL を超える前に vault token renew、不要になったら revoke

AppRole でログインして KV を読む一連のコマンド

# RoleID と SecretID を取得
ROLE_ID=$(vault read -field=role_id auth/approle/role/myapp/role-id)
SECRET_ID=$(vault write -field=secret_id auth/approle/role/myapp/secret-id)

echo "ROLE_ID=$ROLE_ID"
echo "SECRET_ID=$SECRET_ID"

# AppRole ログインでクライアントトークン取得
APP_TOKEN=$(vault write -field=token auth/approle/login role_id="$ROLE_ID" secret_id="$SECRET_ID")

echo "APP_TOKEN=$APP_TOKEN"

# アプリ視点で KV 読み取り（ポリシーの許可範囲のみ）
VAULT_TOKEN="$APP_TOKEN" vault kv get secret/app/config

# TTL 確認と更新
VAULT_TOKEN="$APP_TOKEN" vault token lookup
VAULT_TOKEN="$APP_TOKEN" vault token renew

# 使い終わったら明示的に取り消し
VAULT_TOKEN="$APP_TOKEN" vault token revoke -self

無料枠で起きやすいハマりどころと対処

接続不可の多くは IP 許可リストの未更新、または会社/自宅でグローバルIPが変わったケースです。まずは HCP コンソールの Allowed CIDR を再確認します。証明書エラーは VAULT_ADDR のタイポやプロキシ干渉が原因になりがちです。

トークン関連では、TTL 超過やポリシー不足で操作が失敗します。vault token lookup で現在の TTL とポリシーを確認し、必要なら renew、設計上の不要トークンは revoke します。学習終了後はクラスタの停止/削除でコスト事故を防ぎましょう。

• HTTP 403/timeout: IP 許可リスト、セキュリティグループ、リージョンの取り違えを確認
• permission denied: path と capabilities をポリシーで見直し（data/ と metadata/ の取り違えに注意）
• clock skew: お使いの端末の時刻同期（NTP）を確認。TTL 検証に影響
• 初期トークン再発行: HCP 側のワークフロー（再生成/サポート要否）は時期により異なるため、コンソールと公式ドキュメントを参照

よく使う確認コマンド

# ステータス/診断
vault status

# トークンとポリシーの確認
vault token lookup

# ポリシーの中身を確認
vault policy read app

# KV v2 のメタデータを確認
vault list secret/metadata/app/

# 監査（ローカル dev で練習）
# vault audit enable file file_path=/tmp/vault_audit.log

問題で確認

よくある質問