![]() What happens when we run this playbook? The Ansible user has rights to run dnf and systemctl commands, so it should work, right? Unfortunately not: ~] ansible-playbook -i target, manage_system.yml name: Try and start the myapp service via systemctl name: Try and install telnet using the dnf module, use become true name: Try and install telnet using the dnf module, regular user # Attempt to install the telnet package using the DNF module We’ll now defined following playbook to attempt to install a software package and start a service. On the Ansible target we set the following sudo rules for our Ansible user: ansibleĚLL=(ALL) NOPASSWD: /bin/dnf install *, /usr/bin/systemctl start rvice We have the user ‘ansible’ on our Ansible control host and setup SSH equivalence with our target. Given the above, we might naturally think we can apply those same sudo rules to our Ansible user and simply use the ‘become’ directive where we need to in our playbook. Only switch to an privileged user where necessary. The idea is that where you can always use the least privileged account to achieve a task. If you’re comfortable with Ansible, you’ll have heard of the become, become_user and become_method directives in playbook. A typical sudoers file might look like this: appuserĚLL=(ALL) NOPASSWD: /bin/dnf install *, /usr/bin/systemctl start rvice Let’s say an application team has rights to start and stop their own applications via systemd, they can install package via DNF and they can edit certain system files. The most common way of doing this is via SUDO. In such an environment, it’s not unusual to separate out roles and use privilege escalation to allow teams to perform ‘root’ level privileges where they need to. A server O/S team may well build and administer servers, a application team may deploy and manage applications whilst developers focus on application enhancements. The enterprise IT environment may well consist of different teams focusing on different parts of the estate. ![]() As with any new tool, everyone soon learns of it’s power and wants to take advantage of it. The thousands of modules that are available, comprehensive documentation and low barrier of entry have seen it rise to prominence in the enterprise. Ansible is a fantastic tool for automating your environment. ![]() Within an enterprise environment, you’re likely to be using custom sudo rules in /etc/sudoers to control the security of your users and applications.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |