<p>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 <a href="https://docs.ansible.com/ansible/latest/user_guide/vault.html" rel="nofollow noreferrer">Ansible Vault</a> to encrypt sensitive files. But that's by no means the only way.</p>

<p>As for deploying, you can use <a href="https://docs.ansible.com/ansible/latest/cli/ansible-pull.html" rel="nofollow noreferrer">ansible-pull</a>, which runs on the machine you want to set up:</p>

<p><code>ansible-pull -U &lt;repository&gt; [options] [&lt;playbook.yml&gt;]</code></p>

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

<p>That should meat your requirements, but it also means that the machine executing <code>ansible-pull</code> 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.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 4.0
2019-02-11T16:06:55.123Z
2019-02-11T16:06:55.123Z
bgdnlp
<p>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.</p>

<p>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).</p>

<p>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.</p>

<p>This is just an example: You don't <em>need</em> 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. </p>

CC BY-SA 4.0
2019-01-27T13:17:44.850Z
Perhaps you could also mention terraform
030
CC BY-SA 4.0
2019-01-27T20:25:12.667Z
@030, done.....
AnoE
CC BY-SA 4.0
2019-01-27T23:42:47.757Z
Thanks for the answer, interesting stuff. Would it be possible to set up the control VM using Ansible too? As in having a playbook to set up the VM, where you then run all your other playbooks from? Or is there a reason people use Vagrant, Terraform, etc?
rubberband876
CC BY-SA 4.0
2019-01-28T04:48:52.820Z
@rubberband876 yes, I do this and run my control machine on aws
jdog
CC BY-SA 4.0
2019-01-28T12:51:06.927Z
@rubberband876: Of course you can set up your Ansible control machine with Ansible; I thought you wanted to solve the problem of setting up a machine to run Ansible, in the first place. If you set up your Ansible with Ansible, then you also would need to setup your Ansible-Ansible-runner with Ansible to run Ansible to set up your actual machines... :-) People use Vagrant/Terraform as a first step to set up something which needs no "prior" setup (those VMs appear out of "thin air" without any requirements whatsoever, totally separate from the host computer).
AnoE
CC BY-SA 4.0
2019-01-28T21:06:01.287Z
Ah I think I understand. Ansible can't create VM itself, it has to connect to an existing one via SSH. Whereas with Vagrant it can actually deploy a raw image from scratch and set it up. Is that correct?
rubberband876
CC BY-SA 4.0
2019-01-28T21:26:06.177Z
@rubberband876: Yes, that is correct.
AnoE
CC BY-SA 4.0
2019-01-28T21:33:09.503Z
Thanks @AnoE, this has been very helpful. What do you think of my idea of using GitLab CI for running Ansible? I feel as though that has severe security problems, since compromising my GitLab account would then give an attacker access to all of my servers. What about for self-hosted GitLab?
rubberband876
CC BY-SA 4.0
2019-01-28T23:12:07.453Z
@rubberband876: well, that's the crux - if you don't trust your cloud/platform provider, then you're pretty much out of luck, especially with a "push-type" ansible deployment. But better open a new question for that, I haven't used Ansible out of Gitlab CI, so don't know if there a good option to handle the secrets in a manner to protect them from someone taking over your Gitlab account.
AnoE
CC BY-SA 4.0
2019-01-26T23:04:59.583Z
2019-01-27T20:24:27.987Z
2019-01-27T20:24:27.987Z
AnoE
<p>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.</p>

<p>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.</p>

<p>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.</p>

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

<ansible>
How can I eliminate the need for an Ansible control machine?
rubberband876
# How can I eliminate the need for an Ansible control machine?

(Asked by: username_0 on 2019-01-26)

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?

**Tags:** ansible


---

## 2 answers

### Answer by username_2 on 2019-01-26. Score: 5 | Accepted answer

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.

> **Comments:**
> **username_3**: Perhaps you could also mention terraform  
> **username_2**: @username_3, done.....  
> **username_0**: Thanks for the answer, interesting stuff. Would it be possible to set up the control VM using Ansible too? As in having a playbook to set up the VM, where you then run all your other playbooks from? Or is there a reason people use Vagrant, Terraform, etc?  
> **username_4**: @username_0 yes, I do this and run my control machine on aws  
> **username_2**: @username_0: Of course you can set up your Ansible control machine with Ansible; I thought you wanted to solve the problem of setting up a machine to run Ansible, in the first place. If you set up your Ansible with Ansible, then you also would need to setup your Ansible-Ansible-runner with Ansible to run Ansible to set up your actual machines... :-) People use Vagrant/Terraform as a first step to set up something which needs no "prior" setup (those VMs appear out of "thin air" without any requirements whatsoever, totally separate from the host computer).  
> **username_0**: Ah I think I understand. Ansible can't create VM itself, it has to connect to an existing one via SSH. Whereas with Vagrant it can actually deploy a raw image from scratch and set it up. Is that correct?  
> **username_2**: @username_0: Yes, that is correct.  
> **username_0**: Thanks @username_2, this has been very helpful. What do you think of my idea of using GitLab CI for running Ansible? I feel as though that has severe security problems, since compromising my GitLab account would then give an attacker access to all of my servers. What about for self-hosted GitLab?  
> **username_2**: @username_0: well, that's the crux - if you don't trust your cloud/platform provider, then you're pretty much out of luck, especially with a "push-type" ansible deployment. But better open a new question for that, I haven't used Ansible out of Gitlab CI, so don't know if there a good option to handle the secrets in a manner to protect them from someone taking over your Gitlab account.  

---

### Answer by username_1 on 2019-02-11. Score: 1

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](https://docs.ansible.com/ansible/latest/user_guide/vault.html) to encrypt sensitive files. But that's by no means the only way.

As for deploying, you can use [ansible-pull](https://docs.ansible.com/ansible/latest/cli/ansible-pull.html), which runs on the machine you want to set up:

`ansible-pull -U  [options] []`

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.


---

