レッスン 11: 基本的な認証方法 - トークン、ユーザーパス、および AppRole

Token Types

トークンの作成

# Tạo token với default policy
vault token create

# Tạo token với policies cụ thể
vault token create \
  -policy="app-readonly" \
  -policy="db-creds" \
  -ttl=1h \
  -display-name="app-service"

# Tạo orphan token (không có parent)
vault token create -orphan \
  -policy="monitoring" \
  -ttl=24h

# Tạo batch token
vault token create \
  -type=batch \
  -policy="app-readonly" \
  -ttl=30m

# Tạo periodic token (không bao giờ expire nếu renew đúng hạn)
vault token create \
  -policy="long-running-service" \
  -period=24h

Root Tokens

Root トークンは Vault 全体にアクセスできます。緊急時のみ使用してください:

# Tạo root token mới (cần quorum unseal keys)
vault operator generate-root -init
vault operator generate-root \
  -nonce="..." \
  -otp="..."

# Revoke root token sau khi dùng xong
vault token revoke <root-token>

ベスト プラクティス: ルート トークンを保存しないでください。必要なときに作成し、使用後すぐに取り消します。

Token Roles

# Tạo token role cho CI/CD
vault write auth/token/roles/ci-cd \
  allowed_policies="ci-deploy,ci-readonly" \
  disallowed_policies="admin,root" \
  orphan=true \
  renewable=true \
  token_period=1h \
  token_type=service \
  token_bound_cidrs="10.0.0.0/8"

# Tạo token từ role
vault token create -role=ci-cd

Token Accessors

トークン アクセサーにより、トークン値を知らなくてもトークン管理が可能になります:

# Lookup token bằng accessor
vault token lookup -accessor <accessor>

# Revoke token bằng accessor
vault token revoke -accessor <accessor>

# Liệt kê tất cả token accessors
vault list auth/token/accessors

3. Userpass Auth Method

Userpass は人間のユーザーにとって最も単純な認証方法であり、ユーザー名とパスワードで認証します。小規模な環境やテストに適しています。

有効化および構成

# Enable userpass
vault auth enable userpass

# Tạo user với policies
vault write auth/userpass/users/john.doe \
  password="s3cur3P@ssw0rd" \
  policies="dev-readonly,dev-kv" \
  token_ttl=8h \
  token_max_ttl=24h

# Tạo user với CIDR binding
vault write auth/userpass/users/admin.user \
  password="adm1nP@ss" \
  policies="admin" \
  token_ttl=2h \
  token_bound_cidrs="10.10.0.0/16,192.168.1.0/24"

# Liệt kê users
vault list auth/userpass/users

# Đọc thông tin user
vault read auth/userpass/users/john.doe

Login

# Login qua CLI
vault login -method=userpass \
  username=john.doe \
  password="s3cur3P@ssw0rd"

# Login qua API
curl -s --request POST \
  --data '{"password": "s3cur3P@ssw0rd"}' \
  ${VAULT_ADDR}/v1/auth/userpass/login/john.doe | jq .

Password Policies

Vault 1.5 以降は、パスワードの複雑さを強制するパスワード ポリシーをサポートしています:

# Tạo password policy
vault write sys/policies/password/strong-password policy=-<<EOF
length=20
rule "charset" {
  charset = "abcdefghijklmnopqrstuvwxyz"
  min-chars = 2
}
rule "charset" {
  charset = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
  min-chars = 2
}
rule "charset" {
  charset = "0123456789"
  min-chars = 2
}
rule "charset" {
  charset = "!@#$%^&*()-_=+[]{}|;:,.<>?"
  min-chars = 2
}
EOF

# Sinh password theo policy
vault read sys/policies/password/strong-password/generate

# Áp dụng password policy cho userpass
vault write auth/userpass/users/secure.user \
  password="$(vault read -field=password sys/policies/password/strong-password/generate)" \
  policies="dev-readonly"

ユーザーの更新と削除

# Cập nhật password
vault write auth/userpass/users/john.doe \
  password="n3wP@ssw0rd!"

# Cập nhật policies (không thay đổi password)
vault write auth/userpass/users/john.doe/policies \
  policies="dev-readonly,dev-kv,staging-deploy"

