【連載 第6回】Ansible Vault：パスワードなどの機密情報を暗号化する〜セキュリティの最後の砦〜

そのコミット待った！ GitHubにパスワードを公開する気ですか？

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回（第5回）は、Playbookを「ロール」として部品化し、再利用性を高める設計手法を学びました。
これで大規模な構築も怖くありませんね。

しかし、コード化が進むにつれて、ある「危険なデータ」も一緒にコードに含まれるようになります。
そう、「データベースのルートパスワード」や「AWSのアクセスキー」、「SSHの秘密鍵」などの機密情報です。

これらを平文（そのままの文字）でPlaybookに書いてGitにコミットしてしまうと、リポジトリにアクセスできる全員がパスワードを見れてしまいます。
もしそれがパブリックリポジトリなら…考えただけでも恐ろしいですね。

本記事では、Ansible Vaultを使ったファイルの暗号化から、変数の一部だけを暗号化する高等テクニック、そして自動化におけるパスワード管理の方法までを徹底解説します。

---

1. Ansible Vaultとは？ なぜ必要なのか

Ansible Vaultは、Playbookや変数ファイル（YAML）をAES-256という強力なアルゴリズムで暗号化する機能です。
復号するための「Vaultパスワード」を知っている人（またはシステム）だけが、中身を読むことができます。

GitOps時代の必須機能

現代のインフラ構築は、コードをGitで管理する「GitOps」が主流です。
しかし、Gitは変更履歴をすべて記録するため、一度でもパスワードを平文でコミットしてしまうと、後からファイルを消しても履歴から漏洩します。

Ansible Vaultを使えば、「暗号化された状態」でGitにコミットできます。
これなら、万が一リポジトリが流出しても、パスワード自体は守られます。

---

2. 基本操作：ファイルを丸ごと暗号化する

まずは最も基本的な使い方として、秘密の変数を書いたファイルを丸ごと暗号化してみましょう。

2-1. 暗号化ファイルの作成 (create)

secret.yml というファイルを新規作成し、同時に暗号化します。

ansible-vault create secret.yml

コマンドを実行すると、パスワードの入力を求められます。
入力後、エディタ（vimなど）が開くので、機密情報を記述します。

db_password: "SuperSecretPassword123"
aws_secret_key: "AKIAXXXXXXXXXXXXXXXX"

保存して閉じると、ファイルは暗号化されています。
cat secret.yml で中身を見てみましょう。

$ANSIBLE_VAULT;1.1;AES256
34353236313865323162653036326131333732353361666662386266393433613636643265666265
...

このように、人間には読めない文字列になります。

2-2. 暗号化ファイルの内容を見る (view)

中身を確認したい場合は view を使います。

ansible-vault view secret.yml

Vaultパスワードを入力すると、平文の内容が表示されます。

2-3. 暗号化ファイルを編集する (edit)

内容を修正したい場合は edit を使います。

ansible-vault edit secret.yml

一時的に復号された状態でエディタが開き、保存すると自動的に再暗号化されます。

2-4. 既存ファイルを暗号化する (encrypt / decrypt)

既に存在する平文ファイルを暗号化したり、元に戻したりするコマンドです。

# 暗号化する
ansible-vault encrypt plain_vars.yml

# 復号して平文に戻す（注意！）
ansible-vault decrypt plain_vars.yml

2-5. Playbookの実行方法

暗号化されたファイルを含むPlaybookを実行する場合、--ask-vault-pass オプションが必要です。

ansible-playbook site.yml --ask-vault-pass

実行開始時にパスワード入力を求められ、正しければ自動的に変数が展開されて実行されます。

---

3. 実践：変数の一部だけを暗号化する (encrypt_string)

ファイルを丸ごと暗号化する方法には、大きなデメリットがあります。
それは、「Gitの差分（Diff）が見えなくなる」ことです。

例えば、group_vars/all.yml には「NTPサーバーのアドレス」などの公開しても良い情報と、「DBパスワード」などの機密情報が混ざっています。
これを丸ごと暗号化すると、NTP設定を変えただけでもレビューができなくなります。

そこで、プロの現場では「値だけを暗号化する (Inline Vault)」手法が好まれます。

3-1. encrypt_string の使い方

以下のコマンドを実行します。

ansible-vault encrypt_string 'SuperSecretPassword123' --name 'db_password'

すると、以下のような出力が得られます。

db_password: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          38346633626231363636323631306332616534353366366432326265326539316139626336336531
          ...

3-2. Playbookへの埋め込み

