New in version 2.8.
Become plugins work to ensure that Ansible can use certain privilege escalation systems when running the basic commands to work with the target machine as well as the modules required to execute the tasks specified in the play.
These utilities (
doas, etc) generally let you ‘become’ another user to execute a command
with the permissions of that user.
The become plugins shipped with Ansible are already enabled. Custom plugins can be added by placing
them into a
become_plugins directory adjacent to your play, inside a role, or by placing them in one of
the become plugin directory sources configured in ansible.cfg.
In addition to the default configuration settings in Ansible Configuration Settings or the
--become-method command line option, you can use the
become_method keyword in a play or, if you need
to be ‘host specific’, the connection variable
ansible_become_method to select the plugin to use.
You can further control the settings for each plugin via other configuration options detailed in the plugin themselves (linked below).
You can use
ansible-doc -t become -l to see the list of available plugins.
ansible-doc -t become <plugin name> to see specific documentation and examples.
- doas – Do As user
- dzdo – Centrify’s Direct Authorize
- enable – Switch to elevated permissions on a network device
- ksu – Kerberos substitute user
- machinectl – Systemd’s machinectl privilege escalation
- pbrun – PowerBroker run
- pfexec – profile based execution
- pmrun – Privilege Manager run
- runas – Run As user
- sesu – CA Privileged Access Manager
- su – Substitute User
- sudo – Substitute User DO
- Working With Playbooks
An introduction to playbooks
- Inventory Plugins
Ansible inventory plugins
- Callback Plugins
Ansible callback plugins
Jinja2 filter plugins
Jinja2 test plugins
Jinja2 lookup plugins
- User Mailing List
Have a question? Stop by the google group!
#ansible IRC chat channel