Does Ansible have to share root key between nodes and Ansible playbook server?

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.

[ ] 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.