DEV Community: Ice

อ่านบิล AWS ด้วย Usage Type: 6 บรรทัดที่รั่วเงียบๆ ที่ Cost Explorer ระดับ Service ไม่ยอมบอก

Ice — Fri, 30 Oct 2026 13:01:17 +0000

ตอนเปิด Cost Explorer แล้วเห็นกราฟ EC2 กับ RDS โตเป็นแท่งใหญ่ ใครๆ ก็รู้ว่าต้องไปดูตรงนั้นก่อน ปัญหาคือเงินที่รั่วจริงๆ มักไม่ได้อยู่ในแท่งใหญ่ มันซ่อนอยู่ในบรรทัดเล็กๆ ที่ชื่อฟังดูไม่น่ากลัว เช่น "Data Transfer" หรือ "EC2-Other" ซึ่งเป็นถังรวมที่ยัดสารพัดอย่างไว้ข้างใน

บทความนี้เล่าวิธีที่ใช้จริงเวลาไล่บิล: เลิกดูระดับ Service แล้วเจาะลงไปที่ Usage Type ทีละบรรทัด พร้อม 6 จุดที่เจอบ่อยที่สุด ตัวเลขราคาทั้งหมดเป็น list price ของ us-east-1 ณ ตอนเขียน (ราคาเปลี่ยนได้ และแต่ละ region ไม่เท่ากัน เช็คหน้า pricing ของ AWS อีกทีก่อนเอาไปคำนวณ) ส่วนตัวเลขบิลจริงของที่ไหนไม่เอามาใส่ทั้งนั้น

ทำไมระดับ Service ถึงไม่พอ

"EC2-Other" ใน Cost Explorer ไม่ใช่ instance นะ มันคือทุกอย่างที่เกี่ยวกับ EC2 แต่ไม่ใช่ค่า instance: EBS volume, snapshot, NAT Gateway, Elastic IP, data transfer ข้าม AZ ทั้งหมดรวมอยู่ในก้อนเดียว ถ้าก้อนนี้โต คุณไม่มีทางรู้เลยว่าเป็นเพราะอะไร จนกว่าจะแตกมันออกเป็น Usage Type

วิธีแตกที่เร็วที่สุดคือใน Cost Explorer เลือก Group by เป็น Usage Type แล้ว filter Service เป็น "EC2-Other" ถ้าชอบ CLI:

aws ce get-cost-and-usage \
  --time-period Start=2026-09-01,End=2026-10-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["EC2 - Other"]}}' \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --query 'ResultsByTime[0].Groups[].[Keys[0],Metrics.UnblendedCost.Amount]' \
  --output text | sort -k2 -nr | head -15

หมายเหตุเล็กๆ: Cost Explorer API คิดเงินต่อ request (ราว $0.01 ต่อครั้ง) ไม่ต้องยิงรัวใน loop แต่ถ้าครั้งสองครั้งต่อเดือน ไม่ถึงกับเจ็บ

พอได้ลิสต์ Usage Type แล้ว ลองไล่ดูหกตัวนี้ก่อน

1. NatGateway-Bytes: ค่าประมวลผลต่อ GB ที่ไม่มีใครมอง

NAT Gateway คิดสองก้อน คือค่าชั่วโมง (NatGateway-Hours) กับค่าประมวลผลข้อมูลต่อ GB (NatGateway-Bytes, ราว $0.045 ต่อ GB) ก้อนหลังคือตัวที่โตเงียบๆ เพราะทุก byte ที่ผ่าน NAT โดนนับหมด ไม่ว่าจะไปไหน

ตัวการที่เจอบ่อยคือ traffic ไป S3 และ DynamoDB ที่ไหลผ่าน NAT ทั้งที่ไม่จำเป็น เพราะ Gateway endpoint ของ S3 กับ DynamoDB ไม่มีค่าใช้จ่าย และ pod ที่ pull image จาก ECR ก็เหมือนกัน layer จริงๆ อยู่ใน S3 ใส่ S3 gateway endpoint ใน route table ของ private subnet ก้อนใหญ่หายไปได้เลย

ส่วน interface endpoint (เช่นของ ECR API, STS) ไม่ฟรี คิดต่อ AZ ต่อชั่วโมงบวกค่า data ต้องคำนวณก่อนว่าคุ้มกว่า NAT หรือเปล่า ไม่ใช่ใส่ทุกตัวตามกระแส

2. PublicIPv4:InUseAddress และ IdleAddress: IP ที่เคยฟรีกลายเป็นบิล

ตั้งแต่ AWS เริ่มคิดค่า public IPv4 ทุกตัว (ตัวละ $0.005 ต่อชั่วโมง ราว $3.65 ต่อเดือน) ไม่ว่าจะใช้งานอยู่หรือไม่ก็ตาม บรรทัดนี้โผล่ในบิลของแทบทุกคน Usage Type จะแยกเป็น PublicIPv4:InUseAddress กับ PublicIPv4:IdleAddress

ที่ควรเช็คตามลำดับ:

Elastic IP ที่ไม่ได้ผูกกับอะไร (Idle) ลบได้เลย
ENI ที่ค้างอยู่หลังลบ resource ที่เคยใช้มัน
EC2 ใน public subnet ที่จริงๆ ไม่ต้องมี IP ตัวเอง ย้ายไปหลัง load balancer ได้
ALB เองก็ใช้ public IP ต่อ AZ นะ อย่าลืมนับด้วย

ข้อควรระวัง: ถ้าย้ายของไปหลัง NAT เพื่อประหยัด IP ให้กลับไปดูข้อ 1 ด้วย เดี๋ยวประหยัดค่า IP แล้วไปเสียค่า NAT แทน

3. DataTransfer-Regional-Bytes: ค่า traffic ข้าม AZ

ข้อนี้ทำให้คนงงบ่อยที่สุด traffic ระหว่าง AZ ใน region เดียวกันคิดเงินทั้งสองฝั่ง (ราว $0.01 ต่อ GB ขาออกและ $0.01 ต่อ GB ขาเข้า รวมเป็น $0.02 ต่อ GB ต่อการส่งหนึ่งครั้ง) ฟังดูเล็ก แต่ cluster ที่ service คุยกันถี่ๆ กระจายอยู่หลาย AZ จะสะสมเร็วมาก

จุดที่ต้องดู: service ที่คุยกันเยอะแต่ถูก schedule คนละ AZ, ระบบ messaging หรือ database replication ข้าม AZ, และ log shipper ที่ส่งข้ามไปรวมศูนย์ ใน Kubernetes ลองใช้ topology aware routing (ให้ Service ส่ง traffic ไปที่ endpoint ใน AZ เดียวกันก่อน) หรือ topologySpreadConstraints ที่คิดมาแล้วว่า service คู่ไหนควรอยู่ใกล้กัน แลกกับความ resilient ที่ลดลงนิดหน่อย ซึ่งต้องตัดสินใจเป็นรายระบบ ไม่ใช่เปิดทุกที่

4. DataProcessing-Bytes ของ CloudWatch Logs: ค่า ingest

CloudWatch Logs คิดค่า ingest ราว $0.50 ต่อ GB (ราคาที่แพงกว่าที่คนส่วนใหญ่นึก) และ retention ค่าเริ่มต้นคือ Never expire บรรทัดนี้โตเงียบๆ จากสาเหตุเดิมซ้ำๆ: service ยิง DEBUG ใน production ค้างไว้, log ของ health check ทุก 10 วินาที, หรือ log แบบ JSON ก้อนใหญ่ที่ไม่มีใครอ่าน

ไล่แก้ตามนี้: ตั้ง retention ทุก log group (หลักวันถึงหลักเดือนตามที่ต้องใช้จริง), ปรับ log level, กรอง health check ออกที่ต้นทาง และสำหรับ log ที่ต้องเก็บยาวแต่ไม่ค่อยอ่าน พิจารณา Infrequent Access log class ที่ราคา ingest ถูกลง (แลกกับฟีเจอร์ที่ลดลง เช็คข้อจำกัดก่อนใช้)

5. VolumeUsage.gp2 และ snapshot ที่ไม่มีเจ้าของ

EBS gp3 ถูกกว่า gp2 ราว 20% ต่อ GB ($0.08 เทียบกับ $0.10) และได้ baseline 3,000 IOPS ทุกขนาด แถมเปลี่ยนจาก gp2 เป็น gp3 ได้แบบ online ด้วย modify-volume ไม่ต้อง detach ที่เจอบ่อยคือ module Terraform เก่าที่ก๊อปต่อกันมายังตั้ง default เป็น gp2 อยู่ แก้ที่ default ใน IaC ด้วย ไม่งั้นของใหม่ก็ยังเป็น gp2 ต่อไป

อีกก้อนคือ snapshot ที่ค้างอยู่หลัง AMI ถูก deregister ซึ่ง AWS ไม่ลบให้ ลองไล่ดู snapshot ที่ไม่มี AMI หรือ volume ต้นทางอ้างถึงแล้ว ตั้ง lifecycle policy (Data Lifecycle Manager) ให้ลบเองตามอายุ

6. ELB ที่ไม่มี traffic

Load balancer คิดค่าชั่วโมงตลอดเวลาที่มันอยู่ ต่อให้ไม่มี request สักตัว ของที่เจอบ่อยคือ ALB/NLB ที่เหลือจาก environment ที่เคยทดลองแล้วไม่ได้ลบ เช็คจาก metric RequestCount หรือ ActiveFlowCount ใน CloudWatch ย้อนหลัง 30 วัน ถ้าเป็นศูนย์ตลอด ถามเจ้าของก่อน แล้วค่อยลบ

จัดลำดับก่อนลงมือ

ไล่ครบหกข้อแล้วอย่าเพิ่งแก้ทุกอย่างพร้อมกัน เรียงตามเงินที่ได้คืนต่อแรงที่เสีย แล้วเริ่มจากของที่ไม่เสี่ยงก่อน:

ตั้ง retention ให้ log group และลบ Elastic IP / snapshot / ELB ที่ไม่มีใครใช้ (เสี่ยงต่ำ ได้เงินคืนเร็ว)
ใส่ S3 gateway endpoint และเปลี่ยน default เป็น gp3 ใน IaC
ค่อยพิจารณา cross-AZ กับ interface endpoint ที่ต้องคำนวณและมี trade-off เรื่อง resilience

ก่อนลบอะไรที่ไม่ใช่ของตัวเอง ให้ดูก่อนว่ามี tag เจ้าของไหม ถ้าไม่มี ถามในช่องทีมก่อน และเปิด cost allocation tag ไว้ตั้งแต่วันนี้ เพราะเดือนหน้าคุณจะอยากรู้ว่าบรรทัดไหนเป็นของทีมไหน

สรุป

Cost Explorer ระดับ Service บอกว่า "เงินไปไหน" ได้แค่ครึ่งเดียว ครึ่งที่เหลืออยู่ใน Usage Type ซึ่งใช้เวลาอ่านไม่ถึงครึ่งชั่วโมงต่อเดือน ลองตั้งเป็นกิจวัตรสิ้นเดือน เปิดกราฟ group by Usage Type เรียงจากมากไปน้อย แล้วถามตัวเองว่า "บรรทัดนี้ ใครเป็นเจ้าของ แล้วเรารู้หรือเปล่าว่ามันควรอยู่เท่านี้" แค่นี้ก็จับของรั่วได้ก่อนมันกลายเป็นบิลก้อนโต 555

ตัวเลขราคาในบทความเป็น list price โดยประมาณของ us-east-1 ราคาจริงของคุณอาจต่างตาม region, ส่วนลด หรือสัญญา ตรวจกับหน้า pricing และ pricing calculator ของ AWS ก่อนตัดสินใจทุกครั้ง

