-2

So Ansible is the BIG thing at the moment, along with other configuration management solutions like Puppet, SaltStack and so on. At my company we are managing 500+ servers and some guys are implementing an Ansible solution to minimise the configuration management overhead.

Paranoid as I am, I started thinking about what can actually be done from an Ansible server if someone is not in their right mind.

I have searched online looking for best practices, for security hardening on Ansible servers and mostly I find articles of how Ansible can be used to harden other servers (obviously) and also I find general recommendations of how to harden a Linux server, since Ansible runs on Linux. So that got me thinking that the overall idea of having a centralised configuration management server comes with some risks; wouldn't I, as a hacker or disgruntled employee, be able to run the command rm -rf / on all servers or similar using the Ansible server?

As a rule of thumb I would suppose that having a segmented network where test, dev, pre-prod, and prod are all unavailable to each other would mean that you would AT LEAST have an Ansible server installed for each of these environments, so you don't have a server where firewall allows access to all systems. I guess that's common sense at least.

However still, the idea of a server that can configure an ENTIRE NETWORK of servers is insane if you think about someone who's not supposed to, getting access to the Ansible server.

Would one create some kind of MFA that kicks in before commands are run, or would the Ansible server be unable to create its own playbooks, and then the playbooks are mounted from a readonly server elsewhere, so the possibilities of post exploitation at least require you to control more than just the Ansible server?

Do we put the Ansible server on a locked-the-f-down management network that is difficult for even employees to access with MFA, special access requirements, no VPN, only onsite access, and so on?

Or do we accept the risk and keep good backups and protect the network properly and accept that if the Ansible server is compromised, destruction could be imminent?

Or am I totally wrong about the destructive capabilities of Ansible?

2

Security for your networks is your choice. Segmentation and authentication can make a lot of sense. And you have a business continuity plan to restore services if anything bad happens, right?

Fundamentally this is about trust of people. Someone has to push changes out. If that person is an administrator to do their job, they can do a lot of damage by accident or malice.

Ansible is not necessarily centralized. A common pattern is to check out a playbook from source control and run it from any host. It could be centralized if you want: run plays from a management host. And, Ansible Tower provides a central interface to run things from.

Consider how you deploy to hosts. Ansible is capable of connecting as a personal user, and switching users with become as required. This will only work if your become method allows it on that host. Probably sudo, but could be something else. Presumably, you can audit authentication and lock out unauthorized users if you wish to do so. Much like you would without automation.

  • Thanks for the perspective. I dont see you are disagreeing with the destructive capabilities of such a tool tinfoil hat on. I wonder if the playbooks could be readonly in a sense that... see what I'm looking for is a method that strips playbooks of bad commands - which cant be easily changed - like input in textboxes is stripped to prevent sql injection and xss. – Raker Sep 9 '17 at 15:47
  • A tool is not harmful in itself, it is merely used for a purpose. rm can both clean things up nicely, or remove the entire system accidentally. Some discipline in reviewing and testing plays before they are used in production helps. Tower provides one way of giving users pre-defined tasks, but those tasks still need to be written and tested to be known safe. – John Mahowald Sep 9 '17 at 22:19
  • I agree on that. In essence would it be possible to create a policy or roleset that will result in that the ones who create the playbooks cant execute them and vice versa? I guess this could force two people to be involved whenever a new playbook is created and executed. Like you prevent those toxic rolecombinations. – Raker Sep 9 '17 at 22:22
  • Decide how you want to separate these roles, then implement it. In the most basic example, a developer could write a play to deploy their app, but have no login to production hosts. If you want more point-and-click role based access, look at Ansible Tower. – John Mahowald Sep 17 '17 at 16:33
  • Interesting. Do you know of any documentation on recommended best practices, considering separation of roles? – Raker Sep 17 '17 at 16:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.