Ansible Tower / AWX / Segurança do controlador de automação

Reading time: 12 minutes

Informações Básicas

Ansible Tower ou sua versão de código aberto AWX também é conhecido como interface do usuário do Ansible, painel e API REST. Com controle de acesso baseado em funções, agendamento de tarefas e gerenciamento gráfico de inventário, você pode gerenciar sua infraestrutura Ansible a partir de uma interface moderna. A API REST do Tower e a interface de linha de comando facilitam a integração com ferramentas e fluxos de trabalho atuais.

O Controlador de Automação é uma versão mais nova do Ansible Tower com mais capacidades.

Diferenças

De acordo com este, as principais diferenças entre Ansible Tower e AWX são o suporte recebido e o Ansible Tower possui recursos adicionais, como controle de acesso baseado em funções, suporte para APIs personalizadas e fluxos de trabalho definidos pelo usuário.

Stack Tecnológico

• Interface Web: Esta é a interface gráfica onde os usuários podem gerenciar inventários, credenciais, modelos e tarefas. É projetada para ser intuitiva e fornece visualizações para ajudar a entender o estado e os resultados de suas tarefas de automação.
• API REST: Tudo o que você pode fazer na interface web, você também pode fazer via API REST. Isso significa que você pode integrar AWX/Tower com outros sistemas ou scriptar ações que normalmente você realizaria na interface.
• Banco de Dados: AWX/Tower usa um banco de dados (tipicamente PostgreSQL) para armazenar sua configuração, resultados de tarefas e outros dados operacionais necessários.
• RabbitMQ: Este é o sistema de mensagens usado pelo AWX/Tower para se comunicar entre os diferentes componentes, especialmente entre o serviço web e os executores de tarefas.
• Redis: Redis serve como um cache e um backend para a fila de tarefas.

Componentes Lógicos

• Inventários: Um inventário é uma coleção de hosts (ou nós) contra os quais tarefas (playbooks do Ansible) podem ser executadas. AWX/Tower permite que você defina e agrupe seus inventários e também suporta inventários dinâmicos que podem buscar listas de hosts de outros sistemas como AWS, Azure, etc.
• Projetos: Um projeto é essencialmente uma coleção de playbooks do Ansible provenientes de um sistema de controle de versão (como Git) para puxar os playbooks mais recentes quando necessário.
• Modelos: Modelos de tarefas definem como um determinado playbook será executado, especificando o inventário, credenciais e outros parâmetros para a tarefa.
• Credenciais: AWX/Tower fornece uma maneira segura de gerenciar e armazenar segredos, como chaves SSH, senhas e tokens de API. Essas credenciais podem ser associadas a modelos de tarefas para que os playbooks tenham o acesso necessário quando forem executados.
• Motor de Tarefas: É aqui que a mágica acontece. O motor de tarefas é construído sobre o Ansible e é responsável por executar os playbooks. As tarefas são despachadas para o motor de tarefas, que então executa os playbooks do Ansible contra o inventário designado usando as credenciais especificadas.
• Agendadores e Callbacks: Esses são recursos avançados no AWX/Tower que permitem que tarefas sejam agendadas para serem executadas em horários específicos ou acionadas por eventos externos.
• Notificações: AWX/Tower pode enviar notificações com base no sucesso ou falha das tarefas. Ele suporta vários meios de notificações, como e-mails, mensagens do Slack, webhooks, etc.
• Playbooks do Ansible: Playbooks do Ansible são ferramentas de configuração, implantação e orquestração. Eles descrevem o estado desejado dos sistemas de uma maneira automatizada e repetível. Escritos em YAML, os playbooks usam a linguagem de automação declarativa do Ansible para descrever configurações, tarefas e etapas que precisam ser executadas.

Fluxo de Execução de Tarefas

1. Interação do Usuário: Um usuário pode interagir com AWX/Tower através da Interface Web ou da API REST. Estas fornecem acesso frontal a todas as funcionalidades oferecidas pelo AWX/Tower.
2. Iniciação da Tarefa:

• O usuário, através da Interface Web ou API, inicia uma tarefa com base em um Modelo de Tarefa.
• O Modelo de Tarefa inclui referências ao Inventário, Projeto (contendo o playbook) e Credenciais.
• Após a iniciação da tarefa, uma solicitação é enviada ao backend do AWX/Tower para colocar a tarefa na fila para execução.

3. Fila de Tarefas:

• RabbitMQ gerencia a comunicação entre o componente web e os executores de tarefas. Uma vez que uma tarefa é iniciada, uma mensagem é despachada para o motor de tarefas usando RabbitMQ.
• Redis atua como o backend para a fila de tarefas, gerenciando tarefas enfileiradas aguardando execução.

4. Execução da Tarefa:

• O Motor de Tarefas pega a tarefa enfileirada. Ele recupera as informações necessárias do Banco de Dados sobre o playbook associado à tarefa, inventário e credenciais.
• Usando o playbook do Ansible recuperado do Projeto associado, o Motor de Tarefas executa o playbook contra os nós do Inventário especificado usando as Credenciais fornecidas.
• À medida que o playbook é executado, sua saída de execução (logs, fatos, etc.) é capturada e armazenada no Banco de Dados.

5. Resultados da Tarefa:

• Uma vez que o playbook termina de ser executado, os resultados (sucesso, falha, logs) são salvos no Banco de Dados.
• Os usuários podem então visualizar os resultados através da Interface Web ou consultá-los via API REST.
• Com base nos resultados das tarefas, Notificações podem ser enviadas para informar usuários ou sistemas externos sobre o status da tarefa. As notificações podem ser e-mails, mensagens do Slack, webhooks, etc.

6. Integração com Sistemas Externos:

• Inventários podem ser dinamicamente obtidos de sistemas externos, permitindo que o AWX/Tower puxe hosts de fontes como AWS, Azure, VMware e mais.
• Projetos (playbooks) podem ser buscados de sistemas de controle de versão, garantindo o uso de playbooks atualizados durante a execução da tarefa.
• Agendadores e Callbacks podem ser usados para integrar com outros sistemas ou ferramentas, fazendo com que o AWX/Tower reaja a gatilhos externos ou execute tarefas em horários predeterminados.

Criação de laboratório AWX para testes

Seguindo a documentação é possível usar docker-compose para executar o AWX:

git clone -b x.y.z https://github.com/ansible/awx.git # Get in x.y.z the latest release version

cd awx

# Build
make docker-compose-build

# Run
make docker-compose

# Or to create a more complex env
MAIN_NODE_TYPE=control EXECUTION_NODE_COUNT=2 COMPOSE_TAG=devel make docker-compose

# Clean and build the UI
docker exec tools_awx_1 make clean-ui ui-devel

# Once migrations are completed and the UI is built, you can begin using AWX. The UI can be reached in your browser at https://localhost:8043/#/home, and the API can be found at https://localhost:8043/api/v2.

# Create an admin user
docker exec -ti tools_awx_1 awx-manage createsuperuser

# Load demo data
docker exec tools_awx_1 awx-manage create_preload_data

RBAC

Funções suportadas

A função mais privilegiada é chamada de Administrador do Sistema. Qualquer pessoa com essa função pode modificar qualquer coisa.

De uma revisão de segurança de caixa branca, você precisaria da função de Auditor do Sistema, que permite visualizar todos os dados do sistema, mas não pode fazer alterações. Outra opção seria obter a função de Auditor da Organização, mas seria melhor obter a outra.

Enumeração & Mapeamento de Caminho de Ataque com AnsibleHound

AnsibleHound é um coletor BloodHound OpenGraph de código aberto escrito em Go que transforma um token de API do Ansible Tower/AWX/Automation Controller somente leitura em um gráfico de permissões completo pronto para ser analisado dentro do BloodHound (ou BloodHound Enterprise).

Por que isso é útil?

1. A API REST do Tower/AWX é extremamente rica e expõe cada objeto e relacionamento RBAC que sua instância conhece.
2. Mesmo com o token de menor privilégio (Ler), é possível enumerar recursivamente todos os recursos acessíveis (organizações, inventários, hosts, credenciais, projetos, modelos de trabalho, usuários, equipes…).
3. Quando os dados brutos são convertidos para o esquema do BloodHound, você obtém as mesmas capacidades de visualização de caminho de ataque que são tão populares em avaliações do Active Directory – mas agora direcionadas à sua infraestrutura de CI/CD.

As equipes de segurança (e atacantes!) podem, portanto:

• Compreender rapidamente quem pode se tornar admin de quê.
• Identificar credenciais ou hosts que são acessíveis a partir de uma conta não privilegiada.
• Encadear múltiplas arestas “Ler ➜ Usar ➜ Executar ➜ Admin” para obter controle total sobre a instância do Tower ou a infraestrutura subjacente.

Pré-requisitos

• Ansible Tower / AWX / Automation Controller acessível via HTTPS.
• Um token de API de usuário com escopo Ler apenas (criado a partir de Detalhes do Usuário → Tokens → Criar Token → escopo = Ler).
• Go ≥ 1.20 para compilar o coletor (ou use os binários pré-compilados).

Construindo & Executando

# Compile the collector
cd collector
go build . -o build/ansiblehound

# Execute against the target instance
./build/ansiblehound -u "https://tower.example.com/" -t "READ_ONLY_TOKEN"

Internamente, o AnsibleHound realiza requisições GET paginated contra (pelo menos) os seguintes endpoints e segue automaticamente os links related retornados em cada objeto JSON:

/api/v2/organizations/
/api/v2/inventories/
/api/v2/hosts/
/api/v2/job_templates/
/api/v2/projects/
/api/v2/credentials/
/api/v2/users/
/api/v2/teams/

Todos os arquivos coletados são mesclados em um único arquivo JSON no disco (padrão: ansiblehound-output.json).

Transformação BloodHound

Os dados brutos do Tower são então transformados para BloodHound OpenGraph usando nós personalizados prefixados com AT (Ansible Tower):

• ATOrganization, ATInventory, ATHost, ATJobTemplate, ATProject, ATCredential, ATUser, ATTeam

E arestas modelando relacionamentos / privilégios:

• ATContains, ATUses, ATExecute, ATRead, ATAdmin

O resultado pode ser importado diretamente para o BloodHound:

neo4j stop   # if BloodHound CE is running locally
bloodhound-import ansiblehound-output.json

Opcionalmente, você pode fazer upload de ícones personalizados para que os novos tipos de nó sejam visualmente distintos:

python3 scripts/import-icons.py "https://bloodhound.example.com" "BH_JWT_TOKEN"

Considerações Defensivas e Ofensivas

• Um token Read é normalmente considerado inofensivo, mas ainda vaza a topologia completa e todos os metadados de credenciais. Trate-o como sensível!
• Imponha menor privilégio e gire / revogue tokens não utilizados.
• Monitore a API para enumeração excessiva (múltiplas requisições GET sequenciais, alta atividade de paginação).
• Do ponto de vista de um atacante, esta é uma técnica perfeita de ponto de apoio inicial → escalonamento de privilégios dentro do pipeline CI/CD.

Referências

• AnsibleHound – Coletor BloodHound para Ansible Tower/AWX
• BloodHound OSS