Corrigindo Erros de Escalonamento de Privilégios do Ansible Usando Become e Sudo

Ansible é um poderoso motor de automação que simplifica o gerenciamento de configurações, a implantação de aplicações e a orquestração de tarefas em uma frota de servidores. No entanto, um dos obstáculos mais comuns que usuários novos e experientes enfrentam é lidar com erros de escalonamento de privilégios. Esses problemas frequentemente se manifestam como mensagens de "permissão negada" quando o Ansible tenta realizar ações que exigem direitos elevados, como instalar pacotes, modificar arquivos do sistema ou gerenciar serviços.

Este guia completo irá guiá-lo pelas complexidades do mecanismo become do Ansible, como ele se integra com o sudo para escalonamento de privilégios, e fornecerá passos acionáveis para diagnosticar e resolver problemas de autenticação relacionados. Ao compreender e configurar corretamente essas configurações, você pode garantir que seus playbooks Ansible executem de forma suave e segura, independentemente dos requisitos de acesso do sistema de destino.

Entendendo o Mecanismo become do Ansible

Em sua essência, o Ansible opera conectando-se a hosts de destino, tipicamente via SSH, e executando comandos como o usuário remoto. Muitas tarefas administrativas, entretanto, exigem privilégios elevados (por exemplo, acesso root em sistemas Linux). É aqui que o recurso become do Ansible entra em jogo. O mecanismo become permite que o Ansible "se torne" outro usuário, geralmente root, para executar tarefas específicas ou plays inteiros com permissões elevadas.

Por que become é Necessário

Executar todas as tarefas do Ansible diretamente como o usuário root é geralmente uma má prática de segurança. Em vez disso, você tipicamente se conecta aos seus hosts remotos como um usuário regular, sem privilégios (muitas vezes referido como ansible_user) e então usa become para escalar temporariamente os privilégios para as tarefas que os exigem. Isso adere ao princípio do menor privilégio, minimizando o impacto potencial de uma violação de segurança.

Métodos become

Ansible suporta vários métodos para escalonamento de privilégios, cada um correspondendo a diferentes utilitários de sistema. O método mais comum e amplamente utilizado, especialmente em sistemas Linux/Unix, é sudo (Substitute User Do). Outros métodos incluem su, pbrun, doas e mais, mas este guia focará principalmente em sudo devido à sua prevalência.

Configurando as Definições become no Ansible

Ansible oferece múltiplas maneiras de configurar as definições become, desde configurações globais até overrides específicos de tarefas. Compreender esses escopos é crucial para uma gestão eficaz de privilégios.

1. Configuração Global em ansible.cfg

Para casos de uso gerais em muitos playbooks, você pode definir parâmetros become padrão no seu arquivo ansible.cfg. Este arquivo é tipicamente encontrado no diretório onde você executa o Ansible, ~/.ansible.cfg, ou /etc/ansible/ansible.cfg.

# ansible.cfg
[privilege_escalation]
become=True
become_method=sudo
become_user=root
become_ask_pass=False ; Defina como True se você quiser que o Ansible solicite a senha

• become=True: Habilita o escalonamento de privilégios por padrão para todos os plays.
• become_method=sudo: Especifica sudo como o método para escalonamento de privilégios.
• become_user=root: Especifica root como o usuário de destino a se tornar.
• become_ask_pass=False: Controla se o Ansible deve solicitar a senha become. Defina como True se você não fornecer a senha por outros meios.

2. Por Play ou Por Tarefa em Playbooks

Para um controle mais granular, as definições become podem ser definidas diretamente dentro dos seus playbooks, seja no nível do play (afetando todas as tarefas naquele play) ou no nível da tarefa individual.

Configuração no nível do play:

---
- name: Instalar Nginx com privilégios elevados
  hosts: webservers
  become: yes          # Habilita become para todas as tarefas neste play
  become_user: root
  become_method: sudo

  tasks:
    - name: Garantir que o Nginx esteja instalado
      ansible.builtin.apt:
        name: nginx
        state: present
      # Esta tarefa será executada como root via sudo

    - name: Copiar configuração do Nginx
      ansible.builtin.copy:
        src: nginx.conf
        dest: /etc/nginx/nginx.conf
      # Esta tarefa também será executada como root via sudo

