ANSIBLE SERIES: h.t.wrt* … Passwords: VAULT

Chegou a vez da parte sensível de qualquer negócio: SEGREDOS. Usados para proteger conteúdo crítico ou valioso aos interessado(s)/detentor(es), eles são chamados corriqueiramente de senhas. Além disso, outra definição importante é o conceito de COFRE. Esse seria como uma área reservada e protegida contra acesso não-autorizado. Para entrar no mesmo você precisaria de um dispositivo físico (token), por exemplo: cartão, pendrive. Ou seu próprio corpo, quero dizer, biometria digital e facial. Ou na maioria das situações, a boa e velha SENHA. Sendo assim, vamos direto ao ponto e ver como a Ansible pode ajudá-lo a proteger seus segredos.

>_ Ansible Vault: O QUE É?

Considerado por uns uma ferramenta, por outros um utilitário, e por mim uma linha de comando, o fato é que ele é responsável por criptografar variáveis e arquivos (senhas, chaves, etc) e prepará-los para o uso em playbooks e roles. Totalmente o oposto do que fizemos até agora, que foi deixá-los em texto plano. Para isso você precisará de uma ou mais senhas para cifrar e decifrar conteúdo. Na prática, a capacidade do mesmo vai muito além do que gerar apenas novos arquivos e formatos criptografados, pois ele é também capaz de proteger o conteúdo de variáveis e arquivos pré-existentes. Para os insatisfeitos, ou melhor exigentes, depois que os criar você ainda pode reeditá-los quantas vezes quiser. E por último, ele também é usado para visualizar o conteúdo após informado a senha que irei chamar a partir de agora de VAULT (ou senha vault, se preferir).

>_ Gerenciando senhas

Uma senha vault será sempre uma string. Número, letras, maiúsculas, minúsculas … A escolha é sua. Você decide! Contudo, nunca é demais definir algumas estratégias. A primeira delas talvez seja a seguinte: a mesma senha utilizada para criar/proteger determinado arquivo/variável, será a mesma para decifrá-los. Então, NUNCA, JAMAIS esqueça a mesma. A segunda estratégia seria optar por dois possíveis caminhos: usar uma única senha? Ou múltiplas? Pense nisso!

>_ Utilizando uma senha

Para times pequenos e que não tenham tanto dados sensíveis, a recomendação é usar apenas uma para criptografar tudo. Seja na sua mente (o famoso verbo “decorar”) ou em um gerenciador de senhas, é importante armazená-la de forma segura. Por exemplo:

ansible-vault create secure.yml
Figura 01. create
Figura 02. type something
Figura 03. ls -l | grep

>_ Utilizando várias senhas

Para equipes maiores e muitos dados críticos, recomenda-se duas ou mais senhas. Por exemplo, senhas diferentes para diferentes usuários. Ou ainda, senhas distintas para cada ambiente. Ou quem sabe, (a mais difícil) uma senha para cada arquivo ou pasta. Esta última não recomento por ser complexa além do necessário!!!

ansible-vault create --vault-id victor@prompt user.yml
Figura 04. vault-id = label@source
Figura 05. type some password
Figura 06. ls -l | grep

Ao final, podemos visualizar o conteúdo de ambos, simplesmente usando o comando CAT:

Figura 07. cat

Observem que a única diferença entre os dois é que um tem LABEL e o outro não.

>_ Gerenciando IDs

Nos casos de múltiplas senhas, você pode diferenciá-las umas das outras através do parâmetro --vault-id Para isso, escolha um de três caminhos …

>_ Com o comando ANSIBLE-VAULT

Assim que criar um novo conteúdo encriptado, passe o argumento no formato label@source Aonde label seria um nome qualquer dado por você mesmo, e source seria a maneira como está armazenando suas senhas (ex: prompt, file.txt ou script.py)

ansible-vault create --vault-id client1@prompt password.yml
Figura 08. create
Figura 09. type here

>_ Com o comando ANSIBLE-PLAYBOOK

