Criar e revisar automação de infraestrutura com Ansible sem enfraquecer a segurança

## Priorizar segurança e estabilidade e mudar só o que foi pedido Trate a automação de infraestrutura como código crítico para a segurança: um pequeno erro de configuração pode enfraquecer silenciosamente a privacidade, o controle de acesso, o roteamento ou a disponibilidade do serviço. - Prefira estabilidade a volume de recursos, segurança a conveniência e clareza a soluções engenhosas. - Resolva exatamente o problema solicitado. Mantenha correções não relacionadas e recursos especulativos em trabalhos separados. - Teste as suposições executando a automação afetada antes de declarar uma alteração concluída. - Resista a novas dependências. Cada dependência amplia a superfície de ataque e a carga de manutenção. - Siga os padrões existentes do repositório antes de introduzir novas abstrações ou opções de configuração. - Trate cada nova opção como uma superfície adicional de teste; adicione-a apenas quando os usuários tiverem uma necessidade comprovada. - Use implantações novas nos testes de comportamento quando o estado mantido puder ocultar defeitos. ## Passar em todos os lint e verificações de segurança sem nenhum aviso Execute o controle de qualidade local completo do repositório antes da revisão. Ele deve abranger análise de configuração, YAML e linguagem, análise de shell, análise estática de segurança, verificação de sintaxe de playbooks e os testes unitários relevantes. Nenhum aviso é aceitável na integração contínua. Em automação sensível à segurança, achados aparentemente cosméticos podem ocultar templates quebrados, permissões de arquivo inseguras ou uma regressão real entre ruídos recorrentes. Resolva os achados nesta ordem: 1. Corrija o problema subjacente. 2. Se a regra não for adequada ao repositório, inclua-a na lista permitida da configuração da ferramenta responsável e explique o motivo. 3. Use uma supressão inline somente como último recurso, informando a regra exata e documentando a exceção. Não transfira os achados para uma lista permanente de avisos. Uma regra deve passar ou ser explicitamente ignorada com uma justificativa duradoura. As verificações obrigatórias comuns incluem: - Iniciar documentos YAML com `---` e colocar entre aspas chaves ambíguas de workflows quando o parser exigir. - Preferir condições de falha explícitas, como `failed_when`, ao uso amplo de `ignore_errors`. - Manter espaçamento consistente em Jinja2. - Especificar `mode` em toda tarefa de arquivo ou diretório, em vez de depender de `umask`. - Colocar variáveis de shell entre aspas e ativar tratamento rigoroso de erros de shell. - Tratar supressões de análise estática como exceções revisáveis, não como atalhos. Antes de enviar uma alteração, examine a diferença, registre as verificações executadas e confirme que a integração contínua realizará as mesmas validações essenciais. ## Verificar as entradas cedo e manter segredos fora do repositório Valide as entradas antes de operações caras ou que alterem estado. Rejeite coleções vazias, configurações ausentes, endereços malformados, versões incompatíveis e divergências de permissão no primeiro ponto confiável. - Defina explicitamente os modos de arquivos e diretórios. - Falhe diante de erros de permissão, autenticação, criptografia ou limites de segurança. Reserve avisos para comportamentos realmente opcionais. - Torne os erros acionáveis, informando a condição que falhou e a ação corretiva segura. - Aplique privilégio mínimo: reduza permissões, contas, credenciais mantidas e capacidades de processos. - Use padrões seguros, criptografia forte, regras de firewall rigorosas, registro mínimo e retenção mínima de dados. - Nunca armazene senhas, chaves privadas, tokens de acesso nem credenciais de provedores no controle de código-fonte. - Responda prontamente a vulnerabilidades de segurança confirmadas e verifique o comportamento atualizado. - Evite soluções alternativas não documentadas. Registre por que uma solução existe e indique sua questão no projeto de origem para que os responsáveis possam encerrá-la com segurança depois. Procure um padrão estabelecido na base de código antes de adicionar tarefa, condição, caminho de provedor ou módulo. Reutilize o fluxo de controle existente, a menos que evidências demonstrem que ele é inadequado. ## Evitar erros comuns em loops do Ansible e templates Jinja2 Não substitua mecanicamente iteração legada por `loop`. Algumas formas legadas de iteração achatam listas aninhadas, enquanto `loop` preserva a estrutura. Verifique o formato resultante do item e confirme que os arquivos ou recursos esperados foram criados. - Passe uma lista diretamente para `loop`; não envolva uma lista existente em outra lista. - Combine listas explicitamente quando a construção anterior achatava várias entradas. - Mantenha variáveis de caminho sem barras finais para evitar separadores duplicados. - Em comandos e handlers somente de leitura, defina `changed_when: false` para manter corretos os relatórios de estado. - Use `failed_when: false` somente quando a falha do comando for explicitamente esperada e segura; não oculte falhas não relacionadas. Na avaliação nativa do Jinja2: - Condições exigem valores booleanos reais, não strings como `"true"` e `"false"`. - Passe variáveis diretamente para lookups; não aninhe uma expressão de template dentro de outra. - Analise explicitamente o texto JSON quando um lookup retornar conteúdo de arquivo. - Lembre que `default()` não substitui uma string vazia, a menos que sua opção para valores falsos esteja ativada. - Substitua compreensões de lista complexas geradas por templates por loops comuns de automação e acumulação explícita. - Use testes para predicados booleanos e filtros para transformação de dados. Teste templates com os filtros reais da estrutura de automação ou com mocks fiéis. A validade da sintaxe, por si só, não comprova o comportamento no modo nativo. ## Depurar serviços de rede camada por camada, começando pelas portas em escuta Depure a automação de rede a partir da camada incerta mais baixa, em vez de presumir que todo sintoma de conectividade é uma falha de roteamento. 1. Confirme que os sockets TCP e UDP esperados estão escutando no endereço e na porta pretendidos. 2. Examine o status do serviço e da unidade de socket em busca de avisos de configuração. 3. Verifique as configurações de rede necessárias do kernel. 4. Teste a resolução de nomes diretamente no resolvedor configurado. 5. Somente então examine regras de firewall, tradução de endereços e roteamento por políticas. Em serviços ativados por socket, configure a unidade de socket, não apenas a configuração do serviço. Limpe listeners herdados quando necessário, defina listeners de stream e datagrama e reinicie o socket após as alterações. Desativar o socket pode quebrar dependências do serviço. Considere deliberadamente as diferenças entre plataformas: - Backends de firewall podem reordenar regras; fixe ou verifique o backend cujo comportamento a automação espera. - Hosts com várias conexões de rede podem exigir uma interface de saída explícita para tradução de endereços. - Prefira mascaramento simples com interface especificada a uma complexidade desnecessária de tradução de origem quando ele atender ao requisito. - Adicione flags de compatibilidade condicionalmente depois de detectar a versão da ferramenta instalada. - Coloque endpoints IPv6 entre colchetes quando a sintaxe de host e porta exigir. - Verifique a resolução de nomes antes de reprojetar regras de roteamento ou tradução. Mantenha as regras de rede simples e teste o fluxo de pacotes, em vez de inferir sucesso a partir do resultado de uma tarefa. ## Provar que cada teste de regressão falha quando o bug volta Um teste de regressão deve demonstrar que detecta o defeito que afirma impedir. 1. Escreva um teste focado no caso de falha. 2. Introduza temporariamente o defeito ou altere a condição relacionada. 3. Confirme que o novo teste falha pelo motivo pretendido. 4. Restaure a implementação correta e confirme que o teste passa. 5. Documente a regressão exata contra a qual o teste protege. Quando o comportamento depender de templates, caminhos de arquivo, permissões, regras de firewall ou formatos de coleção, teste o resultado observável, não apenas o texto gerado. Verifique, conforme apropriado, arquivos criados, modos efetivos, valores analisados, estado dos listeners, fluxo de pacotes ou saída renderizada. Atualize testes existentes quando uma alteração modificar caminhos ou comportamento. Não presuma que um teste aprovado seja significativo até que sua sensibilidade à falha tenha sido demonstrada. ## Implantar sem perguntas interativas e relatar só as verificações feitas A automação destinada à integração contínua ou a agentes deve oferecer um caminho totalmente não interativo. - Toda solicitação deve ser contornada quando sua variável estiver predefinida por um parâmetro ou variável de ambiente aprovados. - Documente o conjunto completo de variáveis principais, seus tipos, valores padrão e propósito. - Mantenha credenciais específicas de provedores separadas da configuração comum e aceite-as somente por canais de segredos aprovados. - Exija variáveis de confirmação explícitas para modos de implantação locais ou de alto impacto. - Garanta que recursos opcionais tenham valores booleanos explícitos para que execuções sem interface não parem por falta de entrada. - Teste o caminho não interativo em um ambiente limpo com condições representativas de várias interfaces e endereços. Antes da conclusão, execute todos os analisadores, verificações de sintaxe, testes unitários relevantes e uma implantação nova ou teste de integração equivalente. Revise a diferença em busca de correções não relacionadas, dependências sem justificativa, supressões ocultas, modos de arquivo ausentes, segredos e comportamento não documentado. Informe as evidências exatas coletadas e não declare sucesso da implantação se somente verificações estáticas tiverem sido executadas.