How can I eliminate the need for an Ansible control machine?

Question

Ansible is great for deploying infrastructure, but it requires you to have a control machine. This adds the burden of manually setting it up and securing it, and then pulling down your playbooks and making connections out to your servers.

I would like a way to run my playbooks 'in the cloud' rather than on my own system. I am aware the commercial offering Ansible Tower, however as far as I can see this is not suitable for personal use.

One option is to run them using a hosted CI tool such as Travis-CI or Gitlab CI, however this feels wrong from a security point of view, as somebody who gained access to my Travis/GitLab accounts would then have access to all of my servers.

Which solutions are out there that meet this requirement? Does my GitLab CI proposal have severe security problems or is it an accepted solution?

Answer 1

The solution is to automate setting up the control machine, i.e., the VM. You can use, for example, Vagrant, Terraform or similar tools (I'll stick with Vagrant in this answer for this example, it's about the principle). With that approach, the VM is wholly defined by a text file ("Vagrantfile"), and can easily and repeatably be created and re-created. The Vagrantfile species a base image, for example some particular Linux distribution; networking etc.; and necessary command lines to set it up, going from there.

You can set up your VM (i.e., install Ansible) by just providing all necessary shell commands. In this particular example, this is probably enough. If you need a more complex VM, you can get kind of recursive, and configure the VM itself by using Ansible (or one of its alternatives).

Obviously, you will want to treat the Vagrantfile the same as your other configurations; i.e., commit it to your SCM and keep it up to date.

This is just an example: You don't need to use Vagrant or a VM; you can also install your Ansible inside a Docker image or whatever your cloud provider of choice provides as containerization.

Answer 2

If you're going to go the infrastructure-as-code way, you're going to want to store that code in a repository. Having your infrastructure definition stored in a VCS (GitLab) has pretty much the same security implications as storing code in GitLab. Just make sure you don't store sensitive data or credentials in plain text, or at all if you can help it. In Ansible's case, that usually means using Ansible Vault to encrypt sensitive files. But that's by no means the only way.

As for deploying, you can use ansible-pull, which runs on the machine you want to set up:

ansible-pull -U <repository> [options] [<playbook.yml>]

It will get the Ansible config from the specified repository to local host, then executes the playbook you tell it to.

That should meat your requirements, but it also means that the machine executing ansible-pull will have access to everything that is in that repository. Whether that is secure enough for your environment or not is up to you. You can split your Ansible config in several repositories, use different branches, revoke the machine's access after the initial pull, etc.

In general, encrypt sensitive data in the repository (encryption on disk), make sure you pull over SSH or HTTPS (encryption in flight), and be mindful of who has access to the repository, even indirectly (access/user management), and you've gone a long way towards having a decently secure environment.

Whether using CI to deploy Ansible is secure enough or not, that's debatable. One could argue that someone who gains (write) access to the Travis/GitLab account where you keep your Ansible playbooks already got access to your infrastructure since they can alter those playbooks, it's just a matter of time. On the other hand, code stored in repository is half the point of infrastructure-as-code. YMMV.