MCP server ในมือ agent คือ "คำสั่งที่รันบนเครื่องคุณ"

Ice — Fri, 30 Oct 2026 12:59:49 +0000

สัปดาห์ที่แล้วมีข่าวหนึ่งที่ผมอ่านแล้วต้องวางกาแฟ: OpenCode (coding agent ตัวหนึ่ง) มีช่องโหว่ที่ทำให้ MCP server ที่ไม่น่าไว้ใจรันคำสั่งบนเครื่องนักพัฒนาได้ แค่ตอนกด sign-in ผ่าน OAuth ไม่ต้องให้ agent เรียก tool อะไรเลยด้วยซ้ำ

ข่าวนี้ไม่ใช่เรื่องของ OpenCode ตัวเดียว มันชี้ให้เห็นสิ่งที่ทีม ops/security หลายทีมยังมองข้าม: การเพิ่ม MCP server เข้า agent ไม่ต่างจากการ curl | bash ของเวอร์ชันสมัยใหม่ บทความนี้จะเล่าข่าวก่อน แล้วค่อยไล่ว่าถ้าจะรัน agent กับ MCP ใน infra จริง ควรวางด่านอะไรบ้าง ทั้งหมดเป็นมุม defensive ไม่มี exploit และตัวอย่าง config เป็นของสมมติทั้งหมด

ข่าวที่ 1: OpenCode และ OAuth sign-in ของ MCP server

ตามรายงานของ The Hacker News (เผยแพร่ 22 ตุลาคม 2026) บริษัท Pillar Security พบว่า OpenCode เวอร์ชัน 1.0.137 ถึง 1.18.32 บน Windows และ WSL เท่านั้น (macOS กับ Linux ไม่โดน) มีปัญหาตอนทำ OAuth กับ remote MCP server

กลไกคือ remote MCP server เป็นคนส่ง "authorization endpoint" URL กลับมา แล้ว OpenCode เอา URL นั้นไปเปิดเบราว์เซอร์ผ่าน helper ที่ประกอบคำสั่ง PowerShell โดยไม่ escape ผลคือ URL ที่ถูกออกแบบมาให้มีคำสั่ง PowerShell แฝง จะถูกรันด้วยสิทธิ์ของนักพัฒนาคนนั้นเลย ที่น่าสนใจคือ URL ยังหน้าตาเป็น HTTPS ธรรมดา เช็คแค่ว่าขึ้นต้นด้วย http หรือ https จึงกันไม่ได้

รายละเอียดที่ควรรู้ตามรายงาน: Pillar แจ้งผู้พัฒนาแบบ private เมื่อ 29 สิงหาคม ทีมแก้ในเวอร์ชัน 1.18.33 ซึ่งออกวันที่ 28 กันยายน และเปิดเผยต่อสาธารณะ 19 ตุลาคม Pillar ให้คะแนนความรุนแรงที่เสนอไว้ 9.8 จาก 10 ไม่มี CVE (ผู้พัฒนาไม่ได้ขอ) ซึ่งแปลว่า scanner ที่ไล่ดูแต่ CVE จะ ไม่เห็น เคสนี้เลย และรายงานระบุว่ายังไม่พบการโจมตีจริง

บทเรียนข้อแรกจึงเป็นเรื่องที่ไม่เกี่ยวกับ MCP โดยตรง: ถ้า inventory ของคุณพึ่ง CVE feed อย่างเดียว คุณจะพลาดช่องโหว่ในเครื่องมือฝั่ง developer ที่ไม่มีเลข CVE ต้องมีรายการ "agent/CLI ที่ใช้อยู่ในองค์กรและเวอร์ชัน" แยกต่างหาก

ข่าวที่ 2: ปัญหาเชิงระบบของ STDIO transport (OX Security)

อีกชิ้นที่ควรอ่านคู่กันคือ advisory ของ OX Security ที่เผยแพร่ 15 เมษายน 2026 (ไม่ใช่ข่าวสดแต่ยังเกี่ยวข้อง และถูกอ้างถึงต่อเนื่อง) ประเด็นหลักคือ MCP แบบ STDIO ให้ผู้ใช้กำหนด command กับ args ซึ่งถูกส่งไปรันเป็น subprocess ตรงๆ โดยไม่มี allowlist หรือการ sanitize ใน SDK เอง OX จึงเรียกว่าเป็นช่องโหว่ระบบ (systemic) ที่ไหลไปอยู่ในหลายผลิตภัณฑ์

ผลิตภัณฑ์ที่ OX ระบุว่าได้รับผลมีหลายตัว ตัวที่คนในวงการ AI infra น่าจะคุ้นคือ LiteLLM ซึ่งมี CVE-2026-30623 (ต้อง authenticate, แก้แล้วใน v1.83.6-nightly และ v1.83.7-stable) รวมถึง LangFlow, Flowise, Windsurf และอื่นๆ อีกหลายตัว

อีกส่วนที่น่าคิดคือจุดยืนของผู้ให้บริการ OX ระบุว่าหลายเจ้าตอบว่าพฤติกรรมนี้ "by design" และชี้ว่า sandbox เช่น Docker ช่วยลดความเสี่ยงได้ ส่วน OX แย้งว่า sandbox ก็ยังโดนใช้ขุดเหรียญหรือเป็น proxy ได้ ผมไม่ตัดสินว่าฝั่งไหนถูก เพราะจากมุม ops สิ่งที่ต้องรู้คือ คุณคาดหวังให้ upstream ปิดช่องนี้ให้ไม่ได้ ต้องออกแบบด่านของตัวเอง

ทำไม MCP ถึงเป็นโจทย์ ops ไม่ใช่แค่โจทย์ dev

ลองนึกภาพ MCP server เป็น 3 อย่างพร้อมกัน

โปรแกรมที่รันบนเครื่อง (STDIO แบบ npx some-mcp-server คือดาวน์โหลดแพ็กเกจแล้วรันทันที)
ผู้ให้ข้อความที่ LLM จะอ่านและเชื่อ (tool description, ผลลัพธ์ของ tool คือ input เข้า prompt)
ตัวถือสิทธิ์ (token ของ GitHub, Jira, cloud API ที่ใส่ไว้ให้ tool ใช้)

ทั้งสามอย่างนี้ปกติทีม ops ดูแลแยกกัน: ด่านของ software supply chain, ด่านของ prompt injection, ด่านของ secret management พอมาอยู่ในก้อนเดียวคือ "MCP server" มันเลยตกหล่นระหว่างทีม ไม่มีใครเป็นเจ้าของ

6 ด่านที่ควรวางก่อนปล่อย agent เข้า infra จริง

ด่านที่ 1: ทะเบียน MCP server ที่อนุมัติแล้ว (allowlist ระดับองค์กร)

ใครจะเพิ่ม MCP server ต้องผ่านรีวิวเหมือนเพิ่ม dependency ใหม่ เก็บเป็นไฟล์ใน repo ที่มี owner ชัดเจน เช่น

# mcp-registry.yaml (ตัวอย่างสมมติ)
servers:
  - name: internal-docs-search
    transport: streamable-http
    url: https://mcp.example.internal/docs
    owner: platform-team
    scopes: [read]
    reviewed: 2026-10-01
  - name: ticket-reader
    transport: stdio
    command: /opt/mcp/bin/ticket-reader   # pin path, ไม่ใช้ npx
    args: ["--readonly"]
    owner: sre-team
    reviewed: 2026-09-20

จุดที่ผมย้ำกับตัวเองคือ allowlist ต้องเช็คทั้ง command และ args จาก advisory ของ OX จะเห็นว่ามีเคสที่ allowlist ชื่อคำสั่งอย่าง npx แต่ผู้ใช้ยัดอาร์กิวเมนต์ที่ทำให้มันรันคำสั่งอื่นได้ ถ้าอนุญาตแค่ "npx" เท่ากับไม่ได้อนุญาตอะไรเลย

ด่านที่ 2: ตรึงเวอร์ชันและที่มา (pin + verify)

npx -y some-mcp-server@latest ในไฟล์ config ของ agent คือการให้ใครก็ตามที่ครอบครอง package นั้นรันโค้ดบนเครื่องคุณทุกครั้งที่ agent เริ่ม ให้ pin เวอร์ชันเป็นเลขตายตัว หรือดีกว่านั้นคือ build เป็น image/binary ภายในแล้วอ้างด้วย digest

# ดูว่าเครื่อง dev ในทีมมี MCP config อะไรอยู่บ้าง (ตัวอย่างหาแบบหยาบ)
grep -rn --include="*.json" -E '"(command|url)"\s*:' ~/.config 2>/dev/null | grep -i mcp

คำสั่งข้างบนเป็นแค่จุดเริ่ม ในองค์กรจริงควรให้ MDM หรือ endpoint tooling เก็บ inventory แทน

ด่านที่ 3: แยก identity ของ agent ออกจากคน

อย่าให้ agent ใช้ token ส่วนตัวของนักพัฒนา สร้าง service identity แยก ให้สิทธิ์เท่าที่ tool ต้องใช้ ถ้า tool แค่อ่านตั๋ว ก็ควรได้ token แบบ read-only เหมือนที่เราทำกับ IRSA บน EKS: role ต่อ workload ไม่ใช่ role กลางที่ทุกอย่างแชร์กัน

ถ้าเป็นฝั่ง cloud ให้ใช้ credential อายุสั้น (STS, workload identity) แทน long-lived key และอย่าใส่ secret ลงในไฟล์ config ของ MCP ตรงๆ ให้ดึงจาก secret manager ตอน runtime

ด่านที่ 4: Sandbox ที่ปิดเน็ตและ filesystem โดยค่าเริ่มต้น

MCP server แบบ STDIO ที่ต้องรันในเครื่องเดียวกับ agent ให้รันใน container หรือ sandbox ที่

filesystem เป็น read-only ยกเว้น directory ทำงานที่กำหนด
ไม่มีสิทธิ์ root และ drop capability ที่ไม่จำเป็น
egress ถูกจำกัดเหลือ domain ที่ tool ต้องคุยจริง

# ตัวอย่าง pod spec สมมติสำหรับ MCP server ที่รันใน cluster
securityContext:
  runAsNonRoot: true
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]

ตรงนี้ขอยอมรับฝั่ง "sandbox ช่วยได้" ที่เหล่าผู้ให้บริการอ้าง: มันช่วยลด blast radius จริง แต่ OX ก็พูดถูกว่ามันไม่ได้ทำให้ปลอดภัย ถ้า container ออกเน็ตได้เต็มที่ ก็ยังถูกใช้ทำอะไรแปลกๆ ได้ ต้องมีทั้งสองอย่าง: sandbox คู่กับ egress policy

ด่านที่ 5: Human-in-the-loop เฉพาะ action ที่ย้อนกลับไม่ได้

ไม่ต้องให้คนกดอนุมัติทุก tool call เพราะสุดท้ายคนจะกด approve รัวจนไร้ความหมาย (approval fatigue) แบ่งเป็นระดับ

อ่านอย่างเดียว (list, get, search): รันได้เลย แต่ log
เขียนที่ย้อนกลับได้ (สร้างตั๋ว, comment): รันได้ แต่มีโควตาต่อชั่วโมง
ย้อนกลับไม่ได้หรือกระทบ production (delete, deploy, เปลี่ยน IAM, ส่งข้อความออกนอกองค์กร): ต้องมีคนยืนยันทุกครั้ง

ด่านที่ 6: Audit log ที่ตอบได้ว่า "ใคร สั่งอะไร ผ่าน agent ตัวไหน ได้ผลอะไร"

log ที่มีแค่ "agent เรียก tool X" ไม่พอตอนเกิดเหตุ ควรเก็บอย่างน้อย: identity ของ agent, ผู้ใช้ที่ต้นเรื่อง, ชื่อ MCP server และเวอร์ชัน, ชื่อ tool, พารามิเตอร์ (mask ค่า secret), เวลา, ผลลัพธ์ (สำเร็จ/ล้มเหลว) และส่งเข้าที่เดียวกับ log security อื่นๆ จะได้ค้นข้ามกันได้ เช่น ตอนจะตอบว่า "token ที่รั่วถูกใช้ผ่าน tool ไหนบ้าง"

แล้วข่าว OpenCode สอนอะไรเพิ่ม

กลับไปที่เคส OAuth ของ OpenCode มีบทเรียนที่ผมว่าใช้ได้กับทุก agent

ทุกค่าที่มาจาก MCP server ต้องถือว่าไม่น่าไว้ใจ ไม่ใช่แค่ผลลัพธ์ของ tool URL สำหรับ OAuth, ชื่อ tool, description, metadata ล้วนเป็น input จากภายนอก ถ้าโค้ดฝั่ง client เอาไปประกอบเป็นคำสั่ง shell ก็จบเหมือนกัน นี่คือ command injection แบบคลาสสิกที่ใส่ชุดใหม่

ช่วงเวลาที่เสี่ยงที่สุดคือตอนเชื่อมต่อครั้งแรก ไม่ใช่ตอนใช้งาน ดังนั้นกฎ "ห้ามต่อ remote MCP server ที่ไม่อยู่ในทะเบียน" ต้องบังคับตั้งแต่ขั้น sign-in ไม่ใช่รอดูตอนเรียก tool

อัปเดตเครื่องมือ developer ให้เป็นกิจวัตรเหมือน patch OS เคสนี้แก้ออกมาตั้งแต่ 28 กันยายน แต่เปิดเผยเมื่อ 19 ตุลาคม คนที่อัปเดตตามปกติปลอดภัยก่อนข่าวออกสามสัปดาห์ คนที่ปล่อยเวอร์ชันเก่าไว้ก็เพิ่งรู้ตอนอ่านข่าว

เช็คลิสต์เริ่มต้นสำหรับสัปดาห์นี้

ถ้าไม่มีเวลาทำครบทั้ง 6 ด่าน ลองเริ่มจากสามอย่างนี้ซึ่งใช้แรงน้อยแต่ได้ผลมาก

ทำ inventory ว่าในทีมใช้ agent/CLI ตัวไหน เวอร์ชันอะไร (รวมตัวที่ไม่มี CVE) แล้วเช็คกับข่าวล่าสุด เช่น ถ้ามีคนใช้ OpenCode บน Windows/WSL ให้ยืนยันว่าเป็น 1.18.33 ขึ้นไป
ค้นหา npx ... @latest หรือคำสั่ง STDIO ที่ไม่ได้ pin ในไฟล์ config ของ MCP แล้ว pin ให้หมด
ถอด token ส่วนตัวออกจาก config ของ agent แล้วย้ายไปใช้ identity แยกที่สิทธิ์น้อยที่สุด

ปิดท้าย

ผมไม่ได้บอกว่าอย่าใช้ MCP มันเป็นของที่มีประโยชน์จริง ทุกวันนี้ agent ที่คุยกับระบบ ticket, เอกสาร และ log ได้ช่วยลดงานจุกจิกไปเยอะ แต่เราควรคุยกันตรงๆ ว่ามันคือ "โค้ดจากภายนอกที่ได้สิทธิ์ของเรา" และปฏิบัติกับมันเท่ากับ dependency ที่ผ่านการรีวิว ไม่ใช่ปลั๊กอินที่ติดตั้งตามบล็อก

ครั้งหน้าที่มีคนในทีมบอกว่า "ผมเพิ่มเซิร์ฟเวอร์ MCP ตัวใหม่เข้า agent แล้วนะ" ลองถามกลับสามคำถาม: ใครเป็นเจ้าของ, มันรันด้วยสิทธิ์ของใคร, และถ้ามันทำอะไรแปลกๆ เราจะรู้จาก log ตรงไหน ถ้าตอบไม่ได้ครบ ก็ยังไม่ถึงเวลาเข้า production ครับ

แหล่งอ้างอิง

The Hacker News, "OpenCode Flaw Lets Malicious MCP Servers Execute Code During Sign-In on Windows and WSL" (22 ต.ค. 2026): https://thehackernews.com/2026/10/opencode-flaw-lets-malicious-mcp.html
OX Security, "MCP Supply Chain Advisory: RCE Vulnerabilities Across the AI Ecosystem" (15 เม.ย. 2026): https://www.ox.security/blog/mcp-supply-chain-advisory-rce-vulnerabilities-across-the-ai-ecosystem/

หมายเหตุ: รายละเอียดช่องโหว่ในบทความนี้สรุปจากรายงานสาธารณะข้างต้น ตัวอย่าง config ทั้งหมดเป็นของสมมติ ไม่ใช่ข้อมูลระบบจริงของใคร

GhostAction กลับมาอีกรอบ: เมื่อ workflow ชื่อ "security-audit" คือตัวขโมย secret และสิ่งที่ทีม DevSecOps ควรเช็คเดี๋ยวนี้

Ice — Mon, 12 Oct 2026 03:34:53 +0000

เช้าวันจันทร์ เปิดข่าวมาเจอเรื่องนี้เลยต้องวางกาแฟแล้วไปไล่เช็ค repo ตัวเองก่อน เรื่องคือแคมเปญ GhostAction ที่เคยเป็นข่าวเมื่อกันยายนปีที่แล้ว กลับมาอีกรอบ รอบนี้ The Hacker News รายงานเมื่อ 9 ตุลาคม 2026 ว่ามี workflow ไฟล์หนึ่งถูกยัดเข้าไปใน repository เป็นหลักหมื่น และเป้าหมายของมันคือสิ่งเดียวที่ทีม CI/CD ทุกทีมมีเหมือนกัน นั่นคือ secret ที่เก็บไว้ใน GitHub Actions

บทความนี้จะแยกเป็นสามส่วน: ข่าวมันเกิดอะไรขึ้นจริง (เท่าที่แหล่งข่าวยืนยัน), ทำไมวิธีนี้ถึงได้ผลกับทีมที่คิดว่าตัวเอง "ก็ตั้งค่าปลอดภัยแล้ว", และถ้าเป็นเราต้องทำอะไรบ้างทั้งวันนี้และระยะยาว ทุกอย่างในนี้เป็นแนวป้องกัน ไม่มีขั้นตอนโจมตี

ข่าวคืออะไร

ข้อมูลหลักมาจากรายงานของ The Hacker News อ้าง StepSecurity, Socket และ GitGuardian สรุปเฉพาะที่ยืนยันได้:

Socket นับได้ว่ามีบัญชี GitHub มากกว่า 500 บัญชี commit workflow ตัวนี้เข้าไปใน repository หลักหมื่น นับตั้งแต่ 7 ตุลาคม 2026
StepSecurity บันทึกสองเคสของบัญชี maintainer ที่ถูกใช้งาน เคสแรก workflow ถูก push เข้า 27 repository เริ่มประมาณ 13:20 UTC อีกแปดชั่วโมงถัดมาอีกบัญชีหนึ่งถูก push เข้า 318 repository ภายในเวลาแค่ราว 16 นาที
GitGuardian รายงานเฟสก่อนหน้า: 772 public repository ของ 373 ผู้ใช้/องค์กร ระหว่าง 31 สิงหาคมถึง 30 กันยายน 2026
แคมเปญรอบแรก (2025) เคยเก็บ secret ไปได้ 3,325 รายการจาก 817 repository

วิธีเข้าถึงที่แหล่งข่าวประเมินว่าเป็นไปได้มากที่สุดคือ personal access token ของ maintainer รั่ว อาจมาจาก infostealer log หรือ credential dump ไม่ใช่ช่องโหว่ของ GitHub เอง แปลว่าต่อให้ GitHub ปลอดภัยแค่ไหน token ที่หลุดอยู่นอกแพลตฟอร์มก็ยังเป็นประตูหน้าบ้านอยู่ดี

หน้าตาของมัน และทำไมถึงเนียน

Workflow ที่ถูกยัดมีชื่อไฟล์ว่า security-audit.yml หรือ github_actions_security.yml ชื่อแบบนี้เองคือจุดที่น่าสนใจ มันไม่ได้ตั้งชื่อว่า steal.yml แต่แกล้งเป็นงาน security ที่ใครเห็นในรายการ workflow ก็อาจคิดว่า "อ๋อ ทีมเพิ่มตัวสแกนมั้ง" แล้วปล่อยผ่าน

ลักษณะทางเทคนิคที่แหล่งข่าวบรรยายไว้ ซึ่งเอาไปใช้เป็นตัวตรวจจับได้:

trigger เป็น workflow_dispatch และ push ทุก branch ทุก tag โดยไม่กรอง
checkout ด้วย fetch-depth: 0 คือดึง git history ทั้งหมดมา ไม่ใช่แค่ commit ล่าสุด
มี step เดียวชื่อ "Audit" ที่ส่งข้อมูลออกไปยัง IP ฮาร์ดโค้ดผ่าน HTTP ธรรมดา (IOC ที่รายงานคือ 193.32.204[.]199)
เป้าหมายคือ secret ที่ตั้งไว้ใน Actions, credential ที่อยู่ใน working tree และที่ซ่อนอยู่ใน git history รวมถึง AWS key, token ของ GitHub/GitLab และ API key ของฝั่ง AI อย่าง OpenAI, Anthropic, OpenRouter

ประเด็นที่ผมอยากให้สังเกตคือ fetch-depth: 0 ตรงนี้เป็นเรื่องที่คนมักมองข้าม เราชอบคิดว่า "secret ที่เคย commit พลาดแล้วลบไปแล้ว" ปลอดภัย แต่ใน history มันยังอยู่ครบ workflow ที่ดึง history ทั้งก้อนแล้วเอาไป grep คือการเก็บเกี่ยวหนี้เก่าทั้งหมดของ repo ในรอบเดียว

อีกเรื่องที่น่าคิด: GitGuardian บอกว่าแคมเปญเล็งไปถึง 2,577 รูปแบบของ secret ตั้งแต่ SSH key, Azure, Docker Hub/GHCR, database, GCP/Firebase, bot token ของ Slack/Discord/Telegram ไปจนถึง credential ของ npm และ PyPI ตอนนี้แหล่งข่าวบอกว่ายังไม่พบการ publish package ด้วย credential ที่ขโมยไป แต่คนที่ดูแล package ควรถือว่าเป็นความเสี่ยงที่ใกล้ที่สุด

เช็คอะไรวันนี้ (ใช้เวลาไม่เกิน 30 นาที)

ถ้าคุณดูแลหลาย repo ใน organization ให้เริ่มจากชุดคำสั่งง่ายๆ นี้ ใช้ gh CLI ที่ login ด้วยสิทธิ์อ่านอย่างเดียวพอ

# หา workflow ชื่อต้องสงสัยในทุก repo ของ org
ORG=your-org
gh repo list "$ORG" --limit 1000 --json nameWithOwner -q '.[].nameWithOwner' | while read -r repo; do
  for f in security-audit.yml github_actions_security.yml; do
    if gh api "repos/$repo/contents/.github/workflows/$f" >/dev/null 2>&1; then
      echo "FOUND: $repo/$f"
    fi
  done
done

แล้วเช็ค commit ล่าสุดที่แตะโฟลเดอร์ .github/workflows ว่าใครเป็นคน push ตรงเข้า default branch โดยไม่ผ่าน pull request:

gh api "repos/$ORG/REPO/commits?path=.github/workflows&since=2026-08-31T00:00:00Z" \
  -q '.[] | [.sha[0:7], .commit.author.name, .commit.message] | @tsv'

ถ้าเจอไฟล์จริง แหล่งข่าวแนะนำให้ถือว่าถูกบุกรุกแล้ว ลำดับที่ผมจะทำคือ:

revoke token/PAT ของบัญชีที่ push เข้ามา ก่อนอย่างอื่น
ลบ workflow ออกจากทุก branch (ไม่ใช่แค่ default branch เพราะ trigger ของมันดักทุก branch)
หมุน secret ทั้งหมดที่ repo นั้นเข้าถึงได้ ทั้ง Actions secrets, cloud key, API key ที่เคยอยู่ใน history ให้ถือว่าหลุดหมด
ไล่ดู CloudTrail / audit log ของ provider ว่ามี key เหล่านั้นถูกเรียกจากที่แปลกๆ ช่วงที่ผ่านมาไหม
เช็ค fork โดยเฉพาะ private fork และ mirror เพราะ Socket เตือนว่า fork ที่สร้างหรือ sync ตามหลังจะรับ workflow นั้นไปด้วย

ป้องกันระยะยาว: เปลี่ยนจาก "secret ที่เก็บไว้" เป็น "สิทธิ์ที่ออกให้ชั่วคราว"

ถ้าให้เลือกข้อเดียวจากบทความนี้ ผมเลือกข้อนี้: ถ้า secret ไม่ได้มีอยู่ใน repo ตั้งแต่แรก ต่อให้ workflow ตัวร้ายถูกยัดเข้ามา ก็ไม่มีอะไรให้ขโมย

1. ใช้ OIDC แทน static cloud key

สำหรับ AWS ให้ workflow ขอ role แบบชั่วคราวผ่าน OIDC แทนการเก็บ AWS_ACCESS_KEY_ID ไว้ใน secrets

permissions:
  id-token: write
  contents: read

steps:
  - uses: aws-actions/configure-aws-credentials@<pin-to-full-sha>
    with:
      role-to-assume: arn:aws:iam::123456789012:role/ci-deploy
      aws-region: ap-southeast-1

แล้วที่ trust policy ของ role ล็อก sub ให้เจาะจงถึง repo และ branch เช่น repo:your-org/your-repo:ref:refs/heads/main อย่าใช้ wildcard กว้างๆ ไม่งั้น workflow ที่ถูกยัดใน branch อื่นก็ขอ role ได้เหมือนกัน (ตัวเลข account ด้านบนเป็นตัวอย่างสมมติ)

2. ให้ `GITHUB_TOKEN` มีสิทธิ์น้อยที่สุดเป็นค่าเริ่มต้น

ตั้งที่ระดับ org/repo ให้ default เป็น read-only แล้วเปิดเพิ่มเป็นราย job เท่านั้น ใน workflow เองก็ใส่ permissions: ระบุชัดทุกไฟล์

3. บังคับ review กับโฟลเดอร์ workflow

ใช้ CODEOWNERS ชี้ .github/workflows/ ให้เป็นของทีม platform/security และเปิด branch protection ให้ต้องมี approval รวมถึง "do not allow bypassing" สำหรับ admin ด้วย กรณีนี้ attacker ใช้ identity ของ maintainer จริงๆ push ตรง ถ้า default branch ปิดการ push ตรง workflow ที่ยัดมาจะต้องผ่านคนอื่นก่อน

4. Pin action ด้วย commit SHA และจำกัดว่า action ไหนรันได้

ข้อนี้ไม่ได้กัน GhostAction รอบนี้โดยตรง (เพราะมันเป็น workflow ของตัวเอง ไม่ใช่ action ภายนอก) แต่เป็นเรื่องเดียวกันคือการลดพื้นที่ที่คนนอกแทรกโค้ดเข้า pipeline ได้ ตั้ง policy ระดับ org ให้อนุญาตเฉพาะ action ที่ approve แล้ว

5. ดักที่ปลายทาง: egress และ secret scanning

Self-hosted runner ควรมี egress policy ให้ออกได้เฉพาะปลายทางที่จำเป็น ในข่าวนี้ข้อมูลถูกส่งผ่าน HTTP ไปยัง IP เปล่าๆ ซึ่งกฎ egress ธรรมดาก็จับได้ ส่วน GitHub-hosted runner ให้ดักด้วย audit log stream ไปที่ SIEM แล้วตั้ง alert เมื่อมีไฟล์ใหม่ใน .github/workflows ที่ไม่ได้มาจาก pull request

และเปิด secret scanning กับ push protection ไว้ แต่อย่าหยุดแค่นั้น ให้สแกน history เก่าด้วยเครื่องมืออย่าง Gitleaks เป็นรอบๆ เพราะของที่เคยหลุดแล้วลบ ถ้ายังไม่ได้หมุน ก็ยังเป็นของที่ใช้ได้

ความเห็นส่วนตัวหลังไล่ข่าวนี้

สิ่งที่ผมได้จากข่าวนี้ไม่ใช่ "attacker เก่ง" เพราะเทคนิคมันเรียบมาก ไม่มี zero-day ไม่มีอะไรหรูหรา สิ่งที่ได้ผลคือสามอย่างที่เราเองเป็นคนสร้างไว้: PAT อายุยาวที่ไม่มีใครหมุน, secret ที่อยู่ใน repo ตลอดกาลรวมถึงใน history, และสิทธิ์ push ตรงเข้า default branch ที่ไม่มีใครถาม

ผมเองเคยนั่งไล่ลบ PAT เก่าของทีมแล้วเจออันที่สร้างไว้ตั้งแต่สามปีก่อน สิทธิ์ครบ ไม่มีวันหมดอายุ เจ้าของเปลี่ยนงานไปแล้ว (ขอเล่าแบบไม่ลงรายละเอียดนะ) ความรู้สึกตอนนั้นคือเย็นสันหลังวาบ ถ้าวันนั้นมันหลุดไปอยู่ใน infostealer log ใครสักคน เรื่องที่อ่านวันนี้อาจเป็นเรื่องของเราเอง

เลยอยากฝากเป็นการบ้านสั้นๆ ถ้าอ่านจบแล้วยังไม่รู้จะเริ่มตรงไหน: เปิดหน้า Personal access tokens ของตัวเอง ดูว่ามีอันไหนที่ไม่ได้ใช้แล้วหรือไม่มีวันหมดอายุ ลบเดี๋ยวนี้เลย แล้วค่อยกลับมาคุยเรื่อง OIDC กัน

สรุปเช็คลิสต์

ภาพสรุปด้านล่างเอาไปแปะเตือนทีมได้เลย

แหล่งอ้างอิงข่าว: The Hacker News (9 ต.ค. 2026) "Credential-Stealing GitHub Actions Workflows Planted in Tens of Thousands of Repositories", GitGuardian blog "GhostAction Returns: 772 Repos Hit in New GitHub Actions Wave"

Credential-Stealing GitHub Actions Workflows Planted in Tens of Thousands of Repositories

More than 500 GitHub accounts committed credential-stealing workflows to tens of thousands of repositories since October 7, Socket says.

thehackernews.com

9 คำสั่ง kubectl ที่ควรอยู่ใน muscle memory ก่อนโดนปลุกตอนตี 2

Ice — Mon, 05 Oct 2026 03:57:49 +0000

เมื่อคืนไม่ได้โดนปลุกนะ แต่ลองนึกย้อนดูว่าครั้งล่าสุดที่โดน ใช้เวลาไปกับอะไรมากที่สุด คำตอบมันน่าอายนิดนึง ไม่ใช่การแก้ปัญหา แต่เป็นการนั่งนึกว่า "jsonpath ของ lastState มันเขียนยังไงวะ" แล้วก็เปิด Google ไปสามแท็บ ขณะที่ alert ยังดังอยู่

เลยตัดสินใจรวบรวมคำสั่งที่ใช้จริงบ่อยที่สุดตอน incident มาไว้ที่เดียว ไม่ใช่ cheat sheet ยาวสามหน้าที่ไม่มีใครอ่าน แต่เป็นชุดเล็กๆ ที่เรียงตามลำดับที่ควรไล่จริงตอนของพัง ทุกคำสั่งในนี้ใช้ได้กับ cluster ทั่วไป ไม่ผูกกับ EKS ยกเว้นข้อที่บอกไว้

1. ดู Warning event ทั้ง cluster ก่อนอย่างอื่น

kubectl events -A --types=Warning

ข้อนี้คือข้อที่อยากให้ทุกคนจำได้ที่สุด เพราะมันตอบคำถาม "ตอนนี้มีอะไรแปลกๆ เกิดขึ้นบ้าง" ได้ในคำสั่งเดียว — FailedScheduling, BackOff, FailedMount, Unhealthy โผล่มาหมด

ถ้า kubectl เก่ากว่า 1.28 ที่ kubectl events ยังไม่ stable ใช้ตัวคลาสสิกแทน:

kubectl get events -A --field-selector type=Warning --sort-by=.metadata.creationTimestamp

ที่เลือก sort ด้วย creationTimestamp แทน .lastTimestamp เพราะ event รุ่นใหม่บางตัวไม่มี lastTimestamp เลย sort แล้วลำดับเพี้ยน เคยนั่งงงอยู่ห้านาทีว่าทำไม event ล่าสุดไปอยู่บนสุด อีกเรื่องที่ต้องรู้ไว้คือ event มีอายุสั้น (ค่า default ของ API server อยู่ที่ราว 1 ชั่วโมง) ถ้าตื่นมาดูช้า หลักฐานหายไปแล้ว อันนี้เป็นเหตุผลที่ควรส่ง event ไปเก็บที่อื่นด้วยตั้งแต่แรก

2. หา pod ที่ไม่ปกติ แบบไม่ต้องไล่ทั้ง namespace

kubectl get pods -A --field-selector=status.phase!=Running,status.phase!=Succeeded

กรอง Running กับ Succeeded ออก ที่เหลือคือ Pending, Failed, Unknown ล้วนๆ จุดที่ต้องระวังคือ pod ที่ CrashLoopBackOff ส่วนใหญ่ phase ยังเป็น Running อยู่นะ มันเลยไม่โผล่ในคำสั่งนี้ ต้องเสริมด้วย:

kubectl get pods -A | grep -vE 'Running|Completed' ; \
kubectl get pods -A --sort-by='.status.containerStatuses[0].restartCount' | tail -10

ตัวหลังเรียง restart count จากน้อยไปมาก tail 10 ตัวท้ายคือพวกที่รีสตาร์ทเยอะสุด ส่วนมากต้นเหตุอยู่แถวนี้แหละ

3. ถามว่า container ตายเพราะอะไร โดยไม่ต้อง describe ยาวเหยียด

kubectl get pod <pod> -o jsonpath='{range .status.containerStatuses[*]}{.name}{"\t"}{.restartCount}{"\t"}{.lastState.terminated.reason}{"\t"}{.lastState.terminated.exitCode}{"\n"}{end}'

นี่แหละตัวที่เคยต้องเปิด Google สามแท็บ ตอนนี้ทำเป็น alias ไว้แล้ว output จะได้หน้าตาประมาณ app 7 OOMKilled 137 อ่านปุ๊บรู้ปั๊บ

OOMKilled / 137 → memory limit ต่ำไป หรือแอป leak
Error / 1 → แอปตายเอง ไปดู log ต่อ
143 → โดน SIGTERM ปกติ มักเกี่ยวกับ probe fail แล้วโดน kill

kubectl describe pod ก็ให้ข้อมูลเดียวกัน แต่ต้องเลื่อนหาท่ามกลาง volume, toleration และอีกร้อยบรรทัด ตอนตี 2 สายตาไม่ไหวอ่ะ

4. Log ของรอบก่อนตาย ไม่ใช่รอบปัจจุบัน

kubectl logs <pod> -c <container> --previous --tail=100

พลาดกันบ่อยมาก (ตัวเองด้วย) คือรัน kubectl logs เฉยๆ แล้วเห็น log สวยงามของ container ที่เพิ่ง start ใหม่ ไม่มี error สักบรรทัด แล้วก็งงว่าทำไมมันพัง เพราะ error อยู่ใน instance ก่อนหน้าที่ตายไปแล้วไง --previous คือตัวช่วยชีวิต

5. ใครกิน memory เยอะสุดตอนนี้

kubectl top pod -A --containers --sort-by=memory | head -15

ต้องมี metrics-server ก่อนนะ ถ้ารันแล้วได้ error: Metrics API not available แปลว่ายังไม่ได้ลง บน EKS ลงเป็น add-on ได้เลย ใส่ --containers เพื่อให้เห็นราย container เพราะหลายครั้งตัวกิน memory ไม่ใช่แอปหลัก แต่เป็น sidecar ที่ไม่มีใครตั้ง limit ให้

6. เข้าไปส่องใน pod ที่ไม่มี shell

kubectl debug -it <pod> --image=busybox:1.36 --target=<container>

Image สมัยนี้เป็น distroless กันเยอะ ซึ่งดีด้าน security แต่พอจะ exec เข้าไปดูอะไร ก็เจอ executable file not found ทันที ephemeral container แก้ปัญหานี้ ได้ shell ที่แชร์ process namespace กับ container เป้าหมาย ดู /proc, เช็ค DNS, เช็ค network ได้โดยไม่ต้อง rebuild image

มุม DevSecOps ที่ต้องพูดถึง: สิทธิ์ pods/ephemeralcontainers มีพลังพอๆ กับ pods/exec เลยนะ ถ้าให้ใครก็ได้ใน cluster ใช้ ก็เท่ากับเปิดประตูหลังเอง ควรจำกัดไว้ที่ role ของ on-call และให้ audit log จับไว้ด้วย ใน kubectl รุ่นใหม่ใส่ --profile=restricted ได้เพื่อไม่ให้ debug container ได้ privilege เกินจำเป็น

7. ตรวจว่า pod ถือ IAM role ไหนอยู่ (เฉพาะ EKS)

kubectl get sa <sa-name> -n <ns> -o jsonpath='{.metadata.annotations.eks\.amazonaws\.com/role-arn}{"\n"}'
kubectl exec <pod> -- printenv AWS_ROLE_ARN

บรรทัดแรกดูว่า ServiceAccount ผูก role ไว้ยังไง บรรทัดสองดูว่า pod ที่รันอยู่จริงได้ role นั้นมาหรือยัง เพราะเคยเจอเคสแก้ annotation แล้วลืม restart pod — SA บอกว่าถูก แต่ pod เก่ายังไม่มี env ตัวนี้เลย AccessDenied รัวๆ

ถ้า cluster ใช้ EKS Pod Identity แทน IRSA จะไม่มี AWS_ROLE_ARN แต่จะเห็น AWS_CONTAINER_CREDENTIALS_FULL_URI แทน อย่าเพิ่งตกใจว่ามันหาย ส่วนการ printenv ทั้งก้อนออกมาดู ไม่แนะนำ เพราะบางทีมยัง inject secret ผ่าน env อยู่ ระบุชื่อ env ที่ต้องการไปเลยดีกว่า

8. Rollback แบบรู้ว่ากำลังย้อนไปไหน

kubectl rollout history deploy/<name>
kubectl rollout history deploy/<name> --revision=<N>
kubectl rollout undo deploy/<name> --to-revision=<N>

kubectl rollout undo เฉยๆ จะถอยไปหนึ่ง revision ฟังดูโอเค จนวันที่มีคน deploy ซ้อนกันสองรอบในสิบนาที แล้วถอยหนึ่งขั้นก็ยังไปเจอเวอร์ชันพังอยู่ดี ดู history ก่อนเสมอ บรรทัดที่สองโชว์ image tag ของ revision นั้นให้ด้วย จะได้มั่นใจว่ากำลังย้อนไปตัวที่ดีจริง

ข้อสังเกตสำหรับทีมที่ใช้ GitOps (Argo CD/Flux): rollback ด้วย kubectl ตรงๆ จะโดน sync ทับกลับภายในไม่กี่นาที ต้อง revert ที่ Git หรือ pause auto-sync ก่อน ไม่งั้นจะงงว่าทำไม rollback แล้วมันกลับมาพังเอง

9. Control plane ยังดีอยู่มั้ย

kubectl get --raw='/readyz?verbose'

ข้อนี้ไม่ค่อยได้ใช้ แต่ตอนที่ต้องใช้คือสำคัญมาก โดยเฉพาะเวลาที่ kubectl ช้าผิดปกติ หรือ webhook timeout รัวๆ ผลลัพธ์จะไล่ check ทีละตัว [+]etcd ok, [+]informer-sync ok ถ้ามีตัวไหนเป็น [-] ก็รู้เลยว่าไม่ใช่ปัญหาที่แอป

บน EKS ปกติ control plane AWS ดูแลให้ แต่ admission webhook ที่เราลงเอง (เช่น policy engine) ถ้าล่มหรือช้า ก็ทำให้ทุก request ไป API server ช้าตามได้ เคสนี้ดู kubectl get validatingwebhookconfigurations ประกอบ แล้วเช็คว่า failurePolicy ตั้งไว้เป็นอะไร

ทำเป็น alias ไว้ ไม่ต้องจำ

ไม่มีใครจำ jsonpath ได้หรอก 555 ใส่ลง ~/.zshrc หรือ ~/.bashrc ไปเลย:

alias kwarn='kubectl events -A --types=Warning'
alias kbad='kubectl get pods -A --field-selector=status.phase!=Running,status.phase!=Succeeded'
alias ktopmem='kubectl top pod -A --containers --sort-by=memory | head -15'

kwhy() {
  kubectl get pod "$1" -n "${2:-default}" -o jsonpath='{range .status.containerStatuses[*]}{.name}{"\t"}{.restartCount}{"\t"}{.lastState.terminated.reason}{"\t"}{.lastState.terminated.exitCode}{"\n"}{end}'
}

ใช้ kwhy my-pod prod แล้วได้คำตอบเลย ไม่ต้องเปิดแท็บไหนทั้งนั้น

ลำดับที่ใช้จริง

ถ้าต้องสรุปเป็นลำดับเดียวตอนโดนปลุก: เริ่มจาก event (ข้อ 1) → หา pod ที่ผิดปกติ (ข้อ 2) → ถามว่าตายเพราะอะไร (ข้อ 3) → อ่าน log รอบก่อน (ข้อ 4) → ถ้าเป็นเรื่อง resource ดู top (ข้อ 5) → ถ้ายังไม่เจอ ค่อยเข้าไปส่อง (ข้อ 6) → ถ้าเป็นเรื่องสิทธิ์ AWS ไปข้อ 7 → ถ้าต้องหยุดเลือดก่อน rollback (ข้อ 8)

ส่วนใหญ่จบที่ข้อ 3-4 แล้ว ที่เหลือเป็นของสำรองไว้วันที่ดวงไม่ดี

ไม่ได้บอกว่านี่คือชุดคำสั่งที่ดีที่สุดในโลกนะ แต่เป็นชุดที่หยิบใช้จริงบ่อยสุดจากที่ผ่านมา ใครมี one-liner ตัวเด็ดที่ช่วยชีวิตตอนดึกๆ มาแชร์กันได้ อยากขโมยไปใส่ alias เพิ่มเหมือนกัน

เลิกแปะ AWS key ใน Pod ได้แล้ว — IRSA, least privilege และ audit trail ที่คุมได้จริง

Ice — Mon, 27 Jul 2026 05:18:02 +0000

เจอ Pod ตัวหนึ่งใน cluster เก่าที่ mount ~/.aws/credentials แบบ static key เข้าไปตรงๆ เมื่ออาทิตย์ก่อน — key นั้นสร้างมาตั้งแต่ปีก่อน ไม่เคย rotate เลยสักครั้ง แล้ว policy ที่แนบก็คือ AdministratorAccess ตรงๆ เพราะตอนนั้นมีคนรีบ deploy ให้ทันและไม่มีเวลานั่งไล่ permission ทีละตัว เจอแบบนี้แล้วสะอึกนิดหน่อย เพราะ Pod นั้นแค่ต้องอ่าน object จาก S3 bucket เดียว แต่ดันถือกุญแจทั้งบ้านไว้

เรื่องนี้เป็นปัญหาคลาสสิกของ IAM บน EKS ที่หลายทีมยังเจอ วันนี้เลยอยากพาดูสามเรื่องที่มักโดนมองข้ามพร้อมกัน: IRSA แทน static key, least privilege ที่ทำได้จริงไม่ใช่แค่ทฤษฎี และ audit logging ที่ตอบคำถามได้เวลามีคนถามว่า "ใครทำอะไรตอนไหน"

ทำไม static IAM key ถึงเป็นปัญหา

Key แบบ long-lived มีปัญหาซ้อนกันสามชั้น หนึ่งคือมันไม่หมดอายุเองถ้าไม่ตั้ง rotation policy เอาไว้ สองคือมันมักถูกแปะไว้ใน config file, environment variable หรือแย่กว่านั้นคือ commit เข้า repo โดยไม่ตั้งใจ (Gitleaks เจอเคสนี้บ่อยมาก) สามคือมันผูกกับ Pod ทุกตัวเท่ากันหมด ไม่ว่า Pod นั้นจะทำหน้าที่อะไร ถ้า Pod หนึ่งโดน compromise ก็เท่ากับ credential ทั้งชุดโดนไปด้วย

IRSA (IAM Roles for Service Accounts) แก้ปัญหานี้ตรงจุด คือให้แต่ละ Kubernetes ServiceAccount ผูกกับ IAM Role ผ่าน OIDC provider ของ EKS cluster เอง ไม่มี static key ไม่มีไฟล์ credential ต้องจัดการ Pod ขอ token ชั่วคราวผ่าน service account token ที่ EKS สร้างให้อัตโนมัติ แล้ว AWS SDK ฝั่ง Pod จะ assume role ผ่าน STS ให้เอง

ตั้ง IRSA แบบคร่าวๆ

ก่อนอื่นต้องเปิด OIDC provider ให้ cluster (ถ้ายังไม่เปิด):

eksctl utils associate-iam-oidc-provider \
  --cluster my-cluster \
  --approve

จากนั้นสร้าง IAM Role ที่มี trust policy ผูกกับ OIDC provider และ namespace/service account เจาะจง ไม่ใช่แบบเปิดกว้าง:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Federated": "arn:aws:iam::<account-id>:oidc-provider/<oidc-provider-url>"
    },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "<oidc-provider-url>:sub": "system:serviceaccount:my-namespace:my-app-sa",
        "<oidc-provider-url>:aud": "sts.amazonaws.com"
      }
    }
  }]
}

จุดสำคัญคือ sub ต้องระบุ namespace และ service account name ตรงตัว ไม่ใช่ wildcard เพราะถ้าเปิดกว้างเกินไป Pod อื่นใน cluster ที่ไม่เกี่ยวก็จะ assume role นี้ได้ด้วย เท่ากับย้อนกลับไปปัญหาเดิม

ฝั่ง Kubernetes ก็แค่ annotate ServiceAccount:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: my-namespace
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::<account-id>:role/my-app-s3-reader

แล้ว Deployment ก็ชี้ไปใช้ ServiceAccount นี้ตามปกติ ไม่ต้องแตะ SDK code เลยด้วยซ้ำ เพราะ AWS SDK เวอร์ชันใหม่ๆ รู้จัก AWS_WEB_IDENTITY_TOKEN_FILE ที่ EKS inject ให้อัตโนมัติอยู่แล้ว

Least privilege ที่ทำได้จริง ไม่ใช่แค่คำสวยๆ

ปัญหาของ least privilege คือทุกคนรู้ว่าดี แต่พอถึงเวลาจริงมักจะแนบ policy กว้างไว้ก่อนเพราะกลัวแอพพัง ตรงนี้มีวิธีที่พอช่วยได้บ้าง:

หนึ่ง เริ่มจาก policy แคบสุดเท่าที่รู้ว่าแอพต้องใช้ อย่างเคส S3 reader ด้านบน ควรจำกัด action ให้เหลือแค่ s3:GetObject และ s3:ListBucket บน ARN ของ bucket ที่ใช้จริงเท่านั้น ไม่ใช่ s3:* บน *

สอง ใช้ IAM Access Analyzer ช่วยดู policy ที่ generate จาก CloudTrail log ย้อนหลัง มันจะบอกว่า role นี้เรียก action อะไรบ้างจริงๆ ในช่วงที่ผ่านมา เอาผลนั้นมาเทียบกับ policy ที่แนบอยู่ ถ้าเจอ action ที่ไม่เคยถูกเรียกเลยใน 90 วัน ก็เป็นตัวเลือกแรกๆ ที่ควรตัดออก

สาม แยก Role ตามหน้าที่ อย่าใช้ Role เดียวกันสำหรับหลายๆ microservice เพราะแม้แต่ละ service จะ "ดูคล้ายกัน" แต่ blast radius ตอนมีปัญหาจะต่างกันมาก ถ้า Role เดียวใช้ร่วมกันสิบ service แล้ว service หนึ่งโดนเจาะ อีกเก้าก็เสี่ยงไปด้วย

Secrets ที่ไม่ใช่ IAM

Secrets management เป็นอีกเรื่องที่มักปนกับ IAM แต่จริงๆ ควรแยก IAM คือควบคุมว่า "ใคร/อะไรทำอะไรได้" ส่วน secrets คือ "ข้อมูลลับที่แอพต้องใช้" เช่น database password, API key ของ third-party ที่ไม่ใช่ AWS

แนวทางที่ใช้ได้จริงคือเก็บใน AWS Secrets Manager หรือ Parameter Store (SecureString) แล้วดึงเข้า Kubernetes ผ่าน External Secrets Operator แทนการฝัง secret ไว้ใน manifest หรือ Helm values ตรงๆ

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-credentials
  namespace: my-namespace
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: SecretStore
  target:
    name: db-credentials-k8s
  data:
    - secretKey: password
      remoteRef:
        key: prod/my-app/db-password

ตรงนี้ IRSA ก็เข้ามาช่วยอีกชั้น เพราะ External Secrets Operator เองก็ต้องมี permission อ่าน Secrets Manager ซึ่งควรผูกผ่าน IRSA เช่นกัน ไม่ใช่ static key เหมือนกัน วนกลับมาที่หลักการเดิม

Audit logging — ตอบคำถามได้เวลาต้องสืบ

Least privilege ช่วยลดความเสียหายถ้ามีอะไรผิดพลาด แต่ audit log คือสิ่งที่ตอบได้ว่า "เกิดอะไรขึ้นจริง" เปิด CloudTrail ให้ log ทุก management event เป็นพื้นฐานที่ควรมีอยู่แล้ว แต่ที่มักถูกลืมคือ data event ของ S3 และ Lambda ซึ่งไม่เปิดมาให้ default ต้องเปิดเพิ่มเอง ถ้า bucket เก็บข้อมูลสำคัญแต่ไม่ได้เปิด data event ไว้ ตอนเกิดเหตุจะสืบย้อนไม่ได้ว่ามีใคร GetObject ไฟล์ไหนไปบ้าง

อีกจุดคือ EKS control plane logging เอง แนะนำให้เปิดอย่างน้อย audit และ authenticator log type ส่งเข้า CloudWatch Logs เพราะ log พวกนี้จะโชว์ว่า service account ไหน call Kubernetes API อะไร ซึ่งเวลาต้อง correlate กับ CloudTrail (ฝั่ง AWS API) จะได้ภาพครบทั้งสองชั้น ทั้ง container orchestration และ cloud resource

สุดท้ายคือให้ log พวกนี้ไป SIEM หรืออย่างน้อยตั้ง alert บน pattern ที่ผิดปกติ เช่น AssumeRole จาก IP แปลกๆ หรือ IAM policy ถูกแก้ตอนดึกนอกเวลางาน มี log เก็บไว้เฉยๆ โดยไม่มีคนดูก็แทบไม่ต่างจากไม่มี log

สรุปสั้นๆ

ทั้งสามเรื่องนี้เกี่ยวโยงกันเป็นชั้นๆ IRSA ตัดปัญหา static credential ที่จุดตั้งต้น least privilege จำกัดความเสียหายถ้า Role หลุด และ audit logging ทำให้สืบย้อนได้เมื่อมีเหตุ ทำแค่อย่างเดียวไม่พอ ต้องทำควบคู่กันถึงจะปิดช่องโหว่ได้จริง เคส Pod ที่ถือ Admin key ที่เล่าไปตอนต้น สุดท้ายก็แก้ด้วยการย้ายไป IRSA พร้อม policy เฉพาะ S3 bucket เดียว ใช้เวลาไม่ถึงบ่ายวันนั้นเอง แค่ต้องมีคนมานั่งไล่ก่อนว่า Pod นี้ต้องใช้ permission อะไรจริงๆ

วาง LLM Gateway ด้วย LiteLLM Proxy: คุม cost, token budget และ failover เวลาต้องยิงหลาย provider พร้อมกัน

Ice — Mon, 20 Jul 2026 07:34:08 +0000

เดือนก่อนทีมงานหนึ่งที่คุยด้วยมาบ่นให้ฟังว่า bill LLM ของเดือนนั้นพุ่งขึ้นเกือบ 3 เท่าโดยไม่มีใครรู้ตัวจนบิลออก สาเหตุไม่ใช่ traffic เพิ่ม แต่เป็นเพราะทีม dev คนหนึ่งเปลี่ยน model จาก Haiku ไปเป็น Opus ใน service เดียวเพื่อ debug แล้วลืมเปลี่ยนกลับ ปัญหาคือไม่มีใคร monitor ระดับ per-service เลย เพราะแต่ละทีมยิง API ตรงเข้า provider ของตัวเอง ใครใช้ key ใคร ใครยิงเท่าไหร่ ไม่มี central view

นี่คือปัญหาคลาสสิกของทีมที่โตเร็วแล้วเริ่มใช้ LLM หลาย provider พร้อมกัน (Bedrock, OpenAI, Anthropic API ตรง) โดยไม่มี layer กลางคั่นระหว่าง application กับ provider เลย

ทำไม direct integration ถึงพังตอนสเกล

ตอนมี 1-2 service เรียก LLM ตรงมันโอเค แต่พอเกิน 5 service ขึ้นไป ปัญหาที่เจอซ้ำๆ คือ

Key กระจัดกระจาย — แต่ละ service มี API key ของตัวเอง เก็บใน env var บ้าง Secrets Manager บ้าง ไม่มี pattern เดียวกัน
ไม่มี cost visibility ระดับทีม/โปรเจกต์ — เห็นแต่บิลรวมท้ายเดือน ไม่รู้ว่าใครใช้เท่าไหร่
Rate limit ชนกันเอง — service A กับ B ใช้ key เดียวกันของ provider เดียวกัน พอ A ยิงหนักช่วงพีค B โดน throttle ไปด้วยทั้งที่ไม่เกี่ยว
Provider ล่มแล้วจบเลย — Bedrock throttle หรือ region มีปัญหา ไม่มี fallback ไป provider อื่นอัตโนมัติ ต้องรอ manual fix
Format ไม่ตรงกัน — สลับจาก Anthropic API ไป Bedrock ต้องแก้ code เพราะ request/response shape ไม่เหมือนกัน

วิธีแก้ที่หลายทีมใช้ตอนนี้คือใส่ LLM gateway คั่นกลาง — จุดเดียวที่ทุก service ยิงผ่าน แล้ว gateway เป็นคนจัดการ routing, budget, retry ให้แทน

LiteLLM Proxy ทำอะไรได้บ้าง

LiteLLM Proxy คือ open-source proxy ที่รองรับ provider เกือบทุกเจ้า (OpenAI, Anthropic, Bedrock, Vertex, Azure OpenAI ฯลฯ) ผ่าน interface แบบเดียวกันคือ OpenAI-compatible API ตัว application ฝั่ง client ไม่ต้องรู้เลยว่าข้างหลังยิงไป provider ไหน แค่เรียก endpoint เดียว แล้ว proxy จัดการ routing เอง

Config พื้นฐานหน้าตาประมาณนี้ (ตัวอย่าง ไม่ใช่ค่าจริงจาก production ใดๆ):

model_list:
  - model_name: gpt-tier-fast
    litellm_params:
      model: bedrock/anthropic.claude-3-haiku-20240307-v1:0
      aws_region_name: ap-southeast-1
  - model_name: gpt-tier-fast
    litellm_params:
      model: openai/gpt-4o-mini
      api_key: os.environ/OPENAI_API_KEY

router_settings:
  routing_strategy: latency-based-routing
  fallbacks: [{"gpt-tier-fast": ["gpt-tier-fast-backup"]}]

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  database_url: os.environ/DATABASE_URL

สังเกตว่า model_name เดียวกัน (gpt-tier-fast) ผูกกับ 2 provider — นี่คือจุดที่ทำให้ failover เกิดขึ้นได้แบบ transparent ถ้า Bedrock throttle proxy จะ route ไป OpenAI ให้เองโดย client ไม่ต้องรู้เลย

Token budgeting ต่อทีม ไม่ใช่ต่อบิลรวม

จุดที่ช่วยเรื่อง cost control จริงๆ คือ virtual key แต่ละทีม/โปรเจกต์ขอ key จาก proxy ได้ พร้อมตั้ง budget แยกกัน

curl -X POST http://litellm-proxy:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -d '{
    "models": ["gpt-tier-fast"],
    "max_budget": 50,
    "budget_duration": "30d",
    "team_id": "rag-search-team"
  }'

ทีมไหนเกิน budget key จะถูก block อัตโนมัติ ไม่ต้องรอ finance มาเคาะไหล่ตอนสิ้นเดือน แล้วก็มี dashboard ในตัวให้ดูว่า spend ต่อ team ต่อ model เป็นยังไง อันนี้คือสิ่งที่แก้เคส "เปลี่ยน model แล้วลืมเปลี่ยนกลับ" ได้ตรงจุด เพราะ budget alert จะเด้งก่อนบิลจะบาน ไม่ใช่รู้ตัวหลังบิลออกแล้ว

Failover ที่ต้องคิดมากกว่า retry เฉยๆ

Retry แบบ naive (ยิงซ้ำเมื่อ error) อันตรายกว่าที่คิด โดยเฉพาะถ้า error เป็น rate limit จริง retry รัวๆ จะยิ่งซ้ำเติมปัญหา สิ่งที่ควรตั้งคือ

Exponential backoff สำหรับ retry ไป provider เดิม (2-3 ครั้งพอ)
Fallback ไป model/provider สำรอง ถ้า retry เดิมไม่ผ่าน ไม่ใช่ retry ไม่จำกัดรอบ
Cooldown period — ถ้า provider หนึ่งพัง ให้ proxy จำไว้สักพัก (เช่น 60 วินาที) ก่อนลองยิงกลับไปใหม่ ไม่ใช่ลองทุก request
Timeout ที่สมเหตุสมผลต่อ use case — chat แบบ interactive timeout สั้นได้ (10-15s) แต่ถ้าเป็น batch summarization ปล่อยยาวกว่านั้นได้

เคยเจอเคสจริงที่ setup fallback ไว้แล้ว แต่ timeout ตั้งไว้สั้นเกินไป (5 วินาที) ผลคือ request ที่ปกติจะสำเร็จถ้ารอสัก 8 วินาที กลับ fallback ไป provider สำรองทุกครั้งเพราะ timeout ก่อน กลายเป็นจ่ายแพงขึ้นโดยไม่จำเป็นเพราะ provider สำรองแพงกว่า บทเรียนคือ tuning timeout สำคัญพอๆ กับ setup fallback logic เอง

RAG กับ proxy — จุดที่มักมองข้าม

ถ้าใช้ RAG pipeline ต้องแยกให้ชัดระหว่าง embedding call กับ generation call เพราะสอง workload นี้ pattern การใช้ต่างกันมาก embedding มัก burst หนักตอน ingest เอกสารใหม่ ส่วน generation กระจายตาม user traffic ถ้าใช้ virtual key เดียวกันสำหรับทั้งคู่ budget/rate limit จะปนกัน แนะนำแยก key ต่อ workload type ไปเลย จะได้ตั้ง rate limit ที่เหมาะกับแต่ละแบบจริงๆ ไม่ใช่เผื่อไว้กว้างๆ จนคุมไม่ได้

Checklist ก่อนเอาเข้า production

แยก virtual key ต่อทีม/โปรเจกต์ ไม่ใช้ master key ยิงตรงจาก application
ตั้ง max_budget + budget_duration ให้ทุก key ตั้งแต่วันแรก ไม่ใช่ค่อยตั้งทีหลังตอนบิลบาน
Map model tier (fast/cheap vs premium) แทนการ hardcode ชื่อ model เฉพาะเจาะจงใน application code
ตั้ง fallback chain อย่างน้อย 1 ชั้น ต่อ model tier ที่สำคัญ
Tune timeout แยกตาม use case (interactive vs batch) อย่าใช้ค่า default เดียวกันทั้งระบบ
แยก key ระหว่าง embedding workload กับ generation workload
เปิด logging ระดับ request ไปที่ observability stack ที่มีอยู่แล้ว (อย่าผูกกับ dashboard ของ proxy อย่างเดียว เผื่อวันหนึ่งย้ายออกจาก LiteLLM)
ทดสอบ failover จริงด้วยการปิด provider หลักชั่วคราวใน staging ก่อนเชื่อว่ามันทำงาน อย่าเชื่อแค่ตาม config

ส่วนที่คนมักข้ามคือข้อสุดท้าย — เขียน fallback config ไว้แล้วไม่เคยทดสอบจริงว่ามัน trigger ตอนไหน พอวันที่ provider หลักล่มจริงถึงจะรู้ว่า config ผิดจุดไหน ซึ่งเป็นเวลาที่แย่ที่สุดที่จะเพิ่งมาเจอ bug

Gateway แบบนี้ไม่ได้แก้ทุกปัญหา ถ้าทีมเล็กมากมี service เดียวยิง provider เดียว อาจจะ overkill เกินไปด้วยซ้ำ แต่พอเริ่มมีมากกว่า 1 provider หรือมากกว่า 3-4 service ที่ยิง LLM เป็นเรื่องปกติ การมี layer กลางแบบนี้ช่วยประหยัดเวลา debug และเงินได้เยอะกว่าที่คิดตอนแรก

เมื่อ annotation ของ ALB Ingress เยอะจนอ่านไม่ไหว — ถึงเวลาคุยเรื่อง Gateway API บน EKS หรือยัง

Ice — Mon, 13 Jul 2026 04:28:47 +0000

เปิด ingress.yaml ของ service หนึ่งใน cluster ที่เคยดูแล แล้วนับ annotation ได้ 17 บรรทัด ตั้งแต่ alb.ingress.kubernetes.io/scheme, target-type, certificate-arn, ssl-policy, healthcheck-path, ไปจนถึง actions.weighted-routing ที่เป็น JSON string ยัดอยู่ในค่า annotation ตัวเดียว อ่านครั้งแรกงงเลยว่า string นี้คือ routing rule จริง ๆ ไม่ใช่ comment ที่ลืมลบ

นี่แหละคือจุดที่ทำให้เริ่มมองหาทางอื่น ไม่ใช่เพราะ ALB Ingress Controller ห่วยนะ มันเสถียรมากด้วยซ้ำ ใช้กันมาเป็นมาตรฐานของ EKS หลายปีแล้ว แต่พอ cluster โตขึ้น มีหลายทีมมาแชร์กัน ปัญหาที่ annotation-based config มันไม่เคยถูกออกแบบมาแก้ ก็เริ่มโผล่ทีละอย่าง

ปัญหาที่ ALB Ingress Controller ไม่ได้ถูกออกแบบมาแก้

Ingress resource แบบเดิมมีข้อจำกัดที่ฝังอยู่ใน spec ตั้งแต่ต้น คือมันถูกออกแบบมาให้เป็น resource เดียว ครอบทุกอย่างตั้งแต่ layer 7 routing ไปจนถึง TLS termination ไปจนถึง load balancer attribute เฉพาะของ cloud provider — ทั้งหมดนี้ยัดผ่าน annotation ที่เป็น string ธรรมดา ไม่มี schema validation ไม่มี type checking พิมพ์ผิดตัวเดียวก็ deploy ผ่านเฉยๆ แล้วไปพังตอน runtime

ปัญหาที่เจอบ่อยที่สุดมีสามเรื่อง

เรื่องแรกคือ ownership ปนกัน ทีม platform ที่ดูแล load balancer scheme, security group, WAF association กับทีม app ที่แค่อยากเพิ่ม path ใหม่ ต้องมาแก้ resource เดียวกัน แก้ผิดจุดทีนึงกระทบทั้ง service เพราะ annotation ผูกกับ Ingress object ทั้งก้อน ไม่ได้แยกตาม concern

เรื่องที่สองคือ cross-namespace routing ทำได้ยาก อยากให้ path หนึ่งของ domain เดียวกันชี้ไป service ที่อยู่คนละ namespace ต้องเล่นทริค เช่น ExternalName service หรือรวม Ingress ไว้ namespace เดียวแล้วเปิดสิทธิ์ backend ข้าม namespace ซึ่งขัดกับ multi-tenant model ที่ EKS ส่วนใหญ่ใช้กันตอนนี้

เรื่องที่สามคือ debug ยาก เวลา routing ไม่ทำงานตามที่คิด ต้องไล่อ่าน annotation string ทีละตัว เทียบกับ AWS Load Balancer Controller log แล้วเดาว่า controller ตีความ annotation ยังไง เพราะ syntax ของ annotation ไม่ได้มี IDE autocomplete หรือ kubectl validation ช่วยเลย

Gateway API คืออะไร ทำไมถึงถูกพูดถึงเยอะขึ้น

Gateway API เป็น evolution ของ Ingress ที่ SIG-Network ผลักดันมาหลายปี จนตัว core API (v1) graduate เป็น GA ไปแล้ว หัวใจของมันคือการแยก role ออกจากกันเป็นสาม layer

GatewayClass เป็นของ cluster operator กำหนดว่า controller ตัวไหนจะจัดการ (เช่น AWS Gateway API Controller หรือ Istio) Gateway เป็นของทีม platform กำหนด listener, port, TLS cert, ผูกกับ load balancer จริง ส่วน HTTPRoute (หรือ GRPCRoute, TCPRoute) เป็นของทีม app แก้ path/routing rule ของตัวเองได้โดยไม่ต้องแตะ Gateway เลย

ข้อดีที่เห็นชัดสุดคือทีม app ขอ HTTPRoute resource แยกของตัวเอง อยู่คนละ namespace กับ Gateway ได้เลย ผ่าน ReferenceGrant ที่ทีม platform เป็นคนอนุญาตไว้ล่วงหน้า ทีม app ไม่ต้องรอ platform ทีมมาแก้ Ingress ก้อนใหญ่ทุกครั้งที่จะเพิ่ม path ใหม่

อีกจุดที่ต่างชัดคือ extensibility ผ่าน Policy attachment แทนการยัด annotation รวมกันหมด เช่นจะทำ retry policy หรือ traffic split ก็สร้างเป็น CRD แยกต่างหาก ผูกกับ Gateway/HTTPRoute ผ่าน targetRef ทำให้ตรวจสอบและ validate แยกเป็นชิ้นๆ ได้ ไม่ต้อง parse string เดา syntax เหมือนเดิม

เทียบกันตรงๆ

ลองแตกเป็นภาพเปรียบเทียบไว้ (ดูรูปประกอบด้านล่าง) สรุปสั้นๆ ตรงนี้ก่อน

ALB Ingress Controller ยังเป็นตัวเลือกที่ดีถ้า cluster เล็ก ทีมเดียวดูแลทั้งหมด ไม่ต้องการ cross-namespace routing ซับซ้อน และอยากได้ความเสถียรที่ผ่านการใช้งานจริงมานาน ส่วน Gateway API เหมาะกับ cluster ที่มีหลายทีมแชร์กัน ต้องการแยก ownership ชัดเจน หรือกำลังจะไปทาง multi-cluster/service mesh ในอนาคต เพราะ Gateway API ถูกออกแบบให้ทำงานร่วมกับ mesh ได้ตั้งแต่ต้น ไม่ใช่ patch ทีหลังแบบ Ingress

จุดที่ต้องคิดหนักคือ maturity ของ AWS Gateway API Controller เอง มันเป็นคนละ binary กับ AWS Load Balancer Controller ที่ใช้กับ Ingress อยู่แล้ว ต้อง install แยก และ feature parity บางตัวอย่าง sticky session, custom health check attribute ยังตามหลัง ALB Ingress Controller อยู่พอสมควร ถ้าจะย้ายต้องเช็ค feature ที่ใช้จริงในทีมก่อนว่ารองรับหรือยัง อย่าเชื่อ marketing slide เฉยๆ

ตัวอย่างการแปลงจาก Ingress annotation เป็น Gateway API

Ingress แบบเดิมที่ทำ weighted routing ระหว่างสอง service หน้าตาประมาณนี้

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: checkout
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/actions.weighted-routing: >
      {"type":"forward","forwardConfig":{"targetGroups":[
        {"serviceName":"checkout-v1","servicePort":"80","weight":90},
        {"serviceName":"checkout-v2","servicePort":"80","weight":10}
      ]}}
spec:
  rules:
    - http:
        paths:
          - path: /checkout
            pathType: Prefix
            backend:
              service:
                name: weighted-routing
                port:
                  name: use-annotation

แปลงเป็น Gateway API แยกเป็นสองไฟล์ ทีม platform ดูแล Gateway ทีม app ดูแล HTTPRoute

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shared-gw
  namespace: platform-ingress
spec:
  gatewayClassName: amazon-vpc-lattice   # หรือ eks-alb ตาม controller ที่ใช้
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: Selector
          selector:
            matchLabels:
              gateway-access: allowed
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: checkout-route
  namespace: checkout-team
spec:
  parentRefs:
    - name: shared-gw
      namespace: platform-ingress
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /checkout
      backendRefs:
        - name: checkout-v1
          port: 80
          weight: 90
        - name: checkout-v2
          port: 80
          weight: 10

เห็นความต่างชัดๆ คือ weight ไม่ใช่ JSON string ที่ซ่อนใน annotation อีกแล้ว มันเป็น field จริงใน spec ที่ kubectl validate ได้ และทีม checkout แก้ HTTPRoute ของตัวเองได้เลยโดยไม่ต้องขอ access ไปแก้ Gateway ที่ platform ทีมดูแล

Checklist ก่อนตัดสินใจย้ายจริง

ถ้าคิดจะย้ายจริง อย่าทำทีเดียวทั้ง cluster ทำตามลำดับนี้ดีกว่า

เช็ค EKS version ก่อน แนะนำ 1.28 ขึ้นไปเพื่อความเข้ากันได้ของ CRD ที่ Gateway API ต้องการ
Inventory annotation ทั้งหมดที่ใช้อยู่จริงใน Ingress ปัจจุบัน แล้ว map ทีละตัวว่ามี field ตรงใน Gateway API หรือต้องใช้ Policy attachment เสริม
Install AWS Gateway API Controller แยกต่างหาก อย่า uninstall AWS Load Balancer Controller เดิมทันที ให้รันคู่กันไปก่อนช่วง migration
เลือก namespace ที่ non-critical สุดมา pilot ก่อน วัด behavior จริงของ weighted routing, health check, TLS
ตรวจ feature parity ที่ทีมใช้จริง เช่น sticky session, custom timeout ว่า controller เวอร์ชันที่ใช้รองรับหรือยัง
อัปเดต GitOps repo / Helm chart ให้ generate CRD ใหม่แทน Ingress annotation แล้ว review diff ให้ทีม platform เห็นก่อน merge
เตรียม rollback plan ไว้เสมอ เผื่อ controller ที่ใช้ยังอยู่ใน early adoption แล้วเจอ edge case ที่ไม่คาดคิด

ข้อสุดท้ายสำคัญสุด อย่าลืมว่า AWS Gateway API Controller ยังใหม่กว่า AWS Load Balancer Controller มาก edge case ที่ไม่มีคนเจอมาก่อนมีสิทธิ์โผล่ได้เสมอ ย้ายแบบค่อยเป็นค่อยไป ดีกว่าเปลี่ยนทีเดียวแล้วมานั่งแก้กลางดึก

จะย้ายเลยไหม

ถ้า cluster เล็ก ทีมเดียวดูแล ALB Ingress Controller ยังทำงานได้ดีอยู่ ไม่ต้องรีบย้ายเพราะกระแส แต่ถ้าเริ่มเห็นสัญญาณแบบที่เล่าไปตอนต้น คือ annotation เยอะจนอ่านไม่ไหว หลายทีมแย่งกันแก้ Ingress ก้อนเดียว หรือกำลังวางแผนไปทาง service mesh ในปีหน้าอยู่แล้ว Gateway API คุ้มที่จะเริ่มทดลองตอนนี้ เพราะ ecosystem กำลังโตเร็ว รอช้าไปอาจต้อง migrate แบบเร่งรีบทีหลัง

วางเลเยอร์ security scan ใน pipeline ยังไงไม่ให้ dev เกลียด

Ice — Fri, 10 Jul 2026 02:06:42 +0000

มีอยู่ช่วงนึงที่ pipeline เราช้าลงจาก 4 นาทีเป็น 18 นาที แล้วทุกคนก็เริ่มบ่น จนเกือบมีมติให้ปิด security scan บางตัวทิ้งเพื่อความเร็ว นั่นแหละคือจุดที่รู้ตัวว่าเราวาง scanning layer ผิดตั้งแต่ต้น ไม่ใช่เพราะ tool ห่วย แต่เพราะยัดทุกอย่างไว้จุดเดียวแล้วรันตามลำดับแบบโง่ๆ

เรื่องนี้เลยอยากเขียนสรุปไว้ว่าจริงๆ แล้ว pipeline ที่มี security gate ครบ ไม่จำเป็นต้องช้า ไม่จำเป็นต้องทำให้ dev ด่า ถ้าวางเลเยอร์ให้ถูกจุด

ทำไมต้องมีหลายเลเยอร์ ไม่ใช่ tool เดียวจบ

คำถามที่เจอบ่อยคือ "ทำไมไม่ใช้ตัวเดียวสแกนให้หมดเลย" คำตอบสั้นๆ คือไม่มี tool ตัวไหนสแกนทุกชั้นได้ดีเท่ากันหมด แต่ละตัวถูกออกแบบมาสำหรับ attack surface คนละแบบ:

Secret ที่หลุดเข้า commit — ต้องใช้ tool ที่สแกนเนื้อหา diff/history โดยเฉพาะ
Logic bug และ security anti-pattern ในโค้ด — ต้องใช้ static analysis ที่เข้าใจ syntax ของภาษานั้นจริงๆ
Vulnerability ใน dependency ที่ดึงมาใช้ — ต้องเทียบกับ CVE database
ช่องโหว่ใน base image ตอน build container — ต้องสแกนที่ layer ของ image ไม่ใช่ source code

รวมเป็น scan ตัวเดียวไม่ได้ เพราะแต่ละอันมองคนละมุม ทีมเราเลยจบที่ 4 ชั้น: Gitleaks, Semgrep, OWASP Dependency-Check (กับ OSV เสริม), แล้วก็ Trivy

เลเยอร์ที่ 1: Gitleaks — ดักตั้งแต่ก่อน commit หลุด

Gitleaks เป็นด่านแรกที่ต้องไวที่สุด เพราะ secret ที่หลุดเข้า git history แล้วลบยากกว่าที่คิดเยอะ ต่อให้ force-push ทับ commit ปัจจุบัน key เก่าก็ยังอยู่ใน history เดิม (เว้นแต่จะ rewrite history ทั้ง repo ซึ่งเจ็บกว่าเดิมอีก)

ทีมเราวาง Gitleaks ไว้ 2 จุด:

pre-commit hook — เบาสุด รันแค่ diff ที่กำลังจะ commit ไม่กิน CI time เลย
CI stage แรกสุด — เผื่อกรณีมีคน bypass pre-commit hook มา (เกิดขึ้นจริง บ่อยกว่าที่คิด)

จุดที่คนมักพลาด: ตั้ง Gitleaks แล้วไม่เคย custom allowlist สำหรับ false positive พวก test fixture ที่มี string หน้าตาเหมือน API key แต่จริงๆ เป็น dummy data — พอ noise เยอะ dev ก็เริ่ม ignore alert ทั้งหมด ซึ่งอันตรายกว่าไม่มี scan อีก

เลเยอร์ที่ 2: Semgrep — จับ pattern ที่ linter ธรรมดาจับไม่ได้

Semgrep ต่างจาก linter ทั่วไปตรงที่เขียน rule แบบ semantic ได้ ไม่ใช่แค่ regex บนข้อความ เช่นจับ pattern "query string ต่อกับ user input ตรงๆ โดยไม่ผ่าน parameterized query" ซึ่งเป็นต้นตอ SQL injection

ข้อดีคือ community rule set ของ Semgrep ครอบคลุมเยอะมากอยู่แล้ว ไม่ต้องเขียนเองทั้งหมด แต่ rule set default บางอันก็ noisy เกินไปสำหรับ codebase เฉพาะทาง ทีมเราเลยแยก rule เป็น 2 ระดับ:

Blocking rule — เจอแล้ว fail pipeline ทันที (injection pattern, hardcoded credential pattern, insecure deserialization)
Warning rule — ขึ้นเป็น comment ใน PR แต่ไม่ block ให้ reviewer ตัดสินใจเอง

แบ่งแบบนี้แล้ว noise ลดไปเยอะ คนไม่เบื่อ alert

เลเยอร์ที่ 3: OWASP Dependency-Check + OSV — เช็ค dependency ที่ดึงมาใช้

อันนี้คือจุดที่ pipeline เราเคยช้าที่สุด เพราะ OWASP Dependency-Check ต้อง sync NVD database ซึ่งบางทีช้าหรือ rate-limit เอา ทางแก้คือ:

Cache NVD database ไว้ใน artifact storage แทนที่จะ download ใหม่ทุกรอบ
รัน OSV-Scanner คู่กันไปด้วย เพราะ query ผ่าน API ตรงๆ ไม่ต้อง sync database เอง เร็วกว่ามาก แต่ coverage อาจไม่ครบเท่า NVD ในบาง ecosystem

พอทำสองข้อนี้ เวลารวมของเลเยอร์นี้ลดจาก ~6 นาที เหลือประมาณ 40 วินาที นี่แหละคือจุดที่กู้เวลากลับมาได้เยอะสุดในทั้ง pipeline

เลเยอร์ที่ 4: Trivy — สแกน container image ก่อน push ขึ้น registry

เลเยอร์สุดท้ายอยู่หลัง build image เสร็จ สแกนทั้ง OS package และ language-specific dependency ที่ฝังอยู่ใน image เกณฑ์ที่ทีมเราใช้คือ:

CRITICAL/HIGH ที่มี fix แล้ว → block ทันที ห้าม push
CRITICAL/HIGH ที่ยังไม่มี fix → ให้ผ่านได้แต่ต้องมี ticket track ไว้ ห้ามเงียบหาย
MEDIUM ลงไป → ไม่ block แต่รวมอยู่ใน weekly report

จุดสำคัญคือต้อง set exit-code ให้แยกตาม severity ไม่ใช่ fail ทุกอย่างเป็นก้อนเดียว ไม่งั้น dev จะเจอ pipeline แดงจาก MEDIUM vulnerability ที่ยังไม่มี fix ด้วยซ้ำ แล้วก็เริ่มเบื่อ ignore ทั้งกระดาน

ตัวอย่าง Jenkinsfile แบบย่อ

pipeline {
  agent any
  stages {
    stage('Secret scan') {
      steps { sh 'gitleaks detect --source . --exit-code 1' }
    }
    stage('SAST') {
      steps { sh 'semgrep --config=p/security-audit --error' }
    }
    stage('SCA') {
      parallel {
        stage('OWASP DC') {
          steps { sh 'dependency-check.sh --project myapp --scan . --nvdApiKey $NVD_KEY' }
        }
        stage('OSV') {
          steps { sh 'osv-scanner -r .' }
        }
      }
    }
    stage('Build image') {
      steps { sh 'docker build -t myapp:$BUILD_NUMBER .' }
    }
    stage('Image scan') {
      steps { sh 'trivy image --severity CRITICAL,HIGH --exit-code 1 myapp:$BUILD_NUMBER' }
    }
  }
}

จุดที่ทำให้เร็วขึ้นเยอะคือเอา SCA (OWASP DC กับ OSV) มารันแบบ parallel กัน แทนที่จะรันเรียงต่อกัน เพราะสองตัวนี้ไม่มี dependency ต่อกันเลย

บทเรียนที่แพงที่สุดจากเรื่องนี้

ตอนที่ pipeline ช้า 18 นาทีนั่น ปัญหาจริงๆ ไม่ได้อยู่ที่ tool scan ช้า แต่อยู่ที่เรารันทุกอย่างแบบ sequential ทั้งที่ Gitleaks กับ Semgrep ไม่เกี่ยวกันเลย รันคู่กันได้สบายๆ พอจัดใหม่เป็น parallel ตาม dependency จริง เวลารวมลดลงมากกว่าครึ่งโดยไม่ต้องปิด scan ตัวไหนทิ้งสักตัว

Checklist สรุปเลเยอร์ทั้งหมด

ลำดับที่ทีมเราใช้จริงตอนนี้ (บาง stage รันขนานกันได้ตามที่บอกไปข้างบน):

ถ้าใครกำลังเริ่มวาง pipeline ใหม่ ลองเริ่มจาก Gitleaks กับ Trivy ก่อนสองตัวนี้ effort ต่ำ ผลตอบแทนไว แล้วค่อยๆ เพิ่ม Semgrep กับ SCA ทีหลังได้ ไม่ต้องรีบทำครบ 4 ชั้นตั้งแต่วันแรก