Ansible troubleshooting - Error 501: partial-become

Introduction

When working with Ansible, it's essential to ensure that privilege escalation is managed effectively, especially when changing users. Ansible provides the become directive for this purpose, which allows you to execute actions as a different user, typically a superuser like root. However, Rule 501, known as "partial-become" in Ansible Lint, emphasizes the importance of using this privilege escalation mechanism consistently and explicitly.

See also: Ansible troubleshooting - Error 102: No Jinja2 in 'when' Conditions

The Purpose of Rule 501

Rule 501, "partial-become," checks whether privilege escalation is properly activated when changing users in Ansible playbooks and tasks. To execute a task as a different user using the become_user directive, you must explicitly set become: true to ensure it works as expected.

This rule aims to make your Ansible playbooks more robust and predictable by ensuring that privilege escalation is consistently and explicitly defined at the appropriate levels, specifically the task or play level. By doing so, it minimizes the risk of errors and accidents when tasks are moved from one location to another, enhancing the reliability of your automation workflows.

Common Scenarios

Let's explore some common scenarios that Playbooknstrate how this rule works and what to do when privilege escalation is necessary.

See also: Ansible troubleshooting - Error 104: Deprecated Bare Vars

Problematic Scenario

---
- name: Example playbook
  hosts: all
  become: true # <- Activates privilege escalation.
  tasks:
    - name: Start the httpd service as the apache user
      ansible.builtin.service:
        name: httpd
        state: started
      become_user: apache # <- Does not change the user because "become: true" is not set.

In this scenario, privilege escalation is partially implemented. The become directive is correctly set to true, but the become_user directive is used without the former. This means that the user change does not take effect, making this implementation inconsistent and potentially erroneous.

Output:

WARNING  Listing 1 violation(s) that are fatal
partial-become[task]: ``become_user`` should have a corresponding ``become`` at the play or task level.
501.yml:6 Task/Handler: Start the httpd service as the apache user
Read documentation for instructions on how to ignore specific rule violations.
Rule Violation Summary                  
 count tag                  profile rule associated tags 
     1 partial-become[task] basic   unpredictability
Failed: 1 failure(s), 0 warning(s) on 1 files. Last profile that met the validation criteria was 'min'.

Corrected Scenario

---
- name: Example playbook
  hosts: all
  tasks:
    - name: Start the httpd service as the apache user
      ansible.builtin.service:
        name: httpd
        state: started
      become: true # <- Activates privilege escalation.
      become_user: apache # <- Changes the user with the desired privileges.

In this corrected scenario, privilege escalation is applied consistently and correctly. The become directive is explicitly set to true, ensuring that the become_user directive changes the user as intended.

Play-Level Implementation

To apply privilege escalation consistently across an entire playbook at the play level, you can use the following approach:

- name: Example playbook
  hosts: localhost
  become: true # <- Activates privilege escalation.
  become_user: apache # <- Changes the user with the desired privileges.
  tasks:
    - name: Start the httpd service as the apache user
      ansible.builtin.service:
        name: httpd
        state: started

See also: Ansible troubleshooting - Error 105: Deprecated Module Usage

Conclusion

Ansible Rule 501, "partial-become," is a valuable guideline that ensures privilege escalation is consistently and explicitly implemented when changing users. By adhering to this rule, you can prevent errors and enhance the predictability of your Ansible automation, leading to more reliable and secure infrastructure management. Consistency is key in ensuring that your Ansible playbooks perform as expected, and Rule 501 helps you achieve that.

Related Articles

• when expressions and Jinja2 in Ansible • become and privilege escalation explained • idempotent restarts via Ansible handlers