Ansibleの権限昇格エラーをBecomeとSudoで修正する

Ansibleの権限昇格エラーは、タスクがrootアクセスを必要とする場合に、接続ユーザーが正しくsudoを使用できないときに発生します。「permission denied」「missing sudo password」、またはSSHでは動作するがプレイブック内で失敗するタスクなどのエラーが表示されることがあります。

修正方法は、通常、Ansibleのbecome設定とターゲットホストのsudoers設定の組み合わせです。このガイドでは両方の側面を説明します。

Ansibleの`become`メカニズムを理解する

Ansibleは、基本的にターゲットホストに接続し（通常はSSH経由）、リモートユーザーとしてコマンドを実行します。しかし、多くの管理タスクでは昇格された権限（例：Linuxシステムでのrootアクセス）が必要です。ここでAnsibleのbecome機能が役立ちます。becomeメカニズムにより、Ansibleは特定のタスクやプレイ全体を昇格された権限で実行するために、別のユーザー（通常はroot）に「なる」ことができます。

`become`が必要な理由

すべてのAnsibleタスクを直接rootユーザーとして実行することは、一般的にセキュリティ上の悪い習慣です。代わりに、通常はリモートホストに一般ユーザー（多くの場合ansible_userと呼ばれる）として接続し、必要なタスクに対してのみbecomeを使用して一時的に権限を昇格させます。これは最小権限の原則に従い、セキュリティ侵害の潜在的な影響を最小限に抑えます。

`become`メソッド

Ansibleは権限昇格のために複数のメソッドをサポートしており、それぞれ異なるシステムユーティリティに対応しています。特にLinux/Unixシステムで最も一般的で広く使用されているメソッドはsudo（Substitute User Do）です。他のメソッドにはsu、pbrun、doasなどがありますが、このガイドでは主にsudoに焦点を当てます。

Ansibleでの`become`設定の構成

Ansibleでは、グローバル設定からタスク固有のオーバーライドまで、become設定を構成する複数の方法があります。これらのスコープを理解することは、効果的な権限管理に重要です。

1. `ansible.cfg`でのグローバル設定

多くのプレイブックで一般的なユースケースの場合、ansible.cfgファイルにデフォルトのbecomeパラメータを設定できます。これは通常、Ansibleを実行するディレクトリ、~/.ansible.cfg、または/etc/ansible/ansible.cfgにあります。

# ansible.cfg
[privilege_escalation]
become=True
become_method=sudo
become_user=root
become_ask_pass=False ; パスワードを入力するようAnsibleに促す場合はTrueに設定

become=True: すべてのプレイでデフォルトで権限昇格を有効にします。
become_method=sudo: 権限昇格のメソッドとしてsudoを指定します。
become_user=root: 対象ユーザーとしてrootを指定します。
become_ask_pass=False: Ansibleがbecomeパスワードを要求するかどうかを制御します。他の方法でパスワードを提供しない場合はTrueに設定します。

2. プレイブック内のプレイごとまたはタスクごと

より細かい制御のために、become設定をプレイブック内で直接定義できます。プレイレベル（そのプレイ内のすべてのタスクに影響）または個々のタスクレベルで設定できます。

プレイレベル設定:

---
- name: 昇格された権限でNginxをインストール
  hosts: webservers
  become: yes          # このプレイ内のすべてのタスクでbecomeを有効化
  become_user: root
  become_method: sudo

  tasks:
    - name: Nginxがインストールされていることを確認
      ansible.builtin.apt:
        name: nginx
        state: present
      # このタスクはsudo経由でrootとして実行されます

    - name: Nginx設定をコピー
      ansible.builtin.copy:
        src: nginx.conf
        dest: /etc/nginx/nginx.conf
      # このタスクもsudo経由でrootとして実行されます

タスクレベル設定:

---
- name: 異なるユーザーとしてファイルを管理
  hosts: all

  tasks:
    - name: ansible_user（デフォルト）としてファイルを作成
      ansible.builtin.file:
        path: /tmp/unprivileged_file.txt
        state: touch
        mode: '0644'

    - name: becomeを使用してroot所有のファイルを作成
      ansible.builtin.file:
        path: /root/privileged_file.txt
        state: touch
        mode: '0600'
      become: yes          # このタスクのみbecomeを使用
      become_user: root
      become_method: sudo

3. インベントリ変数経由

become設定はAnsibleインベントリでも定義でき、ホストやグループごとに異なる権限昇格戦略を指定できます。

hosts.iniの例:

[webservers]
web1.example.com
web2.example.com

[dbservers]
db1.example.com

[all:vars]
ansible_user=devops_user
ansible_become=true
ansible_become_method=sudo
ansible_become_user=root

ここで、ansible_become、ansible_become_method、ansible_become_userはbecome設定に対応するインベントリ変数です。これらはall:varsレベル、グループレベル、またはホストレベルで設定できます。

4. `ansible-playbook` CLI引数の使用

迅速なオーバーライドや対話的な実行のために、コマンドラインから直接becomeパラメータを渡すことができます。

--becomeまたは-b: becomeを有効化。
--become-method <METHOD>: becomeメソッドを指定（例：sudo）。
--become-user <USER>: 対象ユーザーを指定（例：root）。
--ask-become-passまたは-K: 実行中にbecomeパスワードを要求。テストには便利ですが、自動化には一般的に使用しません。

例:

ansible-playbook my_playbook.yml --become --become-user root --ask-become-pass

`become`ユーザーの`sudo`権限を確保する

