Ansible - private git repositories - encaminhamento de agente SSH vs cópia de chave SSH privada

Recentemente, comecei a brincar com o Ansible e parece muito bom. Não tenho muita experiência em coisas de DevOps e nunca precisei lidar com cenários complexos. Comecei a criar meu manual do Ansible para substituir minha ferramenta de implantação atual - o Deployer PHP. Infelizmente, estou preso na clonagem de repositório git. Agora, eu sei que preciso de uma chave pública adicionada para habilitar o acesso ao repositório git e aqui vem minha pergunta.

Devo usar o encaminhamento de agente SSH (desta maneira, posso usar minhas chaves SSH locais) ou devo armazenar uma chave SSH privada (criptografada, adicionada ao controle de origem) dentro do meu projeto ansible e copiá-la usando Ansible para o nó de destino? Sei que a pergunta pode ser muito ampla, o que me interessa são as implicações de segurança de ambas as abordagens.

Você também pode criptografar o arquivo que contém sua chave SSH privada usando o Ansible Vault.

Alguns links:

http://docs.ansible.com/ansible/latest/playbooks_vault.html

https://therealmarv.com/ansible-vault-file-handling/

https://www.calazan.com/how-to-deploy-encrypted-copies-of-your-ssl-keys-and-other-files-with-ansible-and-openssl/

Se o seu git repos for um github particular, você poderá usar os métodos do github (deploy keys é muito poderoso).

Se seus repositórios não estiverem hospedados no github ou se não fornecerem o recurso principal de implantação somente leitura, as duas opções mencionadas são valiosas.

Único cara do DevOps

Se você é a única pessoa que trabalha no projeto e Suas máquinas / máquinas são as únicas das quais você pode executar (sem ferramentas de CD como Jenkins e amigos), é melhor usar a opção de encaminhamento de agentes: provavelmente é menos possível que você esqueça sua chave privada sem criptografia.

Equipe pequena

Se você é uma equipe de pessoas que trabalham no mesmo manual Ansible ou em várias pessoas que executam o manual, você tem as duas opções:

• mantenha a opção de encaminhamento de agente; todo companheiro de equipe executa o script em sua máquina.

• crie um par de chaves do implementador, faça o upload da chave do pub e criptografe o privado com o cofre, conforme sugerido por Berlim . A chave é criptografada e o escopo da chave privada é restrito a apenas 1 ou poucos repositórios. O problema dessa abordagem é que você precisa rotacionar a senha do cofre toda vez que um colega de equipe sai da equipe.

Eu nunca colocaria minha chave privada pessoal, que tem um amplo escopo, em qualquer lugar possivelmente inseguro. A criptografia de cofre é tão boa quanto as pessoas que a usam e há muitas chaves / senhas em texto não criptografado por aí :)

Devo usar o encaminhamento de agente SSH (desta forma, posso usar minhas chaves SSH locais)

Sim, isso poderia ser uma opção

devo armazenar a chave SSH privada (criptografada, adicionada ao controle de origem) dentro do meu projeto ansible e copiá-la usando Ansible no meu nó de destino?

não

/server/823956/ansible-security-best-practices

Para servidores, não permita acesso root via ssh. Muitas auditorias zombam disso.

Por exemplo, permita que cada administrador use sua própria conta pessoal em cada servidor de destino e deixe que eles usem senhas. Dessa forma, nenhuma senha é compartilhada entre duas pessoas. Você pode verificar quem fez o quê em cada servidor. Depende de você se as contas pessoais permitirem login com senha, apenas chave ssh ou exigir as duas.

Em resumo, use uma chave ssh com senha. Deixe todo usuário usar suas próprias chaves ssh. Nunca permita acesso ao sudo via ssh.

Você pode criar uma história de sua chave privada em uma circunstância: se você configurar seu repositório para permitir apenas o acesso de leitura para essa chave específica e não se preocupar com o fato de o repositório ser publicamente legível. Nesse caso, você pode armazenar facilmente sua chave privada - obviamente, faça uma chave descartável sem senha. Mas como eu disse, apenas se você estiver bem com o acesso público a esse repositório.

Se não for esse o caso, provavelmente você está preso ao agente SSH. Não é o ideal, como rootpode ser o caso, mas se você estiver em um tipo de ambiente benevolente (ou seja, nenhum servidor da Web atacável nem perto), deve estar tudo bem.