Usaremos o Terraform para automatizar nossa implantação de infraestrutura e o Packer para criar as imagens de máquinas implementadas pelo Terraform. Seguindo os princípios imutáveis de design da infraestrutura, implementaremos o patch criando uma nova imagem com o patch aplicado e, em seguida, reimplantamos nossa infraestrutura.
Com essa configuração, existem ferramentas adicionais que podemos usar para detectar automaticamente quando um pacote ou o próprio sistema operacional em nossa imagem base precisa ser atualizado e acionar o pipeline de construção?
O Chef Automate parece próximo do que estou procurando, no entanto, parece verificar a conformidade dos nós em execução, em vez de analisar o próprio manifesto da imagem.
Obrigado!
chef
terraform
infrastructure-as-code
packer
immutable-servers
Thuy Guevarra
fonte
fonte
machine images,By following immutable infrastructure design principles,Chef Automate seems close to what I'm looking for,base image. Por favor, esclareça.Respostas:
Parte da adoção do Padrão de infra-estrutura imutável é decompor seu sistema em pequenas partes gerenciáveis que podem se mover pelo pipeline de CI / CD muito rapidamente, isso significa que os patches do SO podem ser feitos rapidamente e de maneira controlada. Muitas vezes vejo clientes terminando em uma casa intermediária, onde a infraestrutura é imutável.
No entanto, existem algumas abordagens para isso que eu usei em implantações em larga escala da arquitetura em nuvem, normalmente implanto mais de uma como parte da estratégia de Defesa em Profundidade :
Informações de segurança e gerenciamento de eventos (SIEM) : esses produtos, por exemplo, a LogRhythm Security Intelligence Platform e produtos mais genéricos, como o ElasticStack, recebem feeds do sistema operacional, que inclui a saída de uma verificação frequente de atualizações. O truque aqui é obter informações sobre o que corrigir rapidamente e automaticamente, para informar as decisões sobre quando fazer o roll-up em seu pipeline.
Os sistemas de gerenciamento de vulnerabilidades são mais personalizados do que o SIEM, pois estão focados apenas nas vulnerabilidades do sistema, de modo que podem detectar problemas nas bibliotecas instaladas como parte do software implantado no sistema, mas não gerenciado pelo sistema operacional. Isso pode destacar vulnerabilidades para as quais não há patch (ainda ... espero).
As ferramentas de verificação de dependência fazem parte do seu pipeline e podem ser configuradas para falhar na compilação se os check-ins adicionarem vulnerabilidades, isso também funcionará se uma nova vulnerabilidade for adicionada à ferramenta desde o último check-in.
fonte
Você pode fazer uma varredura de vulnerabilidade com o AWS Inspector e procurar por vulnerabilidades do CVE. O Inspector possui uma métrica do CloudWatch para causar uma ação quando houver descobertas. Seria complicado determinar quais pacotes precisam ser atualizados, mas você pode atualizar tudo. Você não precisa usar o Inspector, qualquer ferramenta de verificação de vulnerabilidades em que possa se conectar funcionaria. A verificação de vulnerabilidades é uma prática recomendada em geral.
Outra idéia seria configurar um trabalho cron que faça apt-get update && apt-get upgrade —dry-run> coisas que deveriam ser atualizadas.txt e analise o arquivo de texto para obter uma lista de pacotes a serem atualizados e atualizados. alimente isso de volta ao seu processo de criação.
fonte
Essa abordagem procura resolver seu objetivo usando a auditoria do Chef, mas possui seus próprios problemas. https://joshuakugler.com/using-chef-zero-audit-mode-and-packer.html
Uma solução personalizada - Se você deseja usar uma Política de conformidade (por exemplo, CIS, HIPPA), crie um trabalho que execute o analisador de auditoria ao executar imagens de pacotes e notifique uma tarefa de atualização sobre o status de não reclamação. Há analisador OVAL e definição OVAL disponíveis gratuitamente para as políticas acima. Para políticas personalizadas de aduit, você pode escrever seu próprio analisador e auditar a imagem.
fonte