# Xóa user
vault delete auth/userpass/users/john.doe

4. AppRole Auth Method

AppRole は、マシン間認証 用に設計された認証方法です。これは、アプリケーションと CI/CD パイプラインが Vault で認証するための最も一般的な方法です。

中心的な概念

┌─────────────────────────────────────────────────────────┐
│                     AppRole Login                       │
│                                                         │
│   RoleID (public identifier)                            │
│   + SecretID (private credential)                       │
│   = Vault Token (with assigned policies)                │
│                                                         │
│   Tương tự: username + password = session token         │
└─────────────────────────────────────────────────────────┘

ロールを有効にして作成

# Enable AppRole
vault auth enable approle

# Tạo role cho web application
vault write auth/approle/role/webapp \
  token_policies="webapp-policy,db-readonly" \
  token_ttl=1h \
  token_max_ttl=4h \
  secret_id_ttl=30m \
  secret_id_num_uses=1 \
  token_num_uses=0 \
  bind_secret_id=true

# Tạo role cho CI/CD pipeline
vault write auth/approle/role/cicd-pipeline \
  token_policies="cicd-deploy" \
  token_ttl=30m \
  token_max_ttl=1h \
  secret_id_ttl=10m \
  secret_id_num_uses=1 \
  token_num_uses=10 \
  bind_secret_id=true \
  secret_id_bound_cidrs="10.0.0.0/8" \
  token_bound_cidrs="10.0.0.0/8"

重要なパラメータ

ログインプロセス

# Bước 1: Lấy RoleID (thường được bake vào config/image)
vault read auth/approle/role/webapp/role-id
# role_id    db02de05-fa39-4855-059b-67f86261c393

# Bước 2: Sinh SecretID (thường do trusted orchestrator sinh)
vault write -f auth/approle/role/webapp/secret-id
# secret_id           6a174c20-f6de-a53c-74d2-6018fcceff64
# secret_id_accessor  c454f7e5-996e-7230-6074-6ef26b7bcf86

# Bước 3: Login
vault write auth/approle/login \
  role_id="db02de05-fa39-4855-059b-67f86261c393" \
  secret_id="6a174c20-f6de-a53c-74d2-6018fcceff64"

Response Wrapping cho SecretID

Response ラッピングは重要なセキュリティ メカニズムです。SecretID は短期ラッピング トークンに「ラップ」されます。ターゲット アプリケーションのみがラップを解除できます:

# Sinh SecretID với response wrapping (TTL 120 giây)
vault write -wrap-ttl=120s -f auth/approle/role/webapp/secret-id

# Response chứa wrapping_token thay vì secret_id trực tiếp
# wrapping_token:           hvs.CAES...
# wrapping_accessor:        ...
# wrapping_token_ttl:       2m
# wrapping_token_creation_time: ...

# Application unwrap để lấy SecretID thật
vault unwrap hvs.CAES...
# secret_id    6a174c20-f6de-a53c-74d2-6018fcceff64

# Nếu ai đó đã unwrap trước → lỗi (phát hiện MITM)
vault unwrap hvs.CAES...
# Error: wrapping token is not valid or does not exist

攻撃検出

ラッピング トークンがアプリケーションの前に攻撃者によってラップ解除された場合:

• ラップ解除時にアプリケーションがエラーを受け取る → すぐにアラート

• 監査ログをチェックして、攻撃者のソース IP を見つけます

• ロールを取り消し、認証情報を再発行

5. AppRole Best Practices cho CI/CD

GitHub Actions

# .github/workflows/deploy.yml
name: Deploy with Vault
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Import Secrets from Vault
        uses: hashicorp/vault-action@v3
        with:
          url: https://vault.company.com
          method: approle
          roleId: ${{ secrets.VAULT_ROLE_ID }}
          secretId: ${{ secrets.VAULT_SECRET_ID }}
          secrets: |
            secret/data/production/db username | DB_USERNAME ;
            secret/data/production/db password | DB_PASSWORD ;
            secret/data/production/api key | API_KEY

      - name: Deploy application
        run: |
          echo "Deploying with secrets..."
          ./deploy.sh
        env:
          DB_USERNAME: ${{ env.DB_USERNAME }}
          DB_PASSWORD: ${{ env.DB_PASSWORD }}

GitLab CI

# .gitlab-ci.yml
stages:
  - deploy

deploy-production:
  stage: deploy
  image: hashicorp/vault:1.21
  variables:
    VAULT_ADDR: "https://vault.company.com"
  script:
    - |
      # Login với AppRole
      VAULT_TOKEN=$(vault write -field=token auth/approle/login \
        role_id="${VAULT_ROLE_ID}" \
        secret_id="${VAULT_SECRET_ID}")
      export VAULT_TOKEN

      # Lấy secrets
      DB_PASSWORD=$(vault kv get -field=password secret/production/db)
      export DB_PASSWORD

      # Deploy
      ./deploy.sh
  only:
    - main

Jenkins Pipeline

// Jenkinsfile
pipeline {
    agent any

    environment {
        VAULT_ADDR = 'https://vault.company.com'
    }

    stages {
        stage('Get Secrets') {
            steps {
                withVault(
                    configuration: [
                        vaultUrl: "${VAULT_ADDR}",
                        vaultCredentialId: 'vault-approle'
                    ],
                    vaultSecrets: [
                        [
                            path: 'secret/production/db',
                            secretValues: [
                                [envVar: 'DB_USER', vaultKey: 'username'],
                                [envVar: 'DB_PASS', vaultKey: 'password']
                            ]
                        ]
                    ]
                ) {
                    sh './deploy.sh'
                }
            }
        }
    }
}

6. AppRole Deployment Pattern

Trusted Orchestrator Pattern

┌──────────────┐                    ┌──────────────┐
│  Terraform/  │  1. Sinh SecretID  │    Vault     │
│  Ansible     │ ──────────────────▶│              │
│ (Orchestrator)│◀──────────────────│              │
│              │  2. Wrapped token  │              │
└──────┬───────┘                    └──────────────┘
       │
       │ 3. Deliver wrapped token
       ▼
┌──────────────┐                    ┌──────────────┐
│  Application │  4. Unwrap →       │    Vault     │
│              │     SecretID       │              │
│              │  5. Login          │              │
│              │     (RoleID +      │              │
│              │      SecretID)     │              │
│              │  6. Vault Token    │              │
└──────────────┘                    └──────────────┘

1. RoleID は AMI/Docker イメージまたは構成管理

に組み込まれます

2. SecretID 信頼できるオーケストレーター (Terraform、Ansible、CI/CD) によって生成されました

3. SecretID は、セキュリティ

のために ラップされたトークン として配信されます。

4. アプリケーションをアンラップして SecretID を取得し、RoleID + SecretID でログイン

Pull vs Push model

7。セキュリティ認証方法

よくある間違い

• ❌ アプリケーションでルート トークンを使用する

• ❌ SecretID の TTL が長すぎるか、使用回数が無制限

• ❌ AppRole

に CIDR バインディングを設定しないでください

• ❌ Hardcode RoleID + SecretID trong source code

• ❌ マシン認証にユーザーパスを使用

ベストプラクティスをまとめました

• ✅ SecretID: num_uses=1, ttl=5m-30m

• ✅ SecretID

には常に応答ラッピングを使用します

• ✅ secret_id_bound_cidrs および token_bound_cidrs

を設定します

• ✅ 各アプリケーション/サービスには独自の役割があります

• ✅

を使用した後にルート トークンを取り消す

• ✅ 監査ログを有効にしてすべての認証を追跡

8。概要

この記事では、Vault の 3 つの最も基本的な認証方法を学習しました:

• Token Auth — プラットフォーム認証メソッド、すべての認証メソッドはトークン

を生成します

• Userpass Auth — 人間のユーザーにとってシンプル、パスワード ポリシーをサポート

• AppRole Auth — マシン認証の標準、CI/CD ワークフローをサポート

応答ラッピングを使用した

AppRole は、CI/CD パイプラインで最も推奨されるパターンです。次の記事では、人間とマシンの両方の ID に対するエンタープライズ認証方法である LDAP、OIDC、および JWT 認証方法について学びます。