APRENDER. PRATICAR. EVOLUIR.1. Provar qual é o destino da automação
Uma equipa fictícia de produção prepara dois servidores para um novo serviço de ficheiros. Antes de criar contas, precisa de saber onde vai executar cada tarefa. O laboratório usa nodea e nodeb, dois contentores UBI 9 com servidores SSH próprios, e um controlador separado. As chaves dos hosts são recolhidas através do canal de preparação controlado e colocadas num known_hosts dedicado. Uma ligação com uma chave de host diferente é rejeitada. Esta comparação demonstra a verificação de identidade configurada; aceitar automaticamente qualquer chave observada na rede não teria a mesma base de confiança. Em produção, uma substituição de servidor pode justificar uma chave nova, mas a equipa deve confirmar essa mudança através do processo autorizado antes de atualizar o registo.
2. Separar quem liga de quem executa
O inventário liga como automation, utilizando uma chave privada que existe apenas no controlador descartável. No primeiro comando id -un, o play define become_user: root mas não ativa become. O resultado é automation. Na tarefa seguinte, become: true ativa a elevação e o resultado passa a root. Ambos são observados em cada nó através de SSH. A conclusão depende da configuração efetiva: uma variável ansible_become definida noutro nível pode alterar o comportamento esperado de uma diretiva. Quando uma tarefa falha por permissões, verifica primeiro utilizador de ligação, opções de elevação e política sudo aplicada. Trocar a conta SSH por root pode esconder a causa e ampliar o acesso sem resolver o desenho de execução aprovado.
3. Validar uma alteração antes de a ativar
O play instala uma regra de demonstração que permite a trainee executar /usr/bin/id como root. O módulo copy chama visudo sobre o ficheiro temporário através de validate antes de substituir o destino. Uma segunda execução apresenta um candidato com sintaxe inválida. A tarefa falha nos dois nós e o hash da regra anterior mantém-se. Depois verifica-se a política completa com visudo -c, pois validar um fragmento isolado não deteta todas as interações com outros ficheiros incluídos. São feitas também duas chamadas reais: o comando permitido funciona e um comando diferente é recusado. Validade sintática, permissões do ficheiro e comportamento de autorização são verificações complementares. Nenhuma demonstra, sozinha, que a política corresponde aos requisitos de acesso da organização.
4. Distinguir a política de um comando da execução de módulos
A regra limitada de trainee serve para observar decisões de sudo; essa conta não é a identidade de automação do exercício. O utilizador automation tem uma regra ampla apenas dentro dos contentores descartáveis para permitir executar os módulos necessários. Ansible pode transferir código para caminhos temporários e executá-lo através do interpretador. Autorizar apenas useradd ou chmod não significa que o módulo user ou file ficará autorizado. Uma equipa deve desenhar o acesso da automação, proteger credenciais, limitar destinos e controlar quem pode lançar alterações. A regra ampla do laboratório não é uma recomendação para servidores reais. Ao transpor um exercício, regista explicitamente as diferenças entre o acesso de preparação, a conta de execução e o acesso de emergência.
5. Entregar evidência com um âmbito preciso
O relatório identifica as versões, imagens, hosts, resultados de cada play e verificações após execução. O controlador usa ansible-core 2.20.10 e ansible.posix 2.2.2; os alvos usam Python 3.9 em UBI 9. São ligações SSH reais entre espaços de utilizador separados, mas os contentores partilham o kernel da máquina virtual Docker. Não foi validado um arranque completo de RHEL, persistência após reboot, SELinux enforcing ou AAP. No handover fictício, a equipa pode aceitar a evidência para o comportamento de contas e SSH ensaiado e manter critérios separados para esses restantes componentes. Um recap sem falhas sustenta o que foi executado; não preenche verificações de plataforma que não ocorreram.
# Original lab: content/labs/rhce-remote-accounts
# Run the complete disposable lab: python3 run.py --output evidence-local.json
# Requires images built with Dockerfile.node and Dockerfile.controller.
# The runner provisions keys and inventory; this play belongs to that fixture.
# Inside the prepared controller: ansible-playbook -i /lab/inventory.ini /lab/identity.yml
- name: Prove connection identity and explicit escalation on each remote node
hosts: managed
gather_facts: false
become_user: root
tasks:
- name: Observe identity with become_user but without become
ansible.builtin.command: id -un
changed_when: false
register: connection_identity
- name: Observe identity after explicit become
ansible.builtin.command: id -un
become: true
changed_when: false
register: elevated_identity
- name: Observe target hostname
ansible.builtin.command: uname -n
changed_when: false
register: target_identity
- name: Assert connection and execution are different identities
ansible.builtin.assert:
that:
- connection_identity.stdout == 'automation'
- elevated_identity.stdout == 'root'
- target_identity.stdout == inventory_hostname
Sem become, id devolve automation; com become: true, devolve root. Um candidato sudo inválido falha antes de substituir a regra funcional.
Armadilhas comuns
Desativar host-key checking para desbloquear um erro; confundir become_user com ativação; aceitar apenas sintaxe sudo; copiar a regra ampla do laboratório para produção.
Tópicos relacionados: Contas, grupos e revogação SSH
Confirma o destino, observa ambas as identidades e testa a política autorizada antes de aceitar o handover.
Referência: Privilege escalation: connection identity and become · EX294 current objectives inspected 2026-09-30; RHCE in Ansible framework effective 2026-05-11; booking product version not publicly pinned