What Is Terraform MCP? AI Agents Meet Terraform

Nếu bạn đã dùng AI agent (trợ lý AI, ví dụ Claude Code, Cursor, Gemini CLI) để viết code application, câu hỏi tự nhiên tiếp theo là: có dùng được cho hạ tầng (infrastructure) không? Terraform là công cụ Infrastructure as Code (IaC — hạ tầng dưới dạng code) phổ biến nhất hiện nay, và Terraform MCP (Model Context Protocol) server là cầu nối để AI agent "nói chuyện" trực tiếp với Terraform CLI, state file, và registry provider/module — thay vì agent phải đoán cú pháp HCL hay copy-paste output plan bằng tay. Bài này sẽ đi từ zero: Terraform MCP là gì, có tool nào, setup ra sao, và quan trọng nhất — ranh giới nào AI agent không được vượt qua khi làm việc với hạ tầng production.

Các Terraform MCP Tool Cốt Lõi: Init, Validate, Plan, Xem State và Tra Cứu Registry

Terraform MCP server thực chất là một lớp bọc (wrapper) expose các tác vụ Terraform CLI quen thuộc thành tool calling (gọi hàm) mà LLM có thể invoke có cấu trúc, thay vì phải chạy shell command thô và tự parse text output. Bộ tool cốt lõi thường gồm:

terraform_init — khởi tạo working directory, download provider plugin, cấu hình backend. Agent gọi tool này trước khi làm bất cứ việc gì khác trong một module mới hoặc sau khi thay đổi backend config.
terraform_validate — kiểm tra cú pháp HCL và tính nhất quán nội bộ (ví dụ tham chiếu tới resource không tồn tại) mà không cần truy cập provider thật. Đây là bước rẻ, nhanh, nên chạy liên tục trong lúc agent sinh code.
terraform_plan — tính toán diff giữa state hiện tại và config mong muốn, trả về structured plan (dạng JSON qua -json hoặc terraform show -json) để agent đọc được resource nào sẽ create/update/destroy.
terraform_state_show / terraform_state_list — cho phép agent inspect state hiện tại (ví dụ để trả lời "bucket S3 này đang có versioning chưa?") mà không cần đọc trực tiếp file .tfstate (vốn có thể chứa secret ở dạng plaintext).
Registry lookup (search_providers, get_provider_docs, search_modules) — tra cứu docs của provider (AWS, GCP, Azure...) hoặc module có sẵn trên Terraform Registry, giúp agent viết đúng attribute schema mà không "bịa" argument không tồn tại (một lỗi rất phổ biến khi LLM không có tool này).

Ví dụ cấu hình MCP server trong file config của client (Claude Code, Cursor...):

{
  "mcpServers": {
    "terraform": {
      "command": "terraform-mcp-server",
      "args": ["--workdir", "./infra/prod"],
      "env": {
        "TF_LOG": "INFO"
      }
    }
  }
}

Với setup này, khi bạn prompt agent: "Kiểm tra xem module VPC hiện tại có hợp lệ không, và cho tôi biết apply sẽ thay đổi gì", agent sẽ tự động gọi terraform_validate rồi terraform_plan, đọc structured output, và tóm tắt lại bằng ngôn ngữ tự nhiên — thay vì bạn phải tự chạy terraform plan rồi copy 300 dòng output vào chat.

Mẹo: Luôn giới hạn --workdir của MCP server về đúng một thư mục module cụ thể (ví dụ ./infra/prod) thay vì root của cả monorepo. Nếu để agent có quyền truy cập toàn bộ cây thư mục infra, một prompt mơ hồ có thể khiến agent chạy plan/apply nhầm workspace, rất khó lường trước hậu quả.

Setup Terraform MCP: Backend, Workspace và Provider Credentials

Terraform MCP không tự phát minh ra cách quản lý state hay credentials — nó chỉ là lớp giao tiếp, mọi quy tắc Terraform gốc vẫn áp dụng. Ba điểm cần chuẩn hóa trước khi cho agent chạm vào:

Backend. Production nên dùng remote backend (S3 + DynamoDB lock, Terraform Cloud, hoặc GCS) để state không nằm trên máy local của agent và có locking chống race condition khi nhiều người (hoặc nhiều agent session) chạy plan đồng thời.