Configuração no nível da tarefa:

---
- name: Gerenciar arquivos como usuários diferentes
  hosts: all

  tasks:
    - name: Criar um arquivo como o ansible_user (padrão)
      ansible.builtin.file:
        path: /tmp/unprivileged_file.txt
        state: touch
        mode: '0644'

    - name: Criar um arquivo de propriedade do root usando become
      ansible.builtin.file:
        path: /root/privileged_file.txt
        state: touch
        mode: '0600'
      become: yes          # Apenas esta tarefa usará become
      become_user: root
      become_method: sudo

3. Via Variáveis de Inventário

As definições become também podem ser definidas no seu inventário Ansible, permitindo que você especifique diferentes estratégias de escalonamento de privilégios para diferentes hosts ou grupos.

Exemplo 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

Aqui, ansible_become, ansible_become_method e ansible_become_user são variáveis de inventário que correspondem às definições become. Elas podem ser definidas no nível all:vars, nível de grupo ou nível de host.

4. Usando Argumentos CLI ansible-playbook

Para overrides rápidos ou execução interativa, você pode passar os parâmetros become diretamente via linha de comando:

• --become ou -b: Ativa become.
• --become-method <METHOD>: Especifica o método become (por exemplo, sudo).
• --become-user <USER>: Especifica o usuário de destino (por exemplo, root).
• --ask-become-pass ou -K: Solicita a senha become durante a execução. Isso é útil para testes, mas geralmente não para automação.

Exemplo:

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

Garantindo Direitos sudo para o Usuário become

Configurar corretamente become no Ansible é apenas metade da batalha. O usuário com o qual o Ansible se conecta (o ansible_user) deve ter os privilégios sudo necessários no host de destino para se tornar o become_user. Isso é configurado no host de destino dentro do arquivo /etc/sudoers ou de um arquivo em /etc/sudoers.d/.

Configurando sudoers

O arquivo sudoers define quem pode executar quais comandos e como quem. Uma entrada comum para permitir que um usuário de conexão Ansible (devops_user neste exemplo) execute qualquer comando como qualquer usuário sem um prompt de senha é:

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

Explicação:

• devops_user: O nome de usuário com o qual o Ansible se conecta (ansible_user).
• ALL: Este usuário pode executar comandos de qualquer terminal.
• (ALL): Este usuário pode executar comandos como qualquer usuário.
• NOPASSWD:: Especifica que nenhuma senha é necessária para operações sudo.
• ALL: Este usuário pode executar todos os comandos.

Aviso: Conceder NOPASSWD: ALL dá ao ansible_user acesso root irrestrito sem senha, o que pode ser um risco de segurança significativo. Use isso apenas se for realmente necessário e garanta que as credenciais do seu ansible_user sejam altamente seguras. Para segurança mais rigorosa, você pode especificar comandos exatos ou conjuntos de comandos que o usuário tem permissão para executar.

Verificando Acesso sudo

Antes de executar seu playbook, você pode verificar manualmente se seu ansible_user tem acesso sudo em um host de destino. Conecte-se via SSH ao host como ansible_user e execute:

# Verifique se você pode fazer sudo para root sem senha
sudo -n whoami

# Se uma senha for necessária, você será solicitado. Teste com um comando simples:
sudo whoami

# Liste os privilégios sudo para o usuário atual:
sudo -l

# Liste os privilégios sudo para um usuário específico (por exemplo, devops_user):
sudo -l -U devops_user

Se sudo -n whoami retornar root sem um prompt de senha, sua configuração NOPASSWD está provavelmente correta. Se ele solicitar uma senha, sua entrada sudoers pode estar faltando NOPASSWD ou está incorretamente configurada.

Diagnosticando Erros de Escalonamento de Privilégios

Ansible tipicamente fornece mensagens de erro informativas, mas problemas relacionados a privilégios podem ser às vezes crípticos. Aqui estão erros comuns e suas soluções:

1. "permission denied" ou "