この出力をそのまま group_vars/all.yml などにコピペします。

# group_vars/all.yml

# これは平文で見える（レビューしやすい）
ntp_server: "ntp.nict.jp"
app_port: 8080

# これだけ暗号化されている
db_password: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          38346633626231363636323631306332616534353366366432326265326539316139626336336531
          ...

これで、「機密情報は守りつつ、その他の設定変更はGitで差分確認ができる」という理想的な状態になります。

---

4. 運用の自動化：パスワードファイルの活用

毎回 --ask-vault-pass でパスワードを手入力するのは面倒ですし、JenkinsやGitHub ActionsなどのCI/CDツールで自動実行することができません。

そこで、Vaultパスワードを記載した「パスワードファイル」を使用します。

4-1. パスワードファイルの作成

ホームディレクトリやプロジェクト直下に、パスワードを書いたテキストファイルを作成します。
ファイル名は何でも良いですが、隠しファイル .vault_pass などにするのが一般的です。

echo "MyVaultPassword" > .vault_pass

4-2. パスワードファイルを使った実行

--vault-password-file オプションでファイルを指定します。

ansible-playbook site.yml --vault-password-file .vault_pass

これでパスワード入力なしで実行できます。

4-3. ansible.cfg でのデフォルト指定

毎回オプションを打つのも面倒な場合は、ansible.cfg に設定してしまいます。

[defaults]
vault_password_file = ./.vault_pass

これで ansible-playbook site.yml だけで実行できるようになります。

---

5. 【プロのノウハウ】環境ごとのパスワード管理戦略

実務では、「開発環境(Dev)」「検証環境(Staging)」「本番環境(Prod)」で、異なるパスワードを使うのが鉄則です。
しかし、Ansible Vaultのパスワードが1つだけだと、開発担当者が本番のパスワードを知ってしまうことになります。

これを防ぐために、「Vault ID」を使って環境ごとにVaultパスワードを分けます。

5-1. 暗号化時にIDを指定する

dev 用と prod 用でIDを分けて暗号化します。

# 開発環境用の変数を暗号化 (ID: dev)
ansible-vault encrypt_string 'DevPass' --name 'db_password' --vault-id dev@prompt

# 本番環境用の変数を暗号化 (ID: prod)
ansible-vault encrypt_string 'ProdPass' --name 'db_password' --vault-id prod@prompt

生成された暗号文には、ヘッダ部分にIDが記録されます（$ANSIBLE_VAULT;1.2;AES256;dev など）。

5-2. 実行時にIDを指定する

開発者は dev のパスワードしか知らない状態でも、以下のように開発環境へのデプロイが可能です。

ansible-playbook site.yml --vault-id dev@.vault_pass_dev

本番デプロイ時は、本番管理者だけが知っているパスワードファイルを使います。

ansible-playbook site.yml --vault-id prod@.vault_pass_prod

これにより、1つのリポジトリで管理しつつ、権限の分離が可能になります。

---

6. パスワードの変更と再暗号化 (rekey)

「担当者が退職したので、Vaultパスワードを変更したい」
こんな時、全てのファイルを一度復号して、新しいパスワードで暗号化し直す…なんて面倒なことは不要です。

rekey コマンドを使えば、一発でパスワードを変更できます。

ansible-vault rekey secret.yml

1. 現在のパスワードを入力
2. 新しいパスワードを入力

これで、ファイルの中身（暗号化されたデータ）が新しいパスワードで書き換えられます。
定期的なパスワードローテーション運用もこれで安心です。

---

まとめ：セキュリティと利便性は両立できる

お疲れ様でした！
第6回では、機密情報を安全に扱うための「Ansible Vault」について深く学びました。

今回の要点まとめ：

• パスワードなどの機密情報は、絶対に平文でGitに上げない。
• ansible-vault を使えば、ファイルや変数をAES-256で暗号化できる。
• encrypt_string を使えば、YAML構造を保ったまま値だけ暗号化できる（推奨）。
• .vault_pass ファイルを使えば、パスワード入力を自動化できる（Git除外必須）。
• Vault ID を使えば、環境ごとにパスワードを使い分けられる。

さて、自動化が進んでPlaybookが複雑になってくると、今度は「実行したけど途中で止まった」「何が原因でエラーになったか分からない」というトラブルが増えてきます。
次回は、堅牢な自動化を実現するための「エラーハンドリング」と、プロが実践する「デバッグ術」について学びます。

次回、【第7回】エラーハンドリングとデバッグ：止まらない自動化のために でお会いしましょう！