Terraform MCP Server 1.0: IA Gera Configurações com Base em Provedores Atualizados – Mas Cuidado com Produção

Qualquer pessoa que já pediu ao ChatGPT ou Claude para gerar uma configuração Terraform conhece o padrão: o modelo escreve confiantemente HCL que estava atualizado há um ano. Ele pode incluir argumentos depreciados em versões anteriores do provedor ou referências a recursos renomeados em lançamentos passados. A razão é simples: o conhecimento do modelo é limitado ao seu treinamento, enquanto o Terraform Registry evolui semanalmente.

Em 11 de junho de 2024, a HashiCorp (agora sob a égide da IBM) lançou o Terraform MCP Server 1.0 em GA (General Availability). Este é o servidor MCP oficial que oferece a assistentes de IA acesso direto ao Terraform Registry. Isso significa acesso a documentação de provedores, módulos e políticas atualizadas no momento da consulta, em vez de depender de dados de treinamento desatualizados. Vamos analisar o que ele realmente faz, como configurar um ambiente de teste rapidamente e onde é absolutamente crucial não permitir que o agente acesse a infraestrutura sem supervisão.

Por que uma Camada Intermediária entre LLM e o Registry?

MCP (Model Context Protocol) é um padrão aberto da Anthropic que permite que modelos de IA interajam com ferramentas externas. A teoria é direta: há um host (como Claude Desktop, Cursor, VS Code), um cliente MCP dentro dele e um servidor que fornece as ferramentas. O que é mais importante é o que o servidor coloca no contexto do modelo. O Terraform MCP Server não "aplica o Terraform para você". Em vez disso, ele fornece ao modelo um conjunto de ferramentas que a IA usa quando você solicita a criação ou modificação de uma configuração. Essas ferramentas incluem:

• search_providers: Para encontrar provedores no registro.
• get_provider_details: Para extrair a documentação atualizada sobre recursos e argumentos.
• get_latest_provider_version: Para verificar a versão mais recente de um provedor.
• search_modules / get_module_details: Para acessar módulos, seus inputs/outputs e exemplos.
• Busca por políticas Sentinel para governança e conformidade.

As ferramentas são agrupadas em três conjuntos (registry, registry-private e terraform) e podem ser ativadas ou desativadas com o flag --toolsets. Isso é conveniente: para desenvolvimento local, o registry público é suficiente, e o terraform (para operações no workspace no HCP/TFE) pode nem ser necessário.

Sem MCP vs. Com MCP: O Impacto na Prática

A maneira mais eficaz de demonstrar o valor do MCP Server é comparar o mesmo prompt em um cenário sem e com acesso ao registro. Um exemplo clássico é a criação de um bucket S3. Um modelo sem acesso ao registro provavelmente gerará um código no estilo antigo:

hcl
# O que uma LLM escreveria de memória - estilo depreciado no provedor AWS v4
resource "aws_s3_bucket" "data" {
  bucket = "my-data"
  acl    = "private"
  versioning {
    enabled = true
  }
}

Isso apresenta um duplo problema. Primeiro, acl e versioning dentro de aws_s3_bucket foram depreciados e movidos para recursos separados a partir da quarta versão do provedor. Segundo, e frequentemente esquecido: desde 2023, o S3 desabilita ACLs por padrão (Bucket Owner Enforced), tornando a privacidade o estado padrão. Um aws_s3_bucket_acl separado com private em um bucket recém-criado simplesmente falhará.

Um modelo que utiliza o MCP para acessar search_providers e get_provider_details para obter a documentação atualizada não incluirá um recurso ACL para um bucket privado. A configuração moderna e correta seria:

hcl
resource "aws_s3_bucket" "data" {
  bucket = "my-data"
}

resource "aws_s3_bucket_versioning" "data" {
  bucket = aws_s3_bucket.data.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_public_access_block" "data" {
  bucket                  = aws_s3_bucket.data.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

A diferença não é que o modelo "ficou mais inteligente", mas sim que ele parou de adivinhar e buscou fatos. O efeito é mais notável para provedores menos comuns e versões principais recentes, onde os dados de treinamento são escassos.

Configuração Rápida em Cinco Minutos

O servidor é executado em um contêiner Docker e suporta dois transportes: stdio (local) e streamable-http (remoto). Para o registro público, nenhum token é necessário. Para iniciar localmente:

bash
docker run -i --rm hashicorp/terraform-mcp-server

Para conectar a um host (exemplo para configurações baseadas em MCP em Claude Desktop, Cursor, VS Code agent mode):

json
{
  "mcpServers": {
    "terraform": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "hashicorp/terraform-mcp-server"]
    }
  }
}