terraform {
  backend "s3" {
    bucket         = "acme-tfstate-prod"
    key            = "network/terraform.tfstate"
    region         = "ap-southeast-1"
    dynamodb_table = "tfstate-lock"
    encrypt        = true
  }
}

Workspace. Nếu bạn dùng Terraform workspace để tách môi trường (dev/staging/prod) trong cùng một config, cần chỉ định rõ workspace nào agent đang tương tác — tránh trường hợp agent tưởng đang ở dev nhưng thật ra CLI context đang trỏ vào prod. Cách an toàn hơn là tách hẳn thư mục root module theo môi trường (infra/dev, infra/prod) thay vì dùng workspace switch, để không có chuyện "quên switch workspace" — một lỗi con người (và agent) mắc đi mắc lại.

Provider credentials. Không bao giờ đưa AWS access key, GCP service account key trực tiếp vào biến môi trường của MCP server process nếu agent có thể đọc lại env qua tool khác. Ưu tiên:

AWS: dùng AWS_PROFILE trỏ tới credentials đã cấu hình sẵn (~/.aws/credentials) hoặc IAM role (nếu agent chạy trên máy có gắn role, ví dụ EC2/CI runner), thay vì access key dài hạn.
Giới hạn IAM policy của credentials đó theo nguyên tắc least privilege (đặc quyền tối thiểu) — role dùng cho agent chỉ nên có quyền plan (read-only: Describe*, Get*, List*) trong giai đoạn thử nghiệm, tách riêng khỏi role có quyền apply.

Mẹo: Tạo một IAM role riêng tên rõ ràng như terraform-agent-readonly chỉ có quyền đọc, dùng cho mọi session agent chạy plan. Chỉ chuyển sang role có quyền write khi một con người thật đã review plan và quyết định apply. Việc tách role này là lưới an toàn rẻ nhất bạn có thể dựng.

AI Nên Làm Gì Với IaC: Review Plan Thì Có, Apply Mù Thì Không

Đây là ranh giới quan trọng nhất của cả bài học này, nên nói thẳng luôn: AI agent nên được dùng để đọc, giải thích, và review plan — không nên được cấp quyền tự động apply thay đổi hạ tầng production.

Lý do không phải vì AI "ngu" mà vì bản chất rủi ro bất đối xứng: một application bug thường rollback được bằng cách revert deploy; một terraform apply sai — ví dụ destroy nhầm RDS instance vì thay đổi tên biến khiến Terraform coi đó là resource mới — có thể mất dữ liệu vĩnh viễn trong vài giây, không có "undo". Plan cho bạn thấy trước điều đó sẽ xảy ra, nhưng chỉ khi có người đọc kỹ.

AI agent làm rất tốt các việc sau:

Đọc plan JSON dài hàng trăm dòng và tóm tắt: "3 resource sẽ bị destroy và tạo lại (replace) do thay đổi availability_zone — đây có phải chủ ý không?"
Phát hiện pattern nguy hiểm: attribute có # forces replacement trên resource stateful (database, EBS volume) — dấu hiệu mất dữ liệu tiềm ẩn.
Giải thích cho dev junior tại sao thay đổi một security group rule lại kéo theo việc replace 5 resource khác (dependency chain).
Generate PR description tóm tắt thay đổi bằng ngôn ngữ người đọc được, kèm plan output đầy đủ để reviewer verify.

AI agent KHÔNG nên tự quyết:

Tự động chạy terraform apply -auto-approve sau khi plan xong, dù plan "nhìn có vẻ ổn".
Tự sửa lỗi apply thất bại bằng cách xóa resource khỏi state (terraform state rm) để "cho qua" — hành động này che giấu vấn đề thật, không giải quyết nó.
Tự quyết định threshold "thay đổi nhỏ thì apply luôn, thay đổi lớn thì hỏi người" — ranh giới này chủ quan và rất dễ bị agent đánh giá sai trong tình huống thực tế.

Quy tắc thực dụng: cấu hình MCP server hoặc CI pipeline sao cho tool terraform_apply (nếu có expose) luôn yêu cầu một bước approval tường minh của con người, tách biệt hoàn toàn khỏi luồng agent tự động.