Ao rodar um playbook que referencia um arquivo .YML contendo uma senha, você deverá informar a vault que utilizou para criptografar o segundo. Por exemplo:

ansible-playbook --ask-vault-pass email.yml

Aonde email.yml contém o seguinte:

---
- hosts: localhost
  vars_files: secret.yml
  tasks:
  - name: Sending an email using Ansible
    mail:
      host: smtp.gmail.com
      port: 587
      username: [email protected]
      password: "{{ p }}"
      to: [email protected]
      subject: Email By Ansible
      body: Test successful
      delegate_to: localhost

E secret.yml apresenta a senha do usuário:

p: 'password'

Por fim, a senha vault que você definiu para a arquivo segredo:

ansible-vault encrypt secret.yml
Figura 10. encrypt

Agora sim, você poderá rodar o playbook solicitando a senha vault:

ansible-playbook --ask-vault-pass email.yml
Figura 11. running … success

Vejam só, e-mail recebido com êxito!

Figura 12. inbox

Para mais informações de como configurar o seu Gmail para acesso de aplicativos e terceiros, leia aqui

>_ Com o chaveiro do sistema (system-keyring) usando SCRIPT-CLIENT.PY

Todos os passos e etapas para armazenar senhas com python e chaveiro do sistema, confira aqui e aqui

>_ Encriptando conteúdo desprotegido

Já escolheu a sua estratégia para gerenciar e armazenar senhas vault? Pois muito bem, então é hora de começar a criptografar todo e qualquer conteúdo sensível e que foi criado previamente. Lembrando sempre que o Ansible VAULT só consegue cifrar dois tipos: variáveis e arquivos. Toda vez que algo é cifrado, será anexado a tag !vault para informar ao Ansible e YAML que há necessidade de descriptografia futuramente. A presença do caractere pipe ( | ) indica duas ou mais linhas. Conteúdos que foram protegidos com o parâmetro --vault-id também conterão uma LABEL (etiqueta, descrição)

Detalhes sobre o processo de criptografia e formatos protegidos, acesse aqui

>_ Cifrando variáveis individuais

Vamos supor um arquivo de configuração simples, de nome credentials Seu conteúdo é basicamente LOGIN e SENHA:

username: admin
password: Pa55w0rD

O nome de usuário não é uma informação tão sigilosa assim, e por isso queremos deixá-la visível, em texto plano. Para isso, cifraremos apenas o campo password, da seguinte maneira:

ansible-vault encrypt_string 'Pa55w0rD' --name 'password'
Figura 13. var ‘password’

A saída mostra que a senha presente no arquivo (não confunda com a senha vault que você digitou … uma coisa é uma coisa, outra coisa é outra coisa!!!) foi criptografada usando o algoritmo AES 256. Sendo assim, copie todo o código selecionando desde !vault | até o final. Depois retorne ao arquivo de configuração e apague a informação, substituindo pelo novo conteúdo.

nano credentials
Figura 14. nano edit

Reforçando, somente neste caso não precisamos utilizar o comando ansible-vault encrypt para proteger todo o arquivo, ou tampouco o comando ansible-vault edit para editá-lo, muito menos o ansible-vault view para enxergar o seu conteúdo. Não, a ideia aqui é apenas cifrar uma pequena parte de um arquivo ou playbook em questão.

Todavia, ainda persiste uma falha de segurança. Qualquer atacante teria acesso a essa string bastando usar o comando history Veja a seguir:

Figura 15. history

Para contornar tal brecha, ao invés do comando anterior, execute o seguinte:

ansible-vault encrypt_string --stdin-name 'password'
Figura 16. prompt: –stdin-name

Pressionado o ENTER, digite a vault anterior (ou informe uma nova). Confirme a mesma, e depois digite a senha presente no arquivo/playbook. Muito importante: não aperte ENTER novamente! Para concluir, pressione CRTL-D duas vezes!!!

>_ Visualizando variáveis

Sempre poderemos listar o conteúdo original de uma variável utilizando o módulo debug

ansible localhost -m ansible.builtin.debug -a var="password" -e "@credentials" --vault-id @prompt
Figura 17. debug

>_ Cifrando arquivos existentes

Já vimos que create adiciona arquivos novos. E os que já existem? Fácil, ansible-vault encrypt … E o melhor, ele é capaz de operar em vários arquivos de uma vez só:

ansible-vault encrypt foo.yml bar.yml test.yml
Figura 18. encrypt

>_ Visualizando arquivos

Para ver o conteúdo sem ter que editar, use o view

ansible-vault view foo.yml bar.yml test.yml
Figura 19. view

>_ Modificando arquivos

Para editar o conteúdo, use o edit

ansible-vault edit foo.yml
Figura 20. edit

>_ Mudando a senha e/ou o ID de arquivos

Nesse caso, use o rekey

ansible-vault rekey foo.yml bar.yml test.yml
Figura 21. rekey
ansible-vault rekey --vault-id preprod1@ppold --new-vault-id preprod2@prompt foo.yml bar.yml test.yml

>_ Descriptografando arquivos

Use o decrypt

ansible-vault decrypt foo.yml bar.yml test.yml
Figura 22. decrypt

>_ Como utilizar conteúdo criptografado

>_ Passando uma única senha

Para digitar (solicitar) uma senha, use:

ansible-playbook --ask-vault-pass site.yml

Para recuperar (solicitar) uma senha padrão (não-vault) dentro de arquivos, use:

ansible-playbook --vault-password-file /path/to/my/vault-password-file site.yml

Para pegar uma senha padrão dentro de scripts, use:

ansible-playbook --vault-password-file my-vault-password-client.py

>_ Passando Vault-IDs

Você também pode usar a opção --vault-id para passar uma única senha com seu rótulo (label). Essa abordagem é mais clara quando vários cofres são usados em um único inventário.

Para solicitar a senha do ID ‘dev’:

ansible-playbook --vault-id dev@prompt site.yml

Para recuperar a senha do ID ‘dev’ dentro do arquivo dev-password

ansible-playbook --vault-id dev@dev-password site.yml

Para obter a senha do ID ‘dev’ dentro do script my-vault-password-client.py

ansible-playbook --vault-id [email protected]

>_ Passando várias senhas

Se sua tarefa ou playbook exigir várias variáveis criptografadas ou arquivos que você criptografou com diferentes IDs de cofre, você deve usar a opção --vault-id, passando várias opções –vault-id para especificar os IDs de cofre (‘dev’, ‘prod ‘, ‘cloud’, ‘db’) e fontes para as senhas (prompt, arquivo, script). . Por exemplo, para usar uma senha ‘dev’ lida de um arquivo e ser solicitada a senha ‘prod’:

ansible-playbook --vault-id dev@dev-password --vault-id prod@prompt site.yml

Por padrão, os rótulos de ID do cofre (dev, prod e assim por diante) são apenas dicas. O Ansible tenta descriptografar o conteúdo do cofre com cada senha. A senha com o mesmo rótulo dos dados criptografados será tentada primeiro, depois disso cada segredo do cofre será tentado na ordem em que foram fornecidos na linha de comando.

Quando os dados criptografados não tiverem rótulo ou o rótulo não corresponder a nenhum dos rótulos fornecidos, as senhas serão testadas na ordem em que forem especificadas. No exemplo acima, a senha ‘dev’ será tentada primeiro, depois a senha ‘prod’ para casos em que o Ansible não sabe qual ID do cofre é usado para criptografar algo.

REFERÊNCIAS:

https://docs.ansible.com/ansible/latest/user_guide/vault.html

https://docs.ansible.com/ansible/latest/cli/ansible-vault.html

https://www.redhat.com/sysadmin/introduction-ansible-vault

https://www.digitalocean.com/community/tutorials/how-to-use-vault-to-protect-sensitive-ansible-data

https://www.linuxtechi.com/use-ansible-vault-secure-sensitive-data/

Deixe uma resposta

Este site utiliza o Akismet para reduzir spam. Saiba como seus dados em comentários são processados.