TIPS - Configurando CI com chaves seguras

Uma dica de como configurar GitLab CI sem correr riscos de ataques de man-in-the-middle.

TIPS - Configurando CI com chaves seguras

Eu odeio fazer deploy manual, quero deploys tão simples quanto fazer merge na branch master. Mas recentemente para configurar isso em um projeto me deparei com o problema como a AWS lida com as chaves e aqui segue alguns aprendizados e um atalho para quem estiver com o mesmo problema.

Eu tenho a seguinte mentalidade, seu eu consigo fazer no terminal ou no código, consigo fazer em qualquer outra máquina. Mas em alguns cenários sempre tem uma tela de permissão ou uma linha com (yes|no) para responder que pode ferrar td isso é o que acontece quando se configura um CI e precisa transferir arquivos do CI para o servidor.

Estava configurando um scp, comando unix para transferir arquivos com segurança entre máquinas, o problema é que ele tem uma pergunta para adicionar os hosts conhecidos esse computador desconhecido. Isso é só digitar um yes e seja feliz. O problema é fazer isso no CI.

A primeira sugestão que encontrei é adicionar ao scpa opção -o com o valor StrictHostKeyChecking=no. O problema é questão de insegurança que fazer isso gera. Como vc pode ver nos seguintes links

Se algo é inseguro não é um caminho q escolho, apesar de ser o mais fácil e com algumas tentativas vi que funcionava, mas o custo de expor a minha aplicação no deploy, parece que não se pagava.

Foi quando me surgiu uma outra ideia, qual é o caminho feito para adicionar uma nova entrada no arquivo know_hosts?

Adicionando um servidor conhecido

Primeiro  existem algumas etapas envolvidas para isso e segue aqui um resumo disso e como conseguir ter deploys seguros.

O know_hosts server para o usuário autenticar um servidor, para isso precisa de algumas chaves, que o servidor devolve ao iniciar a conexão SSH. Usando o comando ssh-keyscan você consegue obter essas chaves, bastar usar o paramentro -H com a url ou IP do servidor e adicionar o resultado ao arquivo know_hosts.

Com essa etapa feita agora é só fazer a conexão com o servidor usando usando a chave a e os parametros -o "ForwardAgent=yes" -o "UserKnownHostsFile=~/.ssh/known_hosts"

E pronto ssh funcionando sem abri vunerabilidade de man-in-the-middle.

Se você é devops e viu que falei alguma besteira ou tem algo que poderia acrescentar, só me falar.