Como posso gerenciar segredos em .tf e .tfstate?

Eu gostaria de usar o Terraform MySQL Provider para manter uma lista de usuários mysql e concessões úteis para criar novos ambientes de teste. Os arquivos .tfe .tfstateparecem querer armazenar as senhas do MySQL em texto sem formatação.

Em relação a .tf:

Entendo que os .tfarquivos vivem no controle de revisão e são mantidos por uma equipe. Como essa prática difere quando existem segredos .tf? É possível criptografar esses valores?

Em relação a .tfstate:

Posso armazenar o arquivo em .tfstatesegurança em algum lugar depois de executar o Terraform apply, mas seria preferível que este caso de uso não o armazene?

O Terraform suporta a adição de um arquivo adicional com variáveis ​​durante a invocação.

^{documentação: https://www.terraform.io/intro/getting-started/variables.html#from-a-file}

Estamos usando esse recurso para fornecer um secrets.tfvarsarquivo em cada chamada do Terraform. Também usamos um script para agrupar o comando, para que sua chamada seja consistente e todos os membros da equipe evitem cometer os mesmos erros. O wrapper é sincronizado .tfstatecom o S3 antes de uma execução e .tfstateretorna ao S3 no final. Também ouço pessoas fazendo o mesmo com o estado armazenado no Consul, até adicionando um tipo de semáforo no consul para impedir que duas pessoas iniciem o Terraform ao mesmo tempo.

Quando você evita definir um valor padrão em um variables.tfarquivo, ele força o usuário a inserir o valor. Pode ser inserido manualmente ou usando a -var-fileopção de comando como descrito acima. Não definir um padrão em seus segredos é uma boa maneira de impor alterações que exigem uma alteração em segredos.

O secrets.tfvarsarquivo é um link simbólico para um dos arquivos com segredos que não são armazenados no controle de versão. Temos vários, um por ambiente, como assim secrets-prod.tfvars, secrets-dev.tfvars, secrets-stg.tfvars, etc ...

Uma prática ainda melhor seria gerar esses arquivos secretos durante o script do wrapper com base nos dados do Vault ou em alguma outra maneira de compartilhar segredos. Como atualmente, quando o formato dos segredos muda, ou eles mesmos, precisamos comunicá-lo à equipe fora do canal de controle de versão - e isso nem sempre funciona bem, para ser sincero. Mas os segredos mudam com pouca frequência.

Evitamos que terraform lide com nossos segredos. Mesmo que você consiga injetar segredos por um arquivo var "secrtes.tfvars", como apontado acima, esses segredos serão armazenados no seu estado de terraform (remoto).

Você pode proteger arquivos de estado remoto usando, por exemplo, autorização S3, ou pode ignorar arquivos de estado local, mas decidimos não confiar nesse tipo de proteção.

Se você estiver na AWS, consulte "O caminho certo para gerenciar segredos", de Segment.io no Blog da AWS. Defendemos o uso chamberde todos os nossos clientes para gerenciar segredos. Ele funciona aproveitando o AWS Systems Manager Parameter Store (SSM) junto com as chaves KMS. Isso garante que os segredos sejam criptografados em repouso (e em trânsito), protegidos com o IAM, auditáveis ​​com CloudTrails e expostos apenas como variáveis ​​de ambiente em tempo de execução.

Depois de configurar a câmara e configurar a chave KMS, escrevemos os segredos no armazenamento de parâmetros.

chamber write db TF_VAR_DB_USER foobar
chamber write db TF_VAR_DB_PASS secret

Em seguida, use esses segredos ao chamar terraform.

chamber exec db -- terraform plan

Isso pressupõe que você definiu uma variável chamada DB_USERe DB_PASSno seu código HCL.

Por exemplo, você pode adicionar isso a variables.tf

variable "DB_USER" { }
variable "DB_PASS" { }

NOTA: chamber sempre exportará variáveis ​​de ambiente em maiúsculas

Fornecemos um módulo de terraform chamado terraform-aws-kms-keypara facilitar o provisionamento da chave KMS. Confira nossa documentação detalhada com exemplos de como usar chambercom vários espaços para nome, bem como como usar câmara com terraform para gerenciar segredos. Veja nosso exemplo de referência completo para provisionar dependências da câmara.

Quanto a .tfstate, você traz um ponto realmente bom sobre a existência de segredos de texto sem formatação no arquivo de estado. Realmente não há maneira de contornar isso. Para que o terraform calcule as mudanças para criar um plano, ele precisa conhecer o estado "antes" e "depois". Por esse motivo, recomendamos o uso de um bucket S3 criptografado com controle de versão obrigatório. Use o terraform-aws-tfstate-backendmódulo para provisionar um balde e a tabela de bloqueio do DynamoDB de acordo com as melhores práticas.

Para importar segredos para arquivos .tf, você também pode usar uma fonte de dados externa . Pode ser, por exemplo, um script que decifra seus segredos.

Eu olhei para algumas maneiras diferentes, mas gostei particularmente do git-crypt por algo adhoc antes de implementar algo maior como o Vault.