Com isso configurado, o modelo pode encontrar e chamar as ferramentas necessárias automaticamente quando você solicita HCL.

HCP Terraform e Enterprise: Registry Privado no Contexto do Modelo

Embora o registro público seja útil, o verdadeiro valor para as equipes reside na parte privada. Ao configurar TFE_TOKEN e TFE_ADDRESS, você expõe seu registro privado ao contexto do modelo, incluindo módulos internos com sua documentação, provedores, organizações e workspaces.

bash
docker run -i --rm \
  -e TFE_ADDRESS=https://app.terraform.io \
  -e TFE_TOKEN=*** \
  hashicorp/terraform-mcp-server

No modo HCP/TFE, operações sobre workspaces, variáveis, tags e runs estão disponíveis. Um ponto crucial aqui é que operações destrutivas são desabilitadas por padrão. apply, destroy, auto-approve e parte das operações de run estão ocultas atrás do flag ENABLE_TF_OPERATIONS, que por padrão é false. Este é o comportamento correto. No entanto, não se engane: o que o agente pode ler e modificar é determinado pelas permissões do TFE_TOKEN, não apenas por este flag. Portanto, o princípio do menor privilégio no token não é uma opção, mas uma necessidade.

Segurança: Onde a Supervisão é Obrigatória

A HashiCorp lista honestamente as ameaças em sua documentação, e é essencial lê-la antes de conectar o servidor a um token de produção. Além das alucinações comuns, existem riscos como prompt injection, tool poisoning e rug pull (onde uma ferramenta muda de comportamento após ganhar confiança) e tool shadowing. Isso significa que não é uma ferramenta "segura por design", mas sim uma que requer restrições.

Um checklist prático para evitar ter que explicar por que o agente derrubou o ambiente de staging:

• Permissões mínimas do token: O TFE_TOKEN deve conceder ao assistente apenas o acesso estritamente necessário. Nada de "darei o token de administrador e depois resolvo".
• ENABLE_TF_OPERATIONS=false: Mantenha este flag desativado, a menos que você decida conscientemente o contrário. Operações destrutivas devem ser tratadas separadamente e com tokens dedicados.
• Não exponha o registry privado a agentes genéricos: Módulos internos são um mapa da sua infraestrutura.
• Nunca use TFE_SKIP_TLS_VERIFY=true em produção.
• Para remote (streamable-http), use TLS: Configure MCP_TLS_CERT_FILE / MCP_TLS_KEY_FILE, CORS rigoroso, listas de IP permitidos e limites de taxa integrados (o padrão MCP_RATE_LIMIT_GLOBAL é 10:20, MCP_RATE_LIMIT_SESSION é 5:10). Para uso local, stdio ou 127.0.0.1 são suficientes.
• Observabilidade: No modo streamable-http, o servidor pode expor métricas OTel (OTEL_METRICS_ENABLED) sobre chamadas de ferramentas, latência e erros. Para implantações em produção, isso é higiene essencial.

Armadilhas Comuns

• Contexto volumoso: A documentação de provedores robustos como AWS consome muitos tokens. Um agente que acessa o registro ativamente pode consumir contexto e custos mais rapidamente do que o esperado.
• Rate limits do Registry: Um agente preso em um loop de busca pode atingir os limites de API do registro.
• Dependência do ecossistema HashiCorp: O servidor é oficialmente otimizado para o Terraform Registry e HCP/TFE. OpenTofu não é um cenário oficialmente suportado, embora a documentação de provedores/módulos do registro ainda seja útil para configurações compatíveis com HCL.

Conclusão

O Terraform MCP Server não "entrega a infraestrutura para a IA" nem "cura alucinações" – essas formulações são imprecisas. Sua função principal é eliminar a obsolescência do contexto, permitindo que o modelo gere HCL com base no esquema atual do provedor, em vez de depender de memórias desatualizadas. A revisão de código continua sendo indispensável.

Para profissionais de DevOps, esta é uma rara oportunidade de usar uma ferramenta de IA que se integra diretamente ao fluxo de trabalho, em vez de ser apenas uma demonstração. Configurar um ambiente de teste leva apenas cinco minutos com um único comando docker run. O mais importante é manter o agente sob controle rigoroso: permissões mínimas, operações destrutivas desativadas por padrão e uma compreensão clara do modelo de ameaças antes de qualquer incidente.

Você permitiria que um agente acessasse seu registry privado – e com quais permissões?