Ansible Vaultの「パスワードファイル管理」という呪縛を解く：KMS連携によるモダンなセキュア運用術
こんにちは。インフラエンジニアの皆さん、日々のIaC運用で「Ansible Vaultのパスワード」をどう扱うか、悩んだことはありませんか？
「`.vault_pass` というファイルをリポジトリに入れないように……」と注意しつつ、結局ローカルのどこかに平文で置いてしまい、ヒヤリハットを経験する。あるいは、CI/CD環境の環境変数にベタ書きして、ログに出ないか冷や冷やする。
そんな「前時代的な秘密鍵管理」とは、今日で決別しましょう。
今回は、Ansible Vaultの暗号化ファイルを、AWS KMSやHashiCorp Vaultといった「外部の信頼できる鍵管理サービス」を使って、実行時にオンザフライで復号する究極の手法を伝授します。これをマスターすれば、あなたのインフラ運用は一段上の「堅牢性」を手に入れるはずです。
—
1. なぜ「パスワードファイル」の管理は地獄なのか？
Ansible Vaultは非常に強力ですが、その「鍵」であるパスワードファイルをどう安全に運ぶかが常に課題となります。
- ハードコードの誘惑: CI/CDツール（GitHub Actions, GitLab CI等）の環境変数に流し込むのは簡単ですが、ログ出力設定を誤ると、シークレットがコンソールに露出するリスクがあります。
- 配布の難しさ: 開発者が増えるたびに「パスワードファイルの受け渡し」が発生し、そこがセキュリティの穴になります。
私たちが目指すべきは、「人間がパスワードを一切知らない状態」での自動化です。クラウドの権限（IAM RoleやService Account）こそが鍵となる設計、これこそが現代のベストプラクティスです。
—
2. 実践：AWS KMSを活用したオンザフライ復号
今回は、AWS環境を例に、KMSを使ってVaultパスワードを動的に取得する構成を作ります。
手順①：KMSで鍵を生成する
まず、AWSコンソールまたはCLIでKMSキーを作成します。このキーのポリシーには、「CI/CDを実行するIAM Role」のみが復号権限を持つように制限をかけます。
手順②：パスワードを暗号化して保存
Ansible Vaultのパスワードを直接ファイルに書くのではなく、一度暗号化してリポジトリにコミットします。
パスワードをKMSで暗号化してファイル化（これがリポジトリに入る）
echo “my-secret-vault-password” > .vault_pass.plain
aws kms encrypt –key-id alias/ansible-key –plaintext fileb://.vault_pass.plain –output text –query CiphertextBlob > .vault_pass.enc
rm .vault_pass.plain
手順③：Ansible実行時の復号スクリプト（vault_pass.py）
Ansibleは `vault_password_file` 設定でスクリプトを指定可能です。このスクリプトが実行時に動的にKMSから平文を取得します。
!/usr/bin/env python3
import boto3
import base64
import sys
KMSから暗号化されたパスワードを復号するスクリプト
def get_vault_password():
client = boto3.client(‘kms’, region_name=’ap-northeast-1′)
with open(‘.vault_pass.enc’, ‘rb’) as f:
encrypted_blob = base64.b64decode(f.read())
response = client.decrypt(CiphertextBlob=encrypted_blob)
print(response[‘Plaintext’].decode(‘utf-8’))
if __name__ == ‘__main__’:
get_vault_password()
手順④：ansible.cfgで連携
`ansible.cfg` に以下を追記するだけで、Ansibleは実行時にこのスクリプトを呼び出し、メモリ上のみでパスワードを解決します。
[defaults]
パスワード取得スクリプトを指定
vault_password_file = ./vault_pass.py
—
3. 安全なCI/CD運用のためのベストプラクティス
この設計を導入すると、開発者のローカルPCやCIサーバーに「パスワードの実体」は存在しなくなります。
1. IAMの最小権限: CIサーバー（GitHub ActionsのOIDCプロバイダ等）に付与するIAM Roleには、`kms:Decrypt` アクションのみを許可してください。
2. 実行ログの秘匿: 万が一のために、CIのログ出力において「シークレットのマスキング」を徹底しましょう（GitHub Actionsなら `add-mask` コマンドを活用）。
3. キーのローテーション: KMSキーは定期的にローテーションさせます。Ansible側のスクリプトはキーIDを参照しているため、自動的に追従可能です。
—
最後に：エンジニアとしての誇り
「ツールをただ使う」段階から「ツールの背後にある信頼モデルを設計する」段階へ進む。それが、一流のSREへの第一歩です。
今回紹介したKMS連携は、AWSに限らず、HashiCorp Vaultの `vault kv get` コマンドなどに置き換えるだけで、どのような環境でも応用可能です。
「パスワードファイルをどう管理するか？」という問いに対して、「管理しない（動的に生成・取得する）」と答えられるようになった時、あなたのインフラは本当の意味で自動化されます。
さあ、あなたのIaCを、より美しく、より堅牢なものへ進化させましょう。何か詰まったら、いつでも聞いてくださいね。応援しています！