Como proteger o arquivo de estado do Terraform contra a exposição inadvertida de segredos em pipelines CI/CD

O Terraform se tornou a principal referência em Infraestrutura como Código (IaC) para provisionar e gerenciar recursos em nuvem. Para manter o rastreamento dos recursos reais criados em provedores como AWS, Azure e Google Cloud, a ferramenta utiliza o arquivo de estado (terraform.tfstate).

Contudo, existe um aspecto crítico no funcionamento interno do Terraform: por design, o arquivo de estado armazena em texto claro todas as propriedades dos recursos gerenciados. Isso significa que senhas de banco de dados, chaves de API, certificados TLS e tokens de acesso passados aos módulos ficam expostos diretamente no JSON do estado, mesmo quando marcados com o parâmetro sensitive = true.

Em pipelines de Integração Contínua e Entrega Contínua (CI/CD), onde execuções do Terraform ocorrem de forma automatizada em runners compartilhados ou temporários, a exposição desse arquivo representa um grande risco de segurança. Neste artigo, abordamos as práticas fundamentais para isolar, criptografar e proteger o estado do Terraform contra vazamentos acidentais.

Por que o Terraform armazena segredos no estado?

Para determinar se a infraestrutura sofreu alterações não planejadas (drift), o Terraform precisa comparar o estado atual dos recursos remotos com o que está definido no código e com a última fotografia salva no arquivo .tfstate.

Quando uma propriedade exige uma credencial — como a senha mestre de uma instância de banco de dados —, o Terraform registra essa informação no estado para validar, em execuções futuras, se o valor mudou. A diretiva sensitive = true instrui a ferramenta a omitir o valor nos logs exibidos no terminal durante o terraform plan ou terraform apply, mas não altera o modo como o dado é gravado no estado final.

Estratégias essenciais para proteger o tfstate em CI/CD

Para impedir a exposição inadvertida do estado e dos segredos contidos nele, é necessário implementar defesas em camadas no ciclo de vida do pipeline.

1. Elimine o estado local e reforce o .gitignore

O erro mais elementar é permitir que o arquivo de estado seja salvo localmente no ambiente de execução do runner e, em seguida, enviado acidentalmente ao controle de versão (Git).

Adicione explicitamente as seguintes regras ao arquivo .gitignore de todos os seus repositórios de infraestrutura:

```gitignore

Arquivos de estado do Terraform

.tfstate .tfstate. .tfvars *.tfvars.json

Diretório de trabalho local do Terraform

.terraform/ ```

2. Configure backends remotos com criptografia em repouso e em trânsito

Em pipelines CI/CD, o estado nunca deve permanecer na máquina que executou o job. Ele deve ser armazenado em um backend remoto centralizado, configurado com políticas de acesso restritas e criptografia ativada.

Ao utilizar serviços como Amazon S3, Azure Blob Storage ou Google Cloud Storage como backend, certifique-se de habilitar:

• Criptografia do lado do servidor (SSE): exija a criptografia de arquivos em repouso usando chaves gerenciadas por um cofre (ex.: AWS KMS).
• Criptografia em trânsito: exija HTTPS/TLS para todas as interações com o bucket de estado.
• Bloqueio de acesso público: impeça qualquer leitura não autenticada no armazenamento de estado.

Exemplo de configuração de backend remoto no Amazon S3 com suporte a criptografia via KMS e bloqueio por DynamoDB:

hcl terraform { backend "s3" { bucket = "empresa-tfstates-prod" key = "infra/database/terraform.tfstate" region = "us-east-1" encrypt = true kms_key_id = "arn:aws:kms:us-east-1:123456789012:key/exemplo-chave-kms" dynamodb_table = "terraform-locks" } }

3. Autenticação efêmera no CI/CD via OIDC

Evite salvar credenciais de longa duração de provedores de nuvem (como chaves de acesso AWS ou segredos do Azure) nas variáveis de ambiente do seu sistema de CI/CD (GitHub Actions, GitLab CI ou Azure DevOps).

A abordagem recomendada é configurar o OpenID Connect (OIDC). O OIDC permite que o runner assuma uma função (role) temporária na nuvem com permissões restritas apenas pelo tempo em que o job do pipeline estiver em execução.

4. Reduza a dependência de segredos estáticos com credenciais dinâmicas

A melhor forma de proteger um segredo presente no arquivo de estado é garantir que ele expire rapidamente. Ao integrar o Terraform a soluções de gerenciamento de segredos, como o HashiCorp Vault ou cofres nativos da nuvem, é possível gerar credenciais dinâmicas para o banco de dados ou provedor que duram apenas alguns minutos ou horas.

Caso o arquivo de estado seja comprometido no futuro, a credencial contida nele já estará invalidada pelo cofre de segredos.

5. Criptografia nativa do estado no lado do cliente (Terraform 1.7+)

Nas versões recentes do Terraform, foi introduzido o suporte à criptografia de estado do lado do cliente (State Encryption). Essa funcionalidade permite criptografar os dados do arquivo de estado antes de enviá-los ao backend remoto.

Dessa forma, mesmo que um usuário tenha permissão de leitura no objeto bruto do S3 ou Blob Storage, não conseguirá ler o conteúdo do .tfstate sem a chave de descriptografia apropriada configurada no ambiente do Terraform.

6. Higiene na configuração do runner e dos artefatos de build

Inspecione o comportamento do seu pipeline de CI/CD para impedir vazamentos secundários:

• Evite salvar a pasta .terraform/ como artefato do job: alguns pipelines exportam automaticamente diretórios de trabalho como artefatos de build para jobs seguintes. Se o arquivo de estado temporário estiver contido ali, ele ficará disponível para download por usuários do sistema de CI/CD.
• Mascaramento de variáveis de saída: garanta que os logs de execução não imprimam o conteúdo de variáveis de ambiente do CI/CD.
• Isolamento de privilégios no repositório: restringir quem pode aprovar e executar pipelines na ramificação principal (main/master) impede que modificações maliciosas em scripts leiam a memória do runner.

Checklist de segurança do estado no Terraform

• [ ] Arquivos .tfstate listados no .gitignore.
• [ ] Backend remoto configurado com criptografia em repouso e TLS obrigatório.
• [ ] Autenticação do pipeline realizada por federação de identidade (OIDC) sem chaves estáticas.
• [ ] Acesso ao bucket de estado restrito pelo princípio do menor privilégio.
• [ ] Artefatos do pipeline revisados para garantir que nenhuma cópia local do estado seja mantida após a execução.