Solución de errores de escalada de privilegios de Ansible usando Become y Sudo

Ansible es un potente motor de automatización que agiliza la gestión de la configuración, el despliegue de aplicaciones y la orquestación de tareas en una flota de servidores. Sin embargo, uno de los obstáculos más comunes que enfrentan tanto los usuarios nuevos como los experimentados es lidiar con los errores de escalada de privilegios. Estos problemas a menudo se manifiestan como mensajes de "permiso denegado" cuando Ansible intenta realizar acciones que requieren derechos elevados, como instalar paquetes, modificar archivos del sistema o administrar servicios.

Esta guía completa le mostrará las complejidades del mecanismo become de Ansible, cómo se integra con sudo para la escalada de privilegios y le proporcionará pasos prácticos para diagnosticar y resolver problemas de autenticación relacionados. Al comprender y configurar correctamente estos ajustes, puede asegurarse de que sus playbooks de Ansible se ejecuten sin problemas y de forma segura, independientemente de los requisitos de acceso del sistema de destino.

Comprensión del mecanismo become de Ansible

En esencia, Ansible opera conectándose a hosts de destino, normalmente a través de SSH, y ejecutando comandos como el usuario remoto. Sin embargo, muchas tareas administrativas requieren privilegios elevados (por ejemplo, acceso root en sistemas Linux). Aquí es donde entra en juego la característica become de Ansible. El mecanismo become permite a Ansible "convertirse" en otro usuario, generalmente root, para ejecutar tareas específicas o plays completos con permisos elevados.

Por qué es necesario become

Ejecutar todas las tareas de Ansible directamente como usuario root es generalmente una mala práctica de seguridad. En su lugar, normalmente se conecta a sus hosts remotos como un usuario normal sin privilegios (a menudo denominado ansible_user) y luego utiliza become para escalar temporalmente los privilegios de las tareas que los requieren. Esto se adhiere al principio del menor privilegio, minimizando el impacto potencial de una brecha de seguridad.

Métodos de become

Ansible admite varios métodos para la escalada de privilegios, cada uno correspondiente a diferentes utilidades del sistema. El método más común y ampliamente utilizado, especialmente en sistemas Linux/Unix, es sudo (Substitute User Do). Otros métodos incluyen su, pbrun, doas y más, pero esta guía se centrará principalmente en sudo debido a su prevalencia.

Configuración de los ajustes de become en Ansible

Ansible ofrece varias formas de configurar los ajustes de become, desde configuraciones globales hasta anulaciones específicas de tareas. Comprender estos alcances es crucial para una gestión eficaz de los privilegios.

1. Configuración global en ansible.cfg

Para casos de uso generales en muchos playbooks, puede establecer parámetros predeterminados de become en su archivo ansible.cfg. Este se encuentra típicamente en el directorio desde donde ejecuta Ansible, ~/.ansible.cfg, o /etc/ansible/ansible.cfg.

# ansible.cfg
[privilege_escalation]
become=True
become_method=sudo
become_user=root
become_ask_pass=False ; Establezca en True si desea que Ansible solicite la contraseña

• become=True: Habilita la escalada de privilegios por defecto para todos los plays.
• become_method=sudo: Especifica sudo como el método para la escalada de privilegios.
• become_user=root: Especifica root como el usuario de destino al que convertirse.
• become_ask_pass=False: Controla si Ansible debe solicitar la contraseña de become. Establézcalo en True si no proporciona la contraseña por otros medios.

2. Por Play o por Tarea en Playbooks

Para un control más granular, los ajustes de become se pueden definir directamente dentro de sus playbooks, ya sea a nivel de play (afectando a todas las tareas de ese play) o a nivel de tarea individual.

Configuración a nivel de Play:

---
- name: Instalar Nginx con privilegios elevados
  hosts: webservers
  become: yes          # Habilitar become para todas las tareas en este play
  become_user: root
  become_method: sudo

  tasks:
    - name: Asegurar que Nginx esté instalado
      ansible.builtin.apt:
        name: nginx
        state: present
      # Esta tarea se ejecutará como root a través de sudo

    - name: Copiar configuración de Nginx
      ansible.builtin.copy:
        src: nginx.conf
        dest: /etc/nginx/nginx.conf
      # Esta tarea también se ejecutará como root a través de sudo

Configuración a nivel de Tarea:

