Ansible Vaultの「その先」へ：機密管理を極め、CI/CDの生産性を最大化するプロの作法
「Ansible Vaultでパスワードを暗号化しました。これで安心ですね」……現場でそんな言葉を聞いたら、私はすぐにその設計を見直すよう促すだろう。
機密情報の管理は、単なる「暗号化の作業」ではない。「いかに開発者の認知負荷を下げ、かつ運用ミスを物理的に排除するか」というエンジニアリングそのものだ。
今日は、Ansible Vaultを単なるツールとしてではなく、堅牢なIaCパイプラインの心臓部として使いこなすための「深淵」を共有する。
—
1. なぜ「個人のVaultパスワード」では破綻するのか？
チーム開発において、各エンジニアが異なるVaultパスワードを個別に管理するのは地獄の入り口だ。パスワードの共有ミスは頻発し、結局Gitにパスワードがコミットされる。
神の解法：`ansible-vault`のファイル指定によるパスワード管理
`ansible.cfg`でVaultパスワードファイルを指定し、環境ごとに異なるパスワードファイルを管理せよ。
ansible.cfg
[defaults]
実行環境ごとに読み込むVaultパスワードファイルを指定
vault_password_file = .vault_pass
この `.vault_pass` は絶対にGit管理外（`.gitignore`）に置くこと。そして、チーム内ではパスワードマネージャー（1PasswordのCLI版やBitwardenなど）から動的に取得する運用を徹底する。
—
2. 開発スピードを劇的に上げる「秘伝のショートカット」
AnsibleのYAML編集で、いちいち暗号化・復号化をCLIで行うのは三流の所作だ。VS Codeを使っているなら、以下のプラグインと設定を導入せよ。
- 必須プラグイン: `Red Hat Ansible` (Red Hat公式)
- 神設定: `ansible-vault`をVS Codeのタスクに統合する
`.vscode/tasks.json` を活用すれば、`Ctrl+Shift+B`（またはキーバインド設定）で、開いているファイルを即座に暗号化・復号化できる。
{
“version”: “2.0.0”,
“tasks”: [
{
“label”: “Vault Encrypt Current File”,
“type”: “shell”,
“command”: “ansible-vault encrypt ${file}”,
“group”: “none”
}
]
}
—
3. 実践的ベストプラクティス：構造化された機密管理
機密情報を `group_vars/all.yml` にべた書きするのは悪手だ。役割ごとにファイルを分割し、インクルードせよ。
ディレクトリ構成例
inventory/
├── group_vars/
│ ├── all/
│ │ ├── vars.yml # 公開しても良い設定
│ │ └── vault.yml # 暗号化された機密情報（Ansible Vault）
この時、`vault.yml` の中身は「平文の変数名」と「暗号化された値」のペアで管理する。
group_vars/all/vault.yml (暗号化後の状態)
db_password: $ANSIBLE_VAULT;1.1;AES256;… (中略) …
api_key: $ANSIBLE_VAULT;1.1;AES256;… (中略) …
極意: `ansible-vault view` で確認する手間を省くため、暗号化ファイルには必ず「何のためのキーか」のコメントを暗号化前に付けておくこと。
—
4. CI/CDパイプラインとの完全統合
GitHub ActionsやGitLab CIでAnsibleを実行する場合、Vaultパスワードをどう渡すか？ 決してCIのログに出力してはならない。
正解: 環境変数 `ANSIBLE_VAULT_PASSWORD` を使用する
1. CIのシークレット管理ツール（GitHub Secrets等）にパスワードを保存。
2. 実行時に環境変数として注入。
GitHub Actionsの例
- name: Run Playbook
env:
ANSIBLE_VAULT_PASSWORD: ${{ secrets.VAULT_PASSWORD }}
run: |
echo “$ANSIBLE_VAULT_PASSWORD” > .vault_pass
ansible-playbook site.yml –vault-password-file .vault_pass
—
最後に：エンジニアが守るべき「聖域」
Ansible Vaultは強力だが、あくまで「静的な機密」を守るためのものだ。もしあなたがAWSやGCPで運用しているなら、Ansible Vaultを使わずに、実行時にSSM Parameter StoreやSecret Managerから直接値を引き抜く実装へ移行することを強く推奨する。
なぜなら、「パスワードをファイルとして保持しないこと」こそが、最強のセキュリティだからだ。
IaCのコードは、常に「破壊」と「再構築」が前提であるべきだ。Vaultはその過渡期における強力な武器だが、最終的には「機密をコード化しない」アーキテクチャを目指してほしい。
この知見が、君のインフラをより強固で、より美しいものにすることを確信している。健闘を祈る。