AnsibleがWorld-Writableディレクトリのansible.cfgを無視する問題を修正

確認されている症状

プレイブックを実行したところ、Ansibleがansible.cfgを読み込んでいない — またはターミナルに以下の警告が表示される場合があります：

Ansible is being run in a world writable directory (/path/to/dir), ignoring it as an ansible.cfg source.
For more information see https://docs.ansible.com/ansible/devel/reference_appendices/config.html#cfg-in-world-writable-dir

プレイブックはデフォルト設定で実行され続けます — さらに悪い場合は、別の場所にある設定が無言で読み込まれることもあります。インベントリパス、become設定、SSHオプションなど、エラーメッセージが一切表示されないまま、意図しない動作をする可能性があります。

Ansibleがこの動作をする理由

Ansibleは、システム上の誰もが書き込めるディレクトリからはansible.cfgを読み込まないようになっています。セキュリティ上の理由は明快です。他のユーザーがそのディレクトリに書き込めると、偽のansible.cfgを置くことができます。その偽の設定ファイルによって、SSHキー、特権昇格の設定、コールバックプラグインが、気づかないうちに上書きされる可能性があるからです。

このチェックはAnsible 2.4で導入され、無効化するフラグはありません。スキップするための環境変数も存在しません。解決するにはディレクトリのパーミッションを修正するしかありません。

現在のパーミッションを確認する

何かを変更する前に、実際の状態を確認しましょう：

ls -ld /path/to/dir

ワールドライタブルなディレクトリは以下のように表示されます — 最後のトリプレットにあるwに注目してください：

drwxrwxrwx 3 alice devops 4096 May  6 10:00 /path/to/dir
#        ^--- この "w" が問題です

Ansibleは「その他のユーザー」が書き込みアクセスを持つディレクトリをすべて拒否します。それはパーミッション文字列の3番目のグループにあたる3文字です。drwxrwxrwx（777）は拒否されます。drwxrwxr-x（775）は拒否されません — その他のユーザーは読み取りのみ可能です。迷った場合は、最後のwを確認してください。

クイック修正：ワールドライト権限を削除する

ワールドライタブルビットを削除します：

chmod o-w /path/to/dir

ほとんどのプロジェクトディレクトリでは、755が適切な選択です：

chmod 755 /path/to/dir

修正されたか確認します：

ls -ld /path/to/dir
# 以下のように表示されるはずです: drwxr-xr-x

再度プレイブックを実行してください。警告が消え、Ansibleが正常に設定を読み込むようになります。

共有ディレクトリやシステムディレクトリの場合

/tmpや共有ワークスペース、CI/CDエージェントのディレクトリなど、意図的にワールドライタブルになっているディレクトリ内にいて、パーミッションを変更できない場合があります。その場合は2つの選択肢があります：

オプション1 — ansible.cfgをより安全な場所に移動する

Ansibleは固定された順序で複数の場所を検索します。ホームディレクトリもその一つであり、ほぼ常に安全なパーミッションが設定されています。

mkdir -p ~/.ansible
cp ansible.cfg ~/.ansible/ansible.cfg

またはディレクトリ検索を完全にスキップするためにANSIBLE_CONFIGを使用します。ファイルを直接指定してください — この変数を使用するとAnsibleはディレクトリのパーミッションチェックをスキップします：

export ANSIBLE_CONFIG=/home/alice/secure-dir/ansible.cfg
ansible-playbook site.yml

オプション2 — CI/CDパイプラインでパーミッションを修正する

CIのチェックアウトディレクトリはデフォルトで広いパーミッションが付与されることが多いです。Ansible実行前にパーミッションを制限するステップを追加してください：

# GitHub Actions
- name: Fix workspace permissions
  run: chmod 755 $GITHUB_WORKSPACE

- name: Run playbook
  run: ansible-playbook site.yml

GitLab CIの場合：

before_script:
  - chmod 755 "$CI_PROJECT_DIR"

修正が適用されたか確認する

Ansibleが実際に読み込んでいる設定ファイルを確認します：

ansible --version

config fileの行を確認してください：

ansible [core 2.16.0]
  config file = /path/to/dir/ansible.cfg   ← 自分のファイルを指しているはずです
  configured module search path = ...
  ...

config file = Noneや予期しないパスが表示されている場合は、ディレクトリのパーミッションがまだ修正されていないか、検索順序の上位で別の設定ファイルが見つかっているということです。

有効なすべての設定とその参照元を確認するには、次を実行します：

ansible-config dump --only-changed

修正後によくある間違い

ディレクトリではなくファイルを修正してしまう — Ansibleはディレクトリのパーミッションをチェックします。chmod 600 ansible.cfgを実行しても意味がありません。ファイルが入っているフォルダを修正する必要があります。
ネストされたディレクトリ — ansible.cfgが/shared/projects/myapp/にある場合、修正が必要なのはそのディレクトリです。親ディレクトリではありません。Ansibleは設定ファイルを直接含むディレクトリだけをチェックします。
/tmpから作業している — /tmpはスティッキービット（drwxrwxrwt）が設定されていますが、それでもワールドライタブルです。Ansibleはそこにあるansible.cfgを無視します。プロジェクトを適切な作業ディレクトリに移動してください。

ヒント

755や777のようなパーミッション数値は一見してわかりにくいことがあります。ToolCraftのUnix Permissions Calculatorを使えば、任意のchmod値を入力するだけで、オーナー・グループ・その他のユーザーに対してどの読み取り/書き込み/実行ビットが設定されているかを正確に確認できます — 共有ディレクトリのパーミッションを変更する前に役立ちます。

期待どおりに解析されないgroup_varsやhost_varsファイルについては、YAML ↔ JSON Converterがインデントエラーを素早く見つけるのに便利です。YAMLを貼り付けてJSONに変換すると、構造上の問題がすぐに浮かび上がります。