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 Playbooknstrate 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'.
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.
Academy
Learn the Ansible automation technology with some real-life examples in my
Udemy 300+ Lessons Video Course.
My book Ansible By Examples: 200+ Automation Examples For Linux and Windows System Administrator and DevOps
Donate
Want to keep this project going? Please donate