Ansibleのbecomeでsudo権限を設計する方法|become_user・become_methodと最小権限設計の実践

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)Ansible > Ansibleのbecomeでsudo権限を設計する方法|become_user・become_methodと最小権限設計の実践
「Ansibleを本番環境で動かしたいが、rootユーザーでSSH接続するのが怖い」「become を使えば良いと聞いたが、どこに書けばいいのかわからない」

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 に安全にコミットする


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

なぜ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

`become: true` を指定すると、Ansible は SSH で接続したユーザーから指定した特権ユーザー(デフォルトは root)へ昇格してタスクを実行します。昇格は `sudo` コマンドで行われ、以下のような実行ログが出力されます。

# 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

`become_user` を省略した場合のデフォルトは root です。Webアプリのデプロイなど、root ではなく専用のサービスアカウント(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

デフォルトの昇格方法は `sudo` です。環境によっては `su`・`pbrun`・`pfexec`・`dzdo` などを指定します。`ansible-doc -t become -l` で現在の Ansible バージョンで使える方法を確認できます。
becomeの設定を含むAnsible権限設計を実務で使える形で身につけたい方へ、20年以上の運用経験を持つ現役エンジニアが基礎から教えます。
Ansible実践ハンズオンの詳細を見る >>

becomeを設定する3つのスコープ

become の設定は「どこに書くか」によって適用範囲が変わります。3つのスコープを理解することが設計の核心です。

1. ansible.cfg(プロジェクト全体のデフォルト設定)

# ansible.cfg の例 [privilege_escalation] become = True become_method = sudo become_user = root become_ask_pass = False

`ansible.cfg` の `[privilege_escalation]` セクションに書くと、プロジェクト全体のデフォルト値になります。

ただし、すべてのタスクが 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 を使う場合は以下のように書きます:

# group_vars/webservers.yml ansible_become: true ansible_become_method: sudo ansible_become_user: root

ホストやグループによって権限昇格の要否が異なる場合は、inventory 変数(`ansible_become`)で制御します。dev 環境と本番環境で設定を分けたいときは、inventory の分離(group_vars/dev/ と group_vars/prod/)と組み合わせると管理しやすくなります。

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 は指定しない

**最も推奨するアプローチはタスクレベルでの個別指定**です。必要なタスクにだけ `become: true` を付けることで、最小権限の原則を徹底できます。どのタスクが root 操作を行うかが Playbook を見るだけで一目でわかり、レビューがしやすくなるメリットもあります。

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

実行するコマンドを限定して NOPASSWD にすることで、パスワード不要かつ最小権限を両立できます。Ansible が実際に実行するコマンドを確認するには `--check` モードと `--diff` オプションを組み合わせてください(SSHで接続できるかポート確認する方法も参考に)。

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 に書き込みます:

# group_vars/all.yml に追記 ansible_become_pass: !vault | $ANSIBLE_VAULT;1.1;AES256 38623337353539386238363732353337...(暗号化された文字列)

Playbook の実行時には Vault パスワードを渡します:

# Vault パスワードをファイルで指定する方法 ansible-playbook site.yml --vault-password-file ~/.vault_pass # または実行時に対話入力する方法 ansible-playbook site.yml --ask-vault-pass

become_pass を平文でファイルに書くことは絶対に避けてください。Vault で暗号化することで、Git リポジトリに安全にコミットできます。

セキュリティ設計|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

この設計のポイントは「ansibleuser 自体はパスワードログインできない(鍵認証のみ)」「sudo できるコマンドが明示的に限定されている」の2点です。仮に Ansible の実行ユーザーが侵害されても、被害を最小限に抑えられます。

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)

本番に Playbook を適用する前に、アドホックコマンドで become が期待通りに動くかを事前に確認しておくと安全です。

本記事のまとめ

設定項目 使い方
基本の権限昇格を有効にする become: true
昇格先ユーザーを指定する become_user: appuser(省略時は root)
昇格方法を指定する become_method: sudo(デフォルト)
プロジェクト全体のデフォルト設定 ansible.cfg[privilege_escalation]
ホスト・グループ単位で設定する group_varsansible_become: true
タスクごとに個別設定する(推奨) タスクに直接 become: true を記述
sudo パスワードを安全に管理する ansible-vault encrypt_string で暗号化して ansible_become_pass に設定
動作を事前確認する ansible ホスト -m command -a "id" --become -K
become の設計の核心は「SSH接続ユーザーと権限昇格を分離し、タスク単位で必要最小限の昇格だけを許可する」ことです。sudoers の設定を絞り込み、パスワードが必要な場合は Vault で暗号化する習慣を付けることで、自動化の効率とセキュリティを両立できます。

Ansible Vault を使った秘密情報の管理については、「Ansible Vaultでシークレットを安全に管理する方法」の記事も合わせて参考にしてください。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、20年以上の運用経験を持つ現役エンジニアが基礎から教えます。
Ansible実践ハンズオンの詳細を見る >>

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。