Ansibleでbecomeを正しく設定することは半分の作業に過ぎません。Ansibleが接続するユーザー（ansible_user）は、ターゲットホスト上でbecome_userになるために必要なsudo権限を持っている必要があります。これはターゲットホストの/etc/sudoersファイルまたは/etc/sudoers.d/下のファイルで設定します。

`sudoers`の設定

sudoersファイルは、誰がどのコマンドを、誰として実行できるかを定義します。Ansible接続ユーザー（この例ではdevops_user）がパスワードなしで任意のコマンドを任意のユーザーとして実行できるようにする一般的なエントリは次のとおりです。

# /etc/sudoers.d/devops
devops_user ALL=(ALL) NOPASSWD: ALL

説明:

devops_user: Ansibleが接続するユーザー名（ansible_user）。
ALL: このユーザーは任意の端末からコマンドを実行できます。
(ALL): このユーザーは任意のユーザーとしてコマンドを実行できます。
NOPASSWD:: sudo操作にパスワードが不要であることを指定します。
ALL: このユーザーはすべてのコマンドを実行できます。

警告: NOPASSWD: ALLを許可すると、ansible_userにパスワードなしで無制限のrootアクセスが与えられ、重大なセキュリティリスクとなる可能性があります。本当に必要な場合のみ使用し、ansible_userの認証情報が高度に安全であることを確認してください。より厳格なセキュリティのためには、ユーザーが実行できる正確なコマンドまたはコマンドセットを指定できます。

`sudo`アクセスの確認

プレイブックを実行する前に、ターゲットホスト上でansible_userがsudoアクセスを持っているか手動で確認できます。ansible_userとしてホストにSSH接続し、次のコマンドを実行します。

# パスワードなしでrootにsudoできるか確認
sudo -n whoami

# パスワードが必要な場合はプロンプトが表示されます。簡単なコマンドでテスト:
sudo whoami

# 現在のユーザーのsudo権限を一覧表示:
sudo -l

# 特定のユーザー（例：devops_user）のsudo権限を一覧表示:
sudo -l -U devops_user

sudo -n whoamiがパスワードプロンプトなしでrootを返す場合、NOPASSWD設定は正しい可能性が高いです。パスワードを要求された場合、sudoersエントリにNOPASSWDがないか、設定が間違っている可能性があります。

権限昇格エラーの診断

Ansibleは通常、有益なエラーメッセージを提供しますが、権限関連の問題は時にわかりにくいことがあります。以下に一般的なエラーとその解決策を示します。

1. "permission denied"

これは通常、タスクがrootではなく権限のない接続ユーザーとして実行されたことを意味します。

プレイまたはタスクを確認:

- name: rootが必要なパッケージをインストール
  ansible.builtin.package:
    name: nginx
    state: present
  become: true

次に、Ansibleが使用しているユーザーを確認:

ansible webservers -m ansible.builtin.command -a 'whoami'
ansible webservers -b -m ansible.builtin.command -a 'whoami'

2番目のコマンドは、sudoが機能している場合にrootを返すはずです。

2. "Missing sudo password"

これは、ターゲットホストがsudoパスワードを必要とするが、Ansibleにパスワードが提供されていない場合に発生します。

対話的な実行の場合、次を使用:

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

自動化の場合、インベントリに平文パスワードを保存しないでください。環境でパスワードなしのsudoが許可されていない場合は、ansible_become_passwordにAnsible Vaultを使用します。

ansible-vault encrypt group_vars/webservers/vault.yml

暗号化前の変数名の例:

ansible_become_password: "実際のパスワードに置き換え"

3. "user is not in the sudoers file"

これはターゲットホストの設定問題です。Ansibleは、すでに十分な権限を持つユーザーとして接続できない限り、これを修正できません。

ターゲットホストで、visudoまたは/etc/sudoers.d/下のファイルを使用:

devops_user ALL=(ALL) NOPASSWD: /usr/bin/systemctl, /usr/bin/apt, /usr/bin/yum

これはNOPASSWD: ALLよりも狭い範囲ですが、プレイブックがこれらの正確なコマンドを必要とする場合にのみ機能します。パッケージモジュールはOSによって異なるバイナリを呼び出す可能性があるため、注意深くテストしてください。

4. 間違った`become_user`

ほとんどのLinux管理タスクではbecome_user: rootを使用します。become_userをアプリケーションアカウントに設定した場合、そのユーザーはシステムファイルの変更やサービスの管理に必要な権限を欠いている可能性があります。

簡単な確認:

- name: 有効なユーザーを確認
  ansible.builtin.command: whoami
  become: true
  changed_when: false

出力が期待したユーザーでない場合、競合するbecome_user値についてプレイブック変数、インベントリ変数、ansible.cfgを確認してください。

安全なトラブルシューティングチェックリスト

ターゲットホストからプレイブックに向かって作業します。

ansible_userとしてホストにSSH接続。
sudo -lを実行し、ユーザーが必要な権限を持っていることを確認。
パスワードなしのsudoを期待する場合はsudo -n whoamiを実行。
1つのテストホストに対してansible all -b -m command -a 'whoami'を実行。
エラーがまだ不明な場合は、失敗したプレイブック実行に-vvvを追加。

重要なポイント

Ansibleのbecomeは、Ansibleに権限を昇格するよう指示するだけです。ターゲットホストは、接続ユーザーがsudoまたは他のbecomeメソッドを介してそれを実行できるようにする必要があります。両方を修正してください。タスクが必要な場所にbecomeを設定し、ホスト上で直接sudo権限を確認します。

Ansibleの権限昇格エラーをBecomeとSudoで修正する

Ansibleのbecomeメカニズムを理解する

becomeが必要な理由

becomeメソッド

Ansibleでのbecome設定の構成

1. ansible.cfgでのグローバル設定