O Ansible tem que compartilhar a chave raiz entre os nós e o servidor de playbooks Ansible?

Question

Como título, parece não ser seguro rodar tudo no root, especialmente quando o servidor de playbook é hackeado e ele pode ssh em qualquer máquina na lista de hosts Ansible, qual é a solução para esse problema de segurança?

    

Answer 1

Eu crio um usuário especificamente para o uso de ansible, que pode usar sudo sem senha, mas que não tem senha definida e requer uma chave ssh para fazer o login. Desta forma, a conta é privilegiada, mas não é acessível remotamente sem a chave ssh.

Como alternativa, você pode criar uma conta ansible com uma senha e exigir a senha sudo toda vez que você executar ansible.

Você pode criar um usuário assim:

# 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

Adapte-o conforme necessário ao processo que você usar para exibir novas instâncias do servidor (kickstart, preseed, cloud-init, o que for).

Eu configurei ansible.cfg para o sudo sem senha:

[defaults]
remote_user = ansible

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

Se você deseja exigir uma senha sudo para executar os manuais, basta definir become_ask_pass = True em ansible.cfg e não criar /etc/sudoers.d/ansible conforme mostrado acima.

    

Answer 2

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

Não há nenhuma solução para esse problema de segurança.

Se a máquina que está executando os livros didáticos estiver comprometida, os servidores gerenciados por essa máquina também devem ser considerados comprometidos.

Reformulação: a máquina que executa os playbooks Ansible deve atender aos requisitos de segurança dos próprios servidores.

Isso se aplica a qualquer máquina usada para administrar os servidores.

Se uma estação de trabalho usada para fins administrativos for comprometida , qualquer programa executado nessa estação de trabalho e conectado a um servidor com credenciais legítimas poderá ser substituído por um malicioso.

E esse código malicioso pode fazer qualquer coisa ao servidor administrado usando as credenciais fornecidas "de boa fé".

Além disso, o uso do Ansible apresenta riscos adicionais como:

1. o código Ansible em si é comumente mantido no espaço do usuário (digamos pip install ansible usando uma conta normal ou um env virtual) - para um invasor pode não ser necessário obter permissões elevadas na estação de trabalho para altere o código Ansible para executar código arbitrário de forma furtiva (porque nenhum administrador verifica o código do Ansible Python toda vez que ele executa Ansible).

2. Os comandos que exigem permissões elevadas executadas pelo Ansible não podem ser explicitamente especificados no sudoers nos servidores administrados (ou seja, o Ansible exige que os comandos ALL estejam habilitados).

A segurança de um sistema que consiste em um servidor e estação de trabalho administrativa é tão alta quanto o nível de segurança do link mais fraco.