Ansibleで構成管理を自動化するとき、必ずぶつかるのが「権限」の問題です。Webサーバーの設定ファイルを書き換えるには root 権限が必要ですが、SSHを root で直接接続するのはセキュリティリスクが大きく、多くの企業で禁止されています。そこで使うのが become(privilege escalation:権限昇格)です。
この記事では、Ansibleの become の仕組みと、運用現場で崩れない権限設計のパターンを解説します。become_user・become_method の使い分けから、設定スコープ(ansible.cfg・inventory・タスクレベル)の選択、Ansible Vault を使ったパスワードの安全管理まで、順を追って体系的に身につけられます。
この記事のポイント
・become: true でSSH接続ユーザーを root に昇格させて操作できる
・設定スコープは「ansible.cfg>inventory変数>タスクレベル」の3段構造
・タスクごとに become を個別指定することで最小権限原則を守れる
・become_pass は Ansible Vault で暗号化して Git に安全にコミットする
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜAnsibleにprivilege escalation(become)が必要なのか
Ansibleは通常、SSH接続したユーザーの権限でタスクを実行します。たとえば SSH を `ansibleuser` というサービスアカウントで接続した場合、パッケージのインストールや `/etc/` 配下の設定ファイル変更は、そのままでは権限エラーになります。多くの企業環境では、セキュリティポリシーとして「直接のroot SSH接続を禁止(`PermitRootLogin no`)」しています。この制約のもとでも構成管理を自動化するために、become が必要になります。
become は Ansible が sudo や su コマンドを代わりに実行する仕組みです。`become: true` を指定するだけで、タスクを指定ユーザー(デフォルトは root)の権限で実行できます。Puppet や Chef の "apply as root" 相当の機能を、より細かい粒度で制御できる点が特徴です。
becomeの基本構文|become・become_user・become_methodの役割
1. become: true で権限昇格を有効にする
# シンプルな become の例(RHEL 9.4 / Ubuntu 24.04 LTS で動作確認済み) - name: Apache パッケージをインストールする ansible.builtin.package: name: httpd state: present become: true
# ansible-playbook 実行後の出力例(管理ノード: web01.example.com) TASK [Apache パッケージをインストールする] ******************* changed: [web01.example.com]
2. become_user で昇格先ユーザーを指定する
# アプリケーション専用ユーザーとして操作する例 - name: デプロイスクリプトを実行する ansible.builtin.shell: /opt/myapp/scripts/deploy.sh become: true become_user: appuser
3. become_method で昇格方法を選択する
# su コマンドで昇格する例 - name: su で root に昇格して実行する ansible.builtin.command: id become: true become_user: root become_method: su # 利用可能な become_method の一覧を確認する ansible-doc -t become -l
Ansible実践ハンズオンの詳細を見る >>
becomeを設定する3つのスコープ
become の設定は「どこに書くか」によって適用範囲が変わります。3つのスコープを理解することが設計の核心です。1. ansible.cfg(プロジェクト全体のデフォルト設定)
# ansible.cfg の例 [privilege_escalation] become = True become_method = sudo become_user = root become_ask_pass = False
ただし、すべてのタスクが root 権限で実行される設定を全体デフォルトにするのは最小権限の観点で推奨しません。「全ホスト・全タスクで必ず root 操作が必要」な限られたケースでのみ使います。
2. inventoryファイルまたはgroup_vars(ホスト・グループ単位の設定)
# inventory.ini の例(ホストごとに個別設定) [webservers] web01.example.com ansible_become=true ansible_become_user=root web02.example.com ansible_become=true ansible_become_user=root [dbservers] db01.example.com ansible_become=false
# group_vars/webservers.yml ansible_become: true ansible_become_method: sudo ansible_become_user: root
3. Playbook・タスクレベル(最も細粒度な設定)
# タスクごとに become を個別指定する例 - name: Nginx 設定変更 Playbook hosts: webservers become: false # Playbook全体では昇格しない tasks: - name: 設定ファイルを配置する(root権限が必要) ansible.builtin.template: src: nginx.conf.j2 dest: /etc/nginx/nginx.conf owner: root group: root mode: '0644' become: true # このタスクだけ昇格 - name: 設定ファイルの構文チェック(一般ユーザーで可能) ansible.builtin.command: nginx -t # become は指定しない
Ansible Vaultと組み合わせたbecomeパスワードの安全な管理
sudo がパスワードなしで使える環境(NOPASSWD 設定)が理想ですが、セキュリティポリシーでパスワードが必須の場合は Ansible Vault と組み合わせます。1. NOPASSWD 設定(推奨パターン)
# /etc/sudoers.d/ansibleuser の内容(visudo で編集) # 特定コマンドのみ NOPASSWD を許可する ansibleuser ALL=(ALL) NOPASSWD: /usr/bin/dnf, /usr/bin/apt-get, /bin/systemctl, /usr/bin/cp # NG: 全コマンドを NOPASSWD にするのはリスクが高い # ansibleuser ALL=(ALL) NOPASSWD: ALL
2. Vault で become パスワードを暗号化する
sudo がパスワード付きの場合は、Vault に暗号化して保存します。# Vault でパスワード文字列を暗号化する ansible-vault encrypt_string 'sudo_password_here' --name 'ansible_become_pass' # 出力例(この文字列を group_vars に貼り付ける) ansible_become_pass: !vault | $ANSIBLE_VAULT;1.1;AES256 38623337353539386238363732353337...
# group_vars/all.yml に追記 ansible_become_pass: !vault | $ANSIBLE_VAULT;1.1;AES256 38623337353539386238363732353337...(暗号化された文字列)
# Vault パスワードをファイルで指定する方法 ansible-playbook site.yml --vault-password-file ~/.vault_pass # または実行時に対話入力する方法 ansible-playbook site.yml --ask-vault-pass
セキュリティ設計|rootを使わずに最小権限でタスクを実行する方法
become の設計で最も重要なのは「必要最小限の権限しか与えない」最小権限の原則です。現場のベストプラクティスを4つの原則にまとめます。・SSH接続ユーザーと become_user を分離する(SSH は一般ユーザー、操作は root または専用サービスアカウント)
・Playbook 全体に `become: true` を設定せず、タスク単位で個別に指定する
・sudoers は `ALL` ではなく、実行するコマンドのみに限定する
・become_pass が必要な場合は Ansible Vault で暗号化し、平文での保存を禁止する
専用の Ansible 実行ユーザーを作成する設計例
# 管理対象サーバー側の設定(管理者が初回のみ手動設定) # 1. Ansible専用ユーザーを作成する useradd -m -s /bin/bash ansibleuser # 2. SSH公開鍵を登録する mkdir -p /home/ansibleuser/.ssh cat /tmp/ansible_id_rsa.pub >> /home/ansibleuser/.ssh/authorized_keys chmod 700 /home/ansibleuser/.ssh chmod 600 /home/ansibleuser/.ssh/authorized_keys chown -R ansibleuser:ansibleuser /home/ansibleuser/.ssh # 3. sudoers に必要なコマンドのみを登録する cat > /etc/sudoers.d/ansibleuser << 'EOF' ansibleuser ALL=(ALL) NOPASSWD: /usr/bin/dnf, /usr/bin/apt-get, /bin/systemctl, /usr/bin/cp, /usr/bin/install EOF chmod 440 /etc/sudoers.d/ansibleuser # 4. 動作確認(ansibleユーザーに切り替えて sudo テスト) su - ansibleuser sudo dnf --version
becomeに関するトラブルシュートと確認コマンド
エラー1: sudo: no tty present and no askpass program specified
`become_ask_pass: True`(または `-K` オプション)でパスワードプロンプト待ちになっているが、対話入力が提供されていない状態です。`ansible.cfg` で `become_ask_pass = False` に設定するか、NOPASSWD 設定を確認してください。エラー2: Missing sudo password
`ansible_become_pass` が設定されていないか、Ansible Vault の復号化に失敗しています。`--ask-become-pass`(`-K`)オプションで一時的に手動入力してテストし、正常に動作するかを確認してから Vault 設定を見直してください。エラー3: sudo: XXX is not in the sudoers file
SSH 接続ユーザーが sudoers に登録されていない状態です。`/etc/sudoers.d/` に設定ファイルが存在するか、`visudo -c` でシンタックスエラーがないかを確認してください。become の動作確認(アドホックコマンドで事前テスト)
# become が正常に機能するか事前テスト(-K でパスワードを対話入力) ansible webservers -m ansible.builtin.command -a "id" --become -K # 成功した場合の出力例(root に昇格していることを確認) web01.example.com | CHANGED | rc=0 >> uid=0(root) gid=0(root) groups=0(root) # 昇格先を appuser に指定する場合 ansible webservers -m ansible.builtin.command -a "id" --become --become-user=appuser # 出力例 web01.example.com | CHANGED | rc=0 >> uid=1001(appuser) gid=1001(appuser) groups=1001(appuser)
本記事のまとめ
| 設定項目 | 使い方 |
|---|---|
| 基本の権限昇格を有効にする | become: true |
| 昇格先ユーザーを指定する | become_user: appuser(省略時は root) |
| 昇格方法を指定する | become_method: sudo(デフォルト) |
| プロジェクト全体のデフォルト設定 | ansible.cfg の [privilege_escalation] |
| ホスト・グループ単位で設定する | group_vars の ansible_become: true |
| タスクごとに個別設定する(推奨) | タスクに直接 become: true を記述 |
| sudo パスワードを安全に管理する | ansible-vault encrypt_string で暗号化して ansible_become_pass に設定 |
| 動作を事前確認する | ansible ホスト -m command -a "id" --become -K |
Ansible Vault を使った秘密情報の管理については、「Ansible Vaultでシークレットを安全に管理する方法」の記事も合わせて参考にしてください。
Ansible実践ハンズオンの詳細を見る >>
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 前のページへ:AnsibleのBlocks・rescue・alwaysでエラー処理を設計する方法|タスク失敗時のロールバックと通知の実践パターン
- この記事の属するカテゴリ:Ansibleへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます