Как заголовок, кажется небезопасным запускать все в корневом каталоге, особенно когда сервер playbook взломан и он может подключиться по ssh к любым машинам в списке хостов Ansible, каково решение этой проблемы безопасности?
Я создаю пользователя специально для использования ansible, который может использовать sudo без пароля, но у которого нет определенного пароля и для входа требуется ключ ssh. Таким образом, учетная запись является привилегированной, но недоступна удаленно без ключа ssh.
Кроме того, вы можете создать учетную запись ansible с паролем и запрашивать пароль sudo каждый раз при запуске ansible.
Создать такого пользователя можно так:
# 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 ansible-runner@example.com" > /home/ansible/.ssh/authorized_keys
# Correct ownership of newly created files and directories
chown -R ansible.ansible /home/ansible/.ssh
При необходимости адаптируйте это к любому процессу, который вы используете для запуска новых экземпляров сервера (кикстарт, предварительная установка, cloud-init и т. Д.).
Затем я настроил ansible.cfg для sudo без пароля:
[defaults]
remote_user = ansible
[privilege_escalation]
become = True
become_method = sudo
become_user = root
become_ask_pass = False
Если вы хотите запросить пароль sudo для запуска playbooks, вы можете просто установить become_ask_pass = True в ansible.cfg, и не создавайте /etc/sudoers.d/ansible как показано выше.
[] когда сервер playbook взломан и он может подключиться по ssh к любым машинам в списке хостов Ansible, каково решение этой проблемы безопасности?
Там есть нет решения к этой проблеме безопасности.
Если компьютер, на котором выполняются playbooks, скомпрометирован, серверы, управляемые этим компьютером, также должны считаться скомпрометированными.
Перефразируя: машина, выполняющая сценарии воспроизведения Ansible, должна удовлетворять требованиям безопасности самих серверов.
Это относится к любой машине, используемой для администрирования серверов.
Если рабочая станция, используемая для административных целей скомпрометирован, любая программа, выполняемая на этой рабочей станции и подключающаяся к серверу с легитимными учетными данными, может быть заменена вредоносной.
И этот вредоносный код может делать что угодно с администрируемым сервером, используя эти учетные данные, предоставленные «добросовестно».
Более того, использование Ansible сопряжено с дополнительными рисками:
сам код Ansible обычно поддерживается в пользовательском пространстве (скажем, pip install ansible используя обычную учетную запись или виртуальный env) - злоумышленнику может даже не потребоваться получение повышенных разрешений на рабочей станции для изменения кода Ansible для скрытого выполнения произвольного кода (поскольку ни один администратор не проверяет код Ansible Python каждый раз он выполняет Ansible).
Команды, требующие повышенных разрешений, выполняемые Ansible, не могут быть явно указаны в sudoers на администрируемых серверах (т.е. Ansible требует ALL команды для включения).
Безопасность системы, состоящей из сервера и административной рабочей станции, соответствует уровню безопасности самого слабого звена.