---
- name: Administrar archivos como diferentes usuarios
  hosts: all

  tasks:
    - name: Crear un archivo propiedad de ansible_user (por defecto)
      ansible.builtin.file:
        path: /tmp/unprivileged_file.txt
        state: touch
        mode: '0644'

    - name: Crear un archivo propiedad de root usando become
      ansible.builtin.file:
        path: /root/privileged_file.txt
        state: touch
        mode: '0600'
      become: yes          # Solo esta tarea usará become
      become_user: root
      become_method: sudo

3. A través de variables de inventario

Los ajustes de become también se pueden definir en su inventario de Ansible, lo que le permite especificar diferentes estrategias de escalada de privilegios para diferentes hosts o grupos.

Ejemplo de hosts.ini:

[webservers]
web1.example.com
web2.example.com

[dbservers]
db1.example.com

[all:vars]
ansible_user=devops_user
ansible_become=true
ansible_become_method=sudo
ansible_become_user=root

Aquí, ansible_become, ansible_become_method y ansible_become_user son variables de inventario que corresponden a los ajustes de become. Se pueden establecer a nivel de all:vars, a nivel de grupo o a nivel de host.

4. Usando argumentos de línea de comandos de ansible-playbook

Para anulaciones rápidas o ejecución interactiva, puede pasar parámetros de become directamente a través de la línea de comandos:

• --become o -b: Activa become.
• --become-method <METHOD>: Especifica el método de become (ej. sudo).
• --become-user <USER>: Especifica el usuario de destino (ej. root).
• --ask-become-pass o -K: Solicita la contraseña de become durante la ejecución. Esto es útil para pruebas pero generalmente no para la automatización.

Ejemplo:

ansible-playbook my_playbook.yml --become --become-user root --ask-become-pass

Asegurar derechos de sudo para el usuario become

Configurar correctamente become en Ansible es solo la mitad de la batalla. El usuario con el que se conecta Ansible (el ansible_user) debe tener los privilegios de sudo necesarios en el host de destino para convertirse en el become_user. Esto se configura en el host de destino dentro del archivo /etc/sudoers o un archivo bajo /etc/sudoers.d/.

Configuración de sudoers

El archivo sudoers define quién puede ejecutar qué comandos y como quién. Una entrada común para permitir que un usuario de conexión de Ansible (devops_user en este ejemplo) ejecute cualquier comando como cualquier usuario sin solicitud de contraseña es:

# /etc/sudoers.d/devops
devops_user ALL=(ALL) NOPASSWD: ALL

Explicación:

• devops_user: El nombre de usuario con el que se conecta Ansible (ansible_user).
• ALL: Este usuario puede ejecutar comandos desde cualquier terminal.
• (ALL): Este usuario puede ejecutar comandos como cualquier usuario.
• NOPASSWD:: Especifica que no se requiere contraseña para las operaciones de sudo.
• ALL: Este usuario puede ejecutar todos los comandos.

Advertencia: Otorgar NOPASSWD: ALL le da al ansible_user acceso root sin restricciones y sin contraseña, lo que puede ser un riesgo de seguridad significativo. Úselo solo si es verdaderamente necesario y asegúrese de que las credenciales de su ansible_user sean altamente seguras. Para una seguridad más estricta, puede especificar comandos exactos o conjuntos de comandos que al usuario se le permite ejecutar.

Verificación del acceso a sudo

Antes de ejecutar su playbook, puede verificar manualmente si su ansible_user tiene acceso a sudo en un host de destino. Inicie sesión por SSH en el host como el ansible_user y ejecute:

# Comprobar si puede usar sudo a root sin contraseña
sudo -n whoami

# Si se requiere una contraseña, se le solicitará. Pruebe con un comando simple:
sudo whoami

# Listar privilegios de sudo para el usuario actual:
sudo -l

# Listar privilegios de sudo para un usuario específico (ej. devops_user):
sudo -l -U devops_user

Si sudo -n whoami devuelve root sin solicitar contraseña, es probable que su configuración de NOPASSWD sea correcta. Si solicita una contraseña, es posible que a su entrada de sudoers le falte NOPASSWD o esté configurada incorrectamente.

Diagnóstico de errores de escalada de privilegios

Ansible generalmente proporciona mensajes de error informativos, pero los problemas relacionados con los privilegios a veces pueden ser crípticos. Aquí hay errores comunes y sus soluciones:

1. "permiso denegado" o