Mẹo: Khi review plan cùng agent, luôn hỏi ngược lại một câu trước khi tin tưởng: "Trong plan này, resource nào có # forces replacement?" Nếu agent trả lời không có nhưng bạn tự grep thấy có, đó là dấu hiệu agent đang tóm tắt hời hợt — cần yêu cầu nó liệt kê từng resource, không tóm tắt gộp.

Bảo Vệ State File và Secrets Khỏi Nguy Cơ Agent Đọc Được

Terraform state file (.tfstate) gần như luôn chứa dữ liệu nhạy cảm ở dạng plaintext — password database khởi tạo qua random_password, private key, connection string — vì Terraform cần lưu toàn bộ attribute của resource để tính diff ở lần plan sau. Khi một AI agent có quyền đọc filesystem hoặc gọi tool terraform_state_show, nó hoàn toàn có thể vô tình "nhìn thấy" các giá trị này, và nếu context đó bị log lại hoặc gửi qua API của model provider, bạn đã vô tình leak secret.

Các lớp bảo vệ nên có:

Encrypt state at rest. Với S3 backend, luôn set encrypt = true và dùng KMS key riêng, không dùng default SSE-S3 cho state chứa secret nhạy cảm cao.
Hạn chế tool terraform_state_show với sensitive value. Terraform từ bản 0.14+ hỗ trợ đánh dấu sensitive = true cho output và variable — khi agent gọi terraform output, giá trị sensitive sẽ bị mask thành (sensitive value). Áp dụng nhất quán cho mọi output có khả năng chứa secret.

output "db_password" {
  value     = random_password.db.result
  sensitive = true
}

Không log toàn bộ output MCP tool ra file log của agent session nếu log đó không được mã hóa hoặc lưu ở nơi có kiểm soát truy cập tương đương với chính state file.
Dùng secret manager (AWS Secrets Manager, Vault) làm nguồn thật, Terraform chỉ tham chiếu (data source) không tạo/lưu secret trực tiếp trong resource — cách này giảm diện tích secret nằm trong state ngay từ đầu, độc lập với việc agent có "ngoan" hay không.

Mẹo: Chạy thử terraform state show <resource> trên module của bạn ngay bây giờ và nhìn kỹ output — nếu thấy bất kỳ giá trị nào bạn không muốn một AI agent (hoặc một log file) nhìn thấy, đó là dấu hiệu cần đánh sensitive = true hoặc chuyển sang secret manager ngay, trước khi bật MCP tool cho agent truy cập.

Checklist Thực Chiến Trước Khi Bật Terraform MCP Cho Agent

Trước khi giao MCP server này cho agent dùng hàng ngày, hãy tự trả lời checklist sau:

Backend đã là remote backend có locking (S3+DynamoDB, Terraform Cloud...) — không còn state local trên máy ai đó?
Credentials agent dùng để plan là read-only, tách biệt hoàn toàn với credentials có quyền apply?
Mọi output/variable có khả năng chứa secret đã đánh sensitive = true?
Có bước approval tường minh của con người giữa "agent generate plan" và "ai đó chạy apply"?
Bạn đã thử hỏi agent tóm tắt một plan có resource bị forces replacement và verify câu trả lời đúng, chưa tin mù quáng?

Nếu một trong các câu trên trả lời "chưa", nên dừng lại xử lý trước khi để agent chạm production. Terraform MCP là công cụ rất mạnh để tăng tốc review và giảm lỗi cú pháp HCL, nhưng nó khuếch đại cả tốc độ ra lỗi nếu thiếu rào chắn — đúng với tinh thần chung của agentic engineering (kỹ thuật phát triển bằng agent): tăng tốc độ luôn phải đi kèm tăng review, không thay thế review.

Mẹo: In checklist này ra thành một file AGENTS.md hoặc CLAUDE.md ngay trong thư mục infra/, để bất kỳ agent nào đọc context trước khi làm việc cũng nhìn thấy quy tắc — đây là cách hiệu quả nhất để "dạy" agent giới hạn của nó, thay vì hy vọng nó tự đoán đúng.