Guia para Proteger Segredos de Configuração Usando Ansible Vault de Forma Eficaz

O Ansible Vault ajuda a manter segredos de configuração fora de texto simples enquanto ainda usa variáveis normais do Ansible. Se seus playbooks contêm senhas de banco de dados, chaves de API ou chaves privadas, comprometê-los não criptografados pode transformar um vazamento de repositório rotineiro em um incidente de infraestrutura.

O Ansible Vault criptografa arquivos de variáveis estruturadas ou valores individuais e os descriptografa apenas quando o Ansible tem a senha do vault. Este guia mostra os comandos que você realmente usará, como carregar variáveis protegidas por vault em playbooks e onde as equipes geralmente cometem erros.

Compreendendo os Conceitos Principais do Ansible Vault

O Ansible Vault usa criptografia simétrica forte (AES256) para proteger dados. O mecanismo central requer uma Senha do Vault que atua como a chave mestra. Esta senha deve ser fornecida ao Ansible sempre que ele precisar acessar ou modificar conteúdo criptografado.

Por que Usar Ansible Vault?

Segurança: Mantém dados sensíveis criptografados em repouso, protegendo contra violações de repositório.
Conformidade: Ajuda a atender padrões da indústria (ex.: PCI DSS, SOC 2) que exigem criptografia de credenciais.
Fluxo de Trabalho: Permite que arquivos de configuração contendo segredos sejam comprometidos com segurança em sistemas de controle de versão (como Git).

Comandos Essenciais do Ansible Vault

O comando ansible-vault é um utilitário independente usado para gerenciar arquivos criptografados fora de uma execução de playbook.

1. Criando um Novo Arquivo Protegido por Vault

Para criar um novo arquivo destinado especificamente a segredos, use o comando create. Isso imediatamente solicita uma nova senha do vault e então abre o arquivo em seu editor de texto padrão ($EDITOR).

ansible-vault create secrets/db_passwords.yml

Exemplo de Conteúdo (db_passwords.yml após salvar):

# Este arquivo está criptografado
db_user: app_admin
db_pass: HighlySecurePassword123!
api_key: abc-123-def-456

Após salvar e fechar o editor, o conteúdo é criptografado e o arquivo está pronto para ser comprometido no controle de versão.

2. Visualizando Conteúdo Criptografado

Se você precisar inspecionar rapidamente o conteúdo de um arquivo protegido por vault sem editá-lo, use o comando view. Você será solicitado a fornecer a senha do vault.

ansible-vault view secrets/db_passwords.yml

3. Editando um Arquivo Protegido por Vault Existente

O comando edit é a principal maneira de modificar segredos. O Ansible descriptografa o arquivo, abre-o em seu editor e, ao salvar, re-criptografa o arquivo automaticamente.

ansible-vault edit secrets/db_passwords.yml

Dica: Certifique-se de que sua variável de ambiente $EDITOR esteja configurada corretamente (ex.: export EDITOR=vim) para uma experiência de edição suave.

4. Criptografando e Descriptografando Arquivos Existentes

Se você tem um arquivo de texto simples existente que precisa ser protegido, use o comando encrypt. Por outro lado, decrypt é usado para reverter um arquivo criptografado de volta para texto simples (usado com cautela, geralmente para migração).

# Criptografar um arquivo existente
ansible-vault encrypt plain_vars.yml

# Descriptografar um arquivo protegido por vault existente (Perigoso! Use apenas se necessário)
ansible-vault decrypt secured_vars.yml

5. Alterando a Senha do Vault (Rekey)

Para atualizar a senha mestra de um arquivo protegido por vault, use o comando rekey. Isso requer que você forneça a senha atual e então defina uma nova.

ansible-vault rekey secrets/db_passwords.yml

Isso é essencial para rotações de segurança ou ao fazer a transição para um novo sistema de gerenciamento de credenciais.

Integrando Segredos Protegidos por Vault em Playbooks do Ansible

Uma vez que os arquivos estão criptografados, você precisa de um método para carregá-los durante a execução do playbook e fornecer a senha do vault necessária.

Carregando Variáveis Criptografadas

Arquivos de variáveis criptografadas são carregados como qualquer outro arquivo de variável, normalmente usando a diretiva vars_files em seu playbook.

Exemplo de Playbook (site.yml):

---
- name: Implantar aplicação que requer segredos de banco de dados
  hosts: webservers
  vars_files:
    - secrets/db_passwords.yml  # Ansible detecta automaticamente que está protegido por vault

  tasks:
    - name: Garantir que o usuário do banco de dados esteja configurado
      ansible.builtin.template:
        src: config.j2
        dest: /etc/app/config.conf
        mode: '0600'
      # Variáveis como {{ db_user }} e {{ db_pass }} agora estão disponíveis

Fornecendo a Senha do Vault Durante a Execução

O Ansible oferece vários métodos seguros para fornecer a senha do vault sem deixá-la exposta no histórico ou em scripts.

Método 1: Prompt Interativo

O método mais simples é usar a flag --ask-vault-pass, que solicita ao usuário a senha de forma segura em tempo de execução.

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

Método 2: Usando um Arquivo de Senha

Para automação, pipelines CI/CD ou ambientes onde prompts interativos são indesejáveis, você pode usar um arquivo de senha em texto simples (geralmente armazenado fora do repositório principal e protegido por permissões de arquivo restritivas).

# Nota: O arquivo de senha DEVE conter APENAS o texto da senha do vault.
ansible-playbook site.yml --vault-password-file ~/.ansible/vault_key.txt

Método 3: Criptografando Variáveis Únicas (`encrypt_string`)

Se você só precisa criptografar uma única variável pequena (ex.: em um arquivo inventory) em vez de um arquivo YAML inteiro, use ansible-vault encrypt_string.

# Use 'echo' ou 'printf' para passar o segredo diretamente
ansible-vault encrypt_string 'MySuperSecretAPIKey' --name 'prod_api_key'

Este comando gera a string criptografada que pode ser colada diretamente em um inventário ou arquivo de variável:

prod_api_key: !vault |
  $ANSIBLE_VAULT;1.1;AES256
  37666236613364656165386638323438646132646337326462613134373463353434613861313361
  ... (resto dos dados criptografados)

Melhores Práticas para Gerenciamento de Vault Empresarial

O gerenciamento eficaz de segredos vai além de simplesmente criptografar um arquivo. Adotar estas melhores práticas garante segurança e capacidade de manutenção:

1. Arquivo de Senha do Vault Dedicado

Sempre use o método --vault-password-file em ambientes automatizados. O arquivo contendo a senha deve ter permissões extremamente restritivas (chmod 400) e nunca deve ser comprometido no Git.

2. Segregação de Ambientes

Use arquivos de vault separados para diferentes ambientes (Desenvolvimento, Staging, Produção). Isso impede que ambientes de baixo risco acessem credenciais de produção de alto risco.

vars/prod_vault.yml
vars/stage_vault.yml

Carregue esses arquivos condicionalmente usando grupos de inventário ou lógica condicional em seus playbooks.

3. Use Armazenamentos Externos de Segredos Quando o Vault Não For Suficiente

Para ambientes maiores, considere armazenamentos externos de segredos como HashiCorp Vault, AWS Secrets Manager ou gerenciamento de chaves nativo da nuvem. Os plugins de lookup do Ansible podem buscar esses valores em tempo de execução, enquanto o Ansible Vault permanece útil para pequenos segredos, valores de inicialização ou equipes que ainda não têm uma plataforma de segredos dedicada.

4. Variáveis de Grupo vs. Variáveis de Playbook

Muitas vezes é mais limpo armazenar variáveis protegidas por vault em group_vars ou host_vars usando nomes de arquivo de variável normais. O Ansible descriptografa o conteúdo protegido por vault quando o arquivo é carregado; a extensão é apenas uma convenção, não o recurso que aciona a descriptografia.

# Exemplo de estrutura
inventory/
├── hosts
└── group_vars/
    └── webservers/
        └── vault.yml

Mantenha o Vault Prático

Comece criptografando os segredos que seus playbooks já carregam, depois padronize como sua equipe fornece a senha do vault. Mantenha a senha do vault fora do Git, separe segredos de produção de ambientes inferiores e gire a senha com ansible-vault rekey quando o acesso mudar.