Ansible Tower / AWX / Automation controller Security

Aprenda hacking na AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks:

• Se você deseja ver sua empresa anunciada no HackTricks ou baixar o HackTricks em PDF Confira os PLANOS DE ASSINATURA!

• Adquira o swag oficial PEASS & HackTricks

• Descubra A Família PEASS, nossa coleção exclusiva de NFTs

• Junte-se ao 💬 grupo Discord ou ao grupo telegram ou siga-me no Twitter 🐦 @hacktricks_live.

• Compartilhe seus truques de hacking enviando PRs para o HackTricks e HackTricks Cloud repositórios do github.

Informações Básicas

Ansible Tower ou sua versão de código aberto AWX também é conhecido como interface de 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 UI moderna. A API REST e a interface de linha de comando do Tower tornam simples integrá-lo às ferramentas e fluxos de trabalho atuais.

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

Diferenças

De acordo com este, as principais diferenças entre o Ansible Tower e o 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.

Pilha Tecnológica

• 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, também pode ser feito via API REST. Isso significa que você pode integrar o AWX/Tower com outros sistemas ou automatizar ações que normalmente seriam realizadas na interface.

• Banco de Dados: O 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: O Redis atua 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) nos quais as tarefas (playbooks Ansible) podem ser executadas. O 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 Ansible provenientes de um sistema de controle de versão (como Git) para buscar os playbooks mais recentes quando necessário.

• Modelos: Os modelos de tarefas definem como um playbook específico será executado, especificando o inventário, credenciais e outros parâmetros para a tarefa.

• Credenciais: O AWX/Tower fornece uma maneira segura de gerenciar e armazenar segredos, como chaves SSH, senhas e tokens de API. Essas credenciais podem ser associadas aos modelos de tarefas para que os playbooks tenham o acesso necessário quando são executados.

• Motor de Tarefas: Aqui é onde a mágica acontece. O motor de tarefas é construído no Ansible e é responsável por executar os playbooks. As tarefas são despachadas para o motor de tarefas, que então executa os playbooks Ansible no inventário designado usando as credenciais especificadas.

• Agendadores e Callbacks: Estes são recursos avançados no AWX/Tower que permitem agendar tarefas para serem executadas em horários específicos ou acionadas por eventos externos.

• Notificações: O AWX/Tower pode enviar notificações com base no sucesso ou falha das tarefas. Ele suporta vários meios de notificação, como e-mails, mensagens no Slack, webhooks, etc.

• Playbooks Ansible: Os playbooks Ansible são ferramentas de configuração, implantação e orquestração. Eles descrevem o estado desejado dos sistemas de forma 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 o AWX/Tower através da Interface Web ou da API REST. Estas fornecem acesso frontal a todas as funcionalidades oferecidas pelo AWX/Tower.

2. Inicialização da Tarefa:

• O usuário, via 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 inicialização da tarefa, é enviada uma solicitação ao backend do AWX/Tower para enfileirar a tarefa para execução.

3. Enfileiramento da Tarefa:

• O RabbitMQ lida com 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 o RabbitMQ.

• O 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 Ansible recuperado do Projeto associado, o Motor de Tarefas executa o playbook nos nós do Inventário especificado usando as Credenciais fornecidas.

• Conforme 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 da tarefa, Notificações podem ser despachadas para informar os usuários ou sistemas externos sobre o status da tarefa. As notificações podem ser e-mails, mensagens no Slack, webhooks, etc.

6. Integração com Sistemas Externos:

• Inventários podem ser obtidos dinamicamente de sistemas externos, permitindo que o AWX/Tower traga hosts de fontes como AWS, Azure, VMware e outros.

• Projetos (playbooks) podem ser obtidos de sistemas de controle de versão, garantindo o uso de playbooks atualizados durante a execução das tarefas.

• 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 o 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.

Expanda para obter uma descrição detalhada das funções disponíveis

1. Administrador do Sistema:

• Esta é a função de superusuário com permissões para acessar e modificar qualquer recurso no sistema.

• Eles podem gerenciar todas as organizações, equipes, projetos, inventários, modelos de trabalho, etc.

2. Auditor do Sistema:

• Usuários com esta função podem visualizar todos os dados do sistema, mas não podem fazer alterações.

• Esta função é projetada para conformidade e supervisão.

3. Funções da Organização:

• Admin: Controle total sobre os recursos da organização.

• Auditor: Acesso somente leitura aos recursos da organização.

• Membro: Associação básica em uma organização sem permissões específicas.

• Executar: Pode executar modelos de trabalho dentro da organização.

• Ler: Pode visualizar os recursos da organização.

4. Funções do Projeto:

• Admin: Pode gerenciar e modificar o projeto.

• Usar: Pode usar o projeto em um modelo de trabalho.

• Atualizar: Pode atualizar o projeto usando SCM (controle de origem).

5. Funções do Inventário:

• Admin: Pode gerenciar e modificar o inventário.

• Ad Hoc: Pode executar comandos ad hoc no inventário.

• Atualizar: Pode atualizar a origem do inventário.

• Usar: Pode usar o inventário em um modelo de trabalho.

• Ler: Acesso somente leitura.

6. Funções do Modelo de Trabalho:

• Admin: Pode gerenciar e modificar o modelo de trabalho.

• Executar: Pode executar o trabalho.

• Ler: Acesso somente leitura.

7. Funções de Credencial:

• Admin: Pode gerenciar e modificar as credenciais.

• Usar: Pode usar as credenciais em modelos de trabalho ou outros recursos relevantes.

• Ler: Acesso somente leitura.

8. Funções da Equipe:

• Membro: Parte da equipe, mas sem permissões específicas.

• Admin: Pode gerenciar os membros da equipe e os recursos associados.

9. Funções do Fluxo de Trabalho:

• Admin: Pode gerenciar e modificar o fluxo de trabalho.

• Executar: Pode executar o fluxo de trabalho.

• Ler: Acesso somente leitura.