Many teams run Ansible plays from their laptops. In practice this just works, but this doesn’t mean that it’s an ideal way of using Ansible. Instead, we suggest to run it inside a dedicated host. In this article you’ll find some good reason for that.
ansible-playbook usually applies a playbook to remote hosts by running commands via SSH. In order to run it from your laptop, you need SSH access to all those hosts. The reason why we don’t think this is ideal depends wether you use a VPN or not.
If you use a VPN, you probably should not blindly trust all your VPN users, for several reasons:
- Social engineering is the most effective way to attack organisation systems. It consists in convincing a person to give the attacker a regular access to sensible resources. Expert social engineers gain access to VPNs as a normal part of their job.
- Cyberattacks sometimes come from organisation members. They could be paid by a competitor or they may be angry with their boss.
- Former members of an organisation could still have their accesses. The reason could be the lack of proper processes, a human mistake or an automation bug. But what matters here is that this problem is quite common.
- Laptops can be stolen, and accesses can be used before proper action is taken to avoid an attack.
If you don’t use a VPN, your bastions are exposed to the world. Hopefully they are properly protected, but this doesn’t mean in any way that an attacker can’t break into them.
In all cases, running Ansible from each laptop implies to give each laptop a dedicated SSH access on all target servers. If Ansible only runs from a dedicated host, it is possible to only have one access. In practice having at least two hosts is better, in case a disaster destroys the first Ansible host and we urgently need to deploy. Still, a small, fixed number of accesses is much manageable.
Auditing is a security matter, and can also be required by applicable law or company policy.
Auditing some components of an infrastructure is fairly common. For example, the queries to databases are often logged. But from a practical perspective, it may be hard to find our why a specific query was run or an API call was made. Logging high level actions can help investigate what happened.
For this reason, it may be a good idea to log ansible-playbook invocations. This can be done by adding some simple audit code to a wrapper script (see next paragraph).
What happens if two persons run playbooks against the same target servers at the same time? It greatly depends on which task those playbooks run, and in which order. Hopefully, nothing bad will happen. But target servers could also be left down, in an inconsistent state. You may have to fix the problem manually.
Running Ansible from a dedicated host makes it easy to implement a lock. You will make a script that looks like the following pseudocode:
foreach $target_host_list as $host: try: locked.push($host) touch "$host.LOCK" catch: foreach $locked: rm -f "$locker.LOCK" abort -- pass all arguments to ansible-playbook ansible-playbook $@ foreach $target_host_list as $host: rm -f "$host.LOCK"
Less environments to manage
If you run Ansible from one host, or from a small number of hosts, you will have just a few environments to manage. The most competent person will take care of upgrading Ansible when needed, or the system it runs on. Leaving this to each member of the team means to increase the chances that problems arise, making them unable to deploy.
Also people could forget to pull from the playbooks repository. Or they could remember it, but still choose not to do so for many reasons: laziness, avoiding a specific problem… but this is hardly a good idea, and you want to avoid it. If you run Ansible from a single host, you can somehow automatically trigger a
git pull every time a commit is made on the master branch. Or you can add
git pull to the above script.
We discussed some reasons why Ansible should run from a dedicated host, rather than all devops laptops.