Amazon EKS MCP Server: SigV4, CloudTrail, dan Risiko Write Mode

Pertanyaan yang ingin saya jawab sederhana: kalau AI assistant diarahkan ke cluster EKS production, apa yang mencegahnya membuat VPC, menghapus stack, atau memberi dirinya sendiri izin IAM? Istilah di dokumentasinya adalah write mode, dan saya mengira ada toggle di console. Toggle itu tidak ada, dan untuk tahu apa yang sebenarnya berperan sebagai toggle itu saya harus membaca lima halaman AWS dengan teliti.

Tulisan ini adalah pembacaan dokumentasi, bukan benchmark. Saya membaca halaman user guide EKS untuk MCP server, referensi AWS managed policy, blog peluncuran, dan README mcp-proxy-for-aws, dan saya tidak menjalankan server ini di cluster sungguhan. Setiap flag, nama permission, dan default di bawah berasal dari halaman-halaman itu, dan bila halamannya saling berbeda saya sebutkan.

Apa server ini, dan apa arti preview di sini

Amazon EKS MCP server dideskripsikan sebagai fully managed service yang di-host di cloud AWS, tanpa instalasi lokal yang harus dirawat. AWS mengumumkan managed MCP server untuk EKS dan ECS dalam preview pada 21 November 2025, dan halaman EKS yang saya baca pada Oktober 2026 masih memuat catatan bahwa server ini berstatus preview release dan dapat berubah. Managed policy IAM untuk read-only tool-nya diperkenalkan pada hari yang sama.

Preview penting untuk tool operasional karena kontraknya boleh bergeser. Dokumentasi menjanjikan tool baru dan perbaikan datang otomatis, yang nyaman, tetapi berarti daftar tool yang Anda review bulan lalu belum tentu sama dengan yang dilihat agent hari ini. Blog peluncuran menyebut ketersediaan di semua AWS Commercial region, kecuali US GovCloud dan region China, dan saya tidak menemukan pernyataan harga di halaman pengumuman.

Jalur request: proxy lokal yang menandatangani dengan SigV4

Assistant Anda tidak berbicara langsung ke AWS. Ia menjalankan mcp-proxy-for-aws sebagai stdio server, dan proxy itu, menurut panduan getting started, bertindak sebagai client-side bridge yang menangani autentikasi AWS SigV4 dengan credential AWS lokal Anda. Endpoint hosted-nya berbentuk https://eks-mcp.REGION.api.aws/mcp, dan nama service untuk signing adalah eks-mcp. Karena identitasnya adalah IAM principal biasa, semua yang sudah Anda tahu tentang role, session policy, dan permission boundary berlaku.

Blog peluncuran menambahkan detail yang mudah terlewat: region di URL endpoint adalah tempat server di-host, sedangkan argumen --region di proxy menentukan cluster EKS mana yang dikerjakan. Halaman configuration reference lalu memuat dua default yang saling bertentangan, karena itu tabel di bawah layak dibaca sebelum Anda menyalin contoh.

Enam belas read tool, empat write tool, satu permission tiap tool

Tools reference membagi server menjadi read-only tool dan full access (write) tool. Read-only mencakup pencarian dokumentasi, troubleshooting guide, panggilan describe dan list untuk cluster, node group, add-on, dan access entry, EKS insights, konfigurasi VPC, event Kubernetes, pod logs, CloudWatch logs dan metrics, serta tool yang membaca policy yang menempel pada sebuah IAM role. Sisi write terdiri dari manage_k8s_resource, apply_yaml, manage_eks_stacks, dan add_inline_policy. Tabel berikut menunjukkan yang menentukan risiko Anda.

Setiap koneksi juga butuh eks-mcp:InvokeMcp, yang dijelaskan dokumentasi sebagai permission untuk inisialisasi dan untuk mengambil daftar tool yang tersedia. Jadi principal yang hanya punya InvokeMcp bisa terhubung dan melihat tool, tetapi tidak bisa memanggil satu pun.

Write mode adalah dua saklar, dan keduanya tidak ada di server

Dokumentasi menulis soal membuat resource jika write mode diaktifkan, tetapi saya tidak menemukan pengaturan server dengan nama itu. Yang dijelaskan halaman-halaman itu adalah dua kontrol yang independen. IAM menentukan apakah panggilan bertanda tangan ke privileged tool diizinkan: eks-mcp:CallPrivilegedTool adalah permission untuk full access tool. Terpisah dari itu, flag --read-only di proxy mencegah tool tersebut ditawarkan ke assistant sama sekali. Managed policy AmazonEKSMCPReadOnlyAccess memuat permission eks-mcp untuk memanggil MCP dan read-only tool, dan halaman getting started mencantumkannya sebagai satu-satunya managed option untuk operasi read-only.

Keempat lapisan ini saling melengkapi, tetapi gagalnya tidak sama, jadi tentukan lapisan mana yang benar-benar Anda andalkan.

Untuk profile production saya memakai lapisan satu sampai tiga bersamaan. Config di bawah mengikuti skenario read-only production milik dokumentasi dengan flag persis seperti yang mereka tunjukkan. Saya mengganti @latest dengan placeholder versi karena README proxy melabeli instalasi CLI-nya sebagai pinned distribution, dan tool operasional tidak boleh berubah sendiri di antara dua restart.

Entri production read-only. Pin versi proxy yang sudah Anda uji, dan isi region endpoint serta --region secara eksplisit, karena dokumentasi menyebut dua default yang berbeda.

{
  "mcpServers": {
    "eks-mcp-prod-readonly": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws@<TESTED_VERSION>",
        "https://eks-mcp.us-west-2.api.aws/mcp",
        "--service", "eks-mcp",
        "--profile", "production",
        "--region", "us-west-2",
        "--read-only"
      ],
      "autoApprove": ["list_k8s_resources", "get_pod_logs", "get_k8s_events"]
    }
  }
}

Blok berikut adalah sisi IAM. Ia menempelkan managed policy read-only ke role yang dipakai proxy untuk signing, lalu menambah explicit deny pada privileged action, sehingga write tool tetap tidak tersedia meskipun kelak seseorang keliru menempelkan policy yang lebih luas.

# Read-only role for the assistant: AWS managed policy for the read tools.
aws iam attach-role-policy \
  --role-name eks-mcp-readonly \
  --policy-arn arn:aws:iam::aws:policy/AmazonEKSMCPReadOnlyAccess

# Explicit deny on the privileged action. A deny beats every allow, so a broader
# policy attached later to this role cannot quietly re-enable the write tools.
aws iam put-role-policy \
  --role-name eks-mcp-readonly \
  --policy-name deny-eks-mcp-privileged \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Deny",
      "Action": "eks-mcp:CallPrivilegedTool",
      "Resource": "*"
    }]
  }'

Apa yang diberikan CloudTrail, dan apa yang tidak dikatakannya

Halaman pengantar menyebut integrasi CloudTrail menangkap initialization dan full access tool call yang dilakukan lewat hosted service, untuk audit trail dan compliance reporting. Bacalah kalimat itu secara harfiah: ia menyebut initialization dan panggilan full access (privileged). Ia tidak mengatakan setiap panggilan read-only tercatat, dan saya tidak menemukan halaman yang menerbitkan nama event atau event source untuk panggilan ini. Jadi jangan membuat alert pada nama yang Anda tebak.

Yang bisa dilakukan tanpa menebak adalah mencari berdasarkan principal. Setiap panggilan ditandatangani oleh identitas IAM yang Anda kendalikan, dan CloudTrail mencatat siapa itu. Beri tiap agent role session name sendiri dan Anda mendapat satu jejak yang bersih per agent.

# The docs do not publish the event names for these calls, so search by who
# signed them instead of guessing a name. The username is the role session
# name, which is why each agent should get its own.
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=agent-triage-01 \
  --max-results 20 \
  --query 'Events[].[EventTime,EventSource,EventName]' \
  --output table

Jejak itu adalah bukti setelah kejadian. Ia memberi tahu role session mana yang menjalankan manage_eks_stacks pada jam berapa, dan tidak menghentikannya. Ia juga tidak menyimpan prompt yang memicu panggilan itu, jadi Anda tetap butuh transkrip assistant sendiri untuk menjelaskan alasannya.

Di mana ia menggigit: trade-off yang dinyatakan terus terang

Kalimat paling berguna di dokumentasi adalah yang kurang enak dibaca. Write policy opsionalnya didokumentasikan memuat permission berisiko tinggi, apa pun dengan Delete atau resource IAM tanpa batas, karena manage_eks_stacks membutuhkannya untuk setup dan teardown resource cluster. Dalam praktik, policy itu memungkinkan principal membuat IAM role, menempelkan policy, dan menghapus komponen VPC, sehingga assistant dengan policy tersebut adalah administrator infrastruktur yang menerima perintah dalam bahasa biasa.

Tiga batasan lain mengikuti dari halaman yang sama. Operasi write Kubernetes hanya menjangkau cluster public, per dokumentasi, sedangkan operasi read menjangkau cluster private dan public. apply_yaml mengandalkan Kubernetes API untuk validasi, sehingga manifest dari sumber yang tidak tepercaya diterapkan apa adanya. Dan server meredaksi pola secret yang umum, menggantinya dengan HIDDEN_FOR_SECURITY_REASONS, tetapi dokumentasi juga meminta Anda tidak melewatkan secret lewat prompt, YAML, atau Kubernetes Secret yang dibuat via MCP, jadi redaksi hanyalah cadangan, bukan jaminan.

Yang dikerjakan hari Senin

Mulai dari role yang hanya bisa melihat, buktikan, dan baru putuskan apakah ada yang layak diberi akses write. Tak satu pun langkah ini butuh server yang lebih dari sekadar preview.

1. Buat role untuk assistant dan tempelkan AmazonEKSMCPReadOnlyAccess, lalu tambahkan explicit deny pada eks-mcp:CallPrivilegedTool.
2. Buktikan policy dengan simulate-principal-policy sebelum agent mana pun terhubung, dan simpan outputnya bersama catatan perubahan Anda.
3. Konfigurasikan proxy dengan --service, --region, --profile, dan --read-only, semuanya eksplisit, dengan versi proxy yang di-pin.
4. Beri tiap assistant role session name sendiri agar CloudTrail bisa dicari berdasarkan principal, lalu ajukan satu pertanyaan sungguhan dan temukan panggilan Anda sendiri di jejaknya.
5. Putuskan secara tertulis environment mana, jika ada, yang mendapat write role, dan siapa yang boleh meng-assume-nya. Jauhkan add_inline_policy dari semua orang.

# Step 2: prove the role can invoke and read, and cannot call privileged tools.
# Expect "allowed" for the first two actions and "explicitDeny" for the third.
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/eks-mcp-readonly \
  --action-names eks-mcp:InvokeMcp eks-mcp:CallReadOnlyTool eks-mcp:CallPrivilegedTool \
  --query 'EvaluationResults[].[EvalActionName,EvalDecision]' \
  --output table

Jika langkah empat tidak menemukan apa pun untuk pertanyaan read-only, itu konsisten dengan dokumentasi yang hanya menyebut initialization dan panggilan full access. Catat itu sebagai celah yang diketahui, jangan berasumsi jejaknya lengkap.

Aturan saya setelah membaca halaman-halaman ini: managed MCP server memindahkan beban operasional ke AWS tetapi tidak memindahkan keputusan soal otoritas. Otoritas tetap IAM, ditegakkan oleh explicit deny, dan flag --read-only hanyalah kemudahan di atasnya. Anggap audit trail sebagai catatan apa yang Anda izinkan, bukan sebagai hal yang mengizinkannya.