Ansible troubleshooting - Error 501: partial-become

How to Solve the Ansible Error 501 partial-become

November 2, 2023

Access the Complete Video Course and Learn Quick Ansible by 200+ Practical Lessons

#ansible-error #ansible-best-practices #ansible-playbook #ansible-troubleshooting #automation #infrastructure-as-code #ansible-linting #ansible-coding #devops #it-automation

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.

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 demonstrate how this rule works and what to do when privilege escalation is necessary.

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'.

The Best Resources For Ansible

Certifications

CYBER DEALS at The Linux Foundation! Up to 65% off, and a FREE GIFT with EVERY PURCHASE! Limited Time, Don't Delay!

Video Course

Udemy: Learn Ansible Automation in 250+examples & practical lessons: Learn Ansible with some real-life examples of how to use the most common modules and Ansible Playbook

Printed Book

eBooks

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

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.

Subscribe to the YouTube channel, Medium, Website, Twitter, and Substack to not miss the next episode of the Ansible Pilot.