4

As title, it seems not safe to run everything on root, especially when playbook server get hacked and it could ssh into any machines on the Ansible host list, what's the solution for this security problem?

1
  • What is "Ansible playbook server"?
    – techraf
    Nov 11, 2017 at 7:43

2 Answers 2

8

I create a user specifically for the use of ansible, which can use passwordless sudo, but which has no defined password and requires an ssh key to login. In this way, the account is privileged but it is not accessible remotely without the ssh key.

Alternately, you can create the ansible account with a password, and require the sudo password each time you run ansible.

You can create such a user like this:

# Create user
adduser ansible

# Lock password preventing password login (optional)
passwd -l ansible

# Expire any existing password, preventing password login (optional)
chage -E 0 ansible

# Ensure ansible can sudo without a password (optional)
echo "ansible ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/ansible

# Create ansible's .ssh directory
mkdir -m 700 /home/ansible/.ssh

# Insert your desired SSH keys here
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIB7/BSV84tCEQ8SSwygqjEVPFcH+G2JSFEdyuJI7A2iG [email protected]" > /home/ansible/.ssh/authorized_keys

# Correct ownership of newly created files and directories
chown -R ansible.ansible /home/ansible/.ssh

Adapt this as necessary to whatever process you use to bring up new server instances (kickstart, preseed, cloud-init, whatever).

I then set up ansible.cfg for passwordless sudo:

[defaults]
remote_user = ansible

[privilege_escalation]
become = True
become_method = sudo
become_user = root
become_ask_pass = False

If you wish to require a sudo password to run playbooks, you can simply set become_ask_pass = True in ansible.cfg, and do not create /etc/sudoers.d/ansible as shown above.

5
  • Whatever OP means by "Ansible playbook server", the question is about security implications of a potential compromise of the machine executing Ansible playbooks. This answer does not even remotely address this problem. It describes standard, minimal measures for ensuring privilege elevation is not fatally broken on the target server itself.
    – techraf
    Nov 12, 2017 at 12:47
  • @techraf The OP doesn't know what his own question is about? I'm not following this. Nov 12, 2017 at 18:20
  • OP uses non-existent term “playbook server” which can mean either a workstation that administrator executes Ansible code on, or an Ansible Tower (or some other scheduler). Either way it’s non-standard vocabulary. Are you “following this” now? Or otherwise, please explain what is the “Ansible playbook server” and how this answer relates to it.
    – techraf
    Nov 12, 2017 at 21:17
  • @techraf He is plainly, albeit in poor English, referring to the machine on which the playbooks are executed. Nov 12, 2017 at 21:26
  • I wrote “the machine executing playbooks” and you responded with”I am not following this”, now you say OP in poor English refers to the machine on which the playbooks are executed. It’s the same. I think I am following this. You have nothing to say in response to the comment that this answer is misguided and basically worthless, so you tried to mock the comment. In an equally unskillful way as writing the answer itself. To name it properly: a bad and dangerous answer leaving novice users with a conviction that they might be somehow secure by applying NOPASSWD:ALL in sudoers.
    – techraf
    Nov 12, 2017 at 21:30
4

[ ] when playbook server get hacked and it could ssh into any machines on the Ansible host list, what's the solution for this security problem?

There is no solution to this security problem.

If the machine executing playbooks is compromised, servers managed by this machine should be considered compromised too.

Rephrasing: machine executing Ansible playbooks must fulfill security requirements of the servers themselves.


This applies to any machine used for administering the servers.

If a workstation used for administrative purposes is compromised, any program executed on that workstation and connecting to a server with a legitimate credentials can be replaced with a malicious one.

And that malicious code can do anything to the administered server using those credentials supplied "in good faith".

Moreover, using Ansible poses additional risks as:

  1. the Ansible code itself is commonly maintained in the userspace (say pip install ansible using a regular account, or a virtual env) -- for an attacker it might not even be necessary to gain elevated permissions on the workstation to change Ansible code to execute arbitrary code in a stealth way (because no administrator verifies Ansible Python's code every time it executes Ansible).

  2. Commands requiring elevated permissions executed by Ansible cannot be explicitly specified in the sudoers on the administered servers (i.e. Ansible requires ALL commands to be enabled).


The security of a system consisting of a server and administrative workstation is only as high as the security level of the weakest link.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .