Vault Mount Filters入門: マウント単位のレプリケーション制御

Vault EnterpriseのPerformance Replicationは読み取りのスケールアウトを可能にしますが、全てのマウントを複製したくないケースは少なくありません。Mount Filtersは、どのマウント（シークレットエンジン/認証メソッド）をセカンダリへ複製するかを、プライマリ側で制御するための仕組みです。

本稿では運用担当（Ops）目線で、Mount Filtersの設計ポイント、設定・検証手順、トラブルシューティングの勘所を整理します。Vaultの公式ドキュメントに準拠した安定的な概念に絞って説明します。

Mount Filtersの基本と前提知識

Mount FiltersはVault EnterpriseのPerformance Replicationで、プライマリからセカンダリへ複製するマウントを制限する機能です。運用上は、機密度の高いマウントを除外したり、特定のマウントのみを許可するAllowlistモードで安全に範囲を絞り込む用途が中心です。

重要な前提: Mount FiltersはPerformance Replication向けの制御であり、DR Replicationでは基本的に全データの整合コピーが前提となるため、マウント単位のフィルタリングは適用しません。Mount Filtersはプライマリで設定し、レプリケーショントポロジに従って評価されます。

• 対象: シークレットエンジンと認証メソッド（Vaultではどちらも「マウント」）
• モード: Allowlist（明示許可）またはDenylist（明示除外）
• 評価単位: パスの前方一致（プレフィックス）で指定するのが基本
• 適用層: Performance Replication。DRには使わない
• Namespace対応: Enterprise Namespaces環境ではNamespaceごとに検討（実装や構成に依存）

評価タイミングとデフォルト動作

デフォルト（Mount Filters未設定）では、Performance Replicationは一般的なマウントをセカンダリへ複製します。ただし、Vaultの内部・システムパスや、明示的にローカル指定されたマウント（後述のLocal Mount）は対象外です。

Mount Filtersを設定すると、プライマリは指定ルールに基づきマウントを含める/除外します。Allowlistは「指定したもののみ複製」、Denylistは「指定したものを除外し、それ以外を複製」という挙動を意図します。複雑な競合ルールは避け、どちらか一貫した方針で設計するのが安全です。

• フィルタはプライマリ側で評価される（セカンダリでの個別上書きは基本想定しない）
• パス指定は過不足がないよう、段階（例: kv/prod/ など）で切る
• フィルタ変更はレプリケーションの再評価を招くため、メンテナンス時間帯に計画的に行う

Mount Filtersの概念図（Performance Replication）

他機能との比較: Local Mount・Namespaces・DR

Mount Filtersだけでなく、Local MountやNamespaces、DR Replicationの特性と組み合わせて全体設計を行います。以下の比較で、試験や実務で混同しやすいポイントを整理します。

• Local Mountは「レプリケーションから除外」ではなく「クラスターにローカル」な性質付与であり、用途が異なる
• DRはフェイルオーバー前提の完全コピーが目的。部分的な除外は基本しない
• Namespacesは権限境界と運用分離のための論理区画。Mount Filtersは複製範囲の技術的制御

設定手順と検証: 安全な導入のプロセス

以下は典型的な手順例です。実際のAPIパス名や細かなパラメータはエディション/バージョンで差異があり得るため、作業前に公式ドキュメントを確認してください。特に本番では、同一構成の検証環境で事前リハーサルを行うことを強く推奨します。

ポイントは、1) 現行マウントと依存関係の棚卸し、2) フィルタ設計（Allowlist推奨）、3) 段階的適用、4) ロールバック手順の事前用意、の4点です。

• 前提確認: 現行がPerformance Primaryであること、セカンダリとのレプリケーションが健全であること
• 影響調査: 除外予定マウントを利用するクライアント/ロール/ポリシーの洗い出し
• 適用: Allowlistで最小集合から開始し、段階的に拡張
• 検証: 読み取りの局所性、レイテンシ、セカンダリでの対象マウントの可視性を確認
• ロールバック: フィルタ削除/緩和の計画と承認ルートを用意

CLI例（概念イメージ。実環境では公式パス/パラメータを要確認）

# 1) 現行のレプリケーション状態を確認（役割/健全性）
$ vault read -format=json sys/replication/status | jq .

# 2) 現行のマウント（シークレットエンジン）と認証メソッドを棚卸し
$ vault read -format=json sys/mounts | jq '.data | keys'
$ vault read -format=json sys/auth   | jq '.data | keys'

# 3) Mount Filters（Allowlist）の設定例
#   例: kv/prod/ と transit/ のみ複製する
#   注: 実際のエンドポイント名やフィールドはバージョンで異なる可能性あり
$ vault write sys/replication/performance/primary/mount-filter \
    mode=allowlist \
    paths=kv/prod/*,transit/*

# 4) 設定の確認（フィルタ内容）
$ vault read sys/replication/performance/primary/mount-filter

# 5) セカンダリでの結果確認（対象マウントが見える/読めること）
#    読み取りはセカンダリでローカルに終了するが、書き込みはプライマリにフォワードされる点を理解して検証
$ vault login <secondary_token>
$ vault kv get kv/prod/sample
$ vault kv get kv/pii/sample   # 期待: フィルタで除外されていれば不可視/非該当

# 6) ロールバック（フィルタの削除/緩和）
$ vault delete sys/replication/performance/primary/mount-filter

# 7) 変更後のレプリケーション健全性と遅延を再確認
$ vault read -format=json sys/replication/status | jq .

運用・監視・トラブルシューティングの勘所

フィルタ変更はレプリケーションの再評価を引き起こすため、変更ウィンドウとロールバックを確保します。セカンダリから見えるマウントが減ると、クライアントの認可フローや依存ジョブが失敗する可能性があるため、事前の影響分析が必須です。

監視では、レプリケーションの遅延、失敗カウンタ、セカンダリでのエラーログ（権限/パス未存在）を併せて確認します。監査ログでは、除外マウントへのアクセス試行がどのように記録されるかを事前に把握し、運用手順に組み込みましょう。

• 計画停止を確保し、変更は段階的に適用（Canaryセカンダリ→全体）
• 影響を受けるロール/ポリシー/アプリの事前告知とバリデーション
• メトリクス/ログ: レプリケーション遅延、転送失敗、セカンダリの404/permission denied
• バックアウト: フィルタ削除→健全性確認→依存系の再実行

資格試験（Ops）向け要点整理

試験では、Mount Filtersの適用対象、DRとの違い、Local Mount/Namespacesとの役割差分を正しく切り分けられるかが頻出ポイントです。

• Mount FiltersはPerformance Replication用。DRではフィルタでの部分除外は基本しない
• Allowlistは「挙げたものだけ」複製。設計時は最小権限の原則でAllowlistが無難
• Local Mountは性質付け（ローカル化）であり、Mount Filtersの置き換えではない
• Namespaceは権限/運用の境界。フィルタは複製範囲の技術制御で別軸
• 設定はプライマリで行い、セカンダリの個別上書きは想定しないのが基本

問題で確認

よくある質問