1. Image vulnerabilities — ตู้ที่บรรจุของพร้อมโรค#

เหตุเกิดจาก base image หรือ dependency ที่ติดมีช่องโหว่ — เหมือนตู้คอนเทนเนอร์ที่ซื้อมาแล้วข้างในมีของพร้อมจุดอ่อน

เคสที่คลาสสิคที่สุด — Log4Shell ในปี 2021. Log4j เป็น logging library ของ Java ที่อยู่ในแอปนับล้าน. เดือนธันวาคม 2021 — มีคนค้นพบช่องโหว่ระดับ CVSS 10.0 (สูงสุดของ scale) — โจรส่ง string พิเศษไปใน log → log4j ไป fetch โค้ดอันตรายมารัน → โจรครองเครื่องเสร็จ

ในโลก container ผลกระทบ ยิ่งร้ายแรง เพราะ:

• ทุก image ที่ใช้ Java + Log4j โดน — ไม่ว่าจะรู้หรือไม่
• image แบบ multi-stage ที่ฝัง Log4j ใน build stage — บางครั้งหลุดมา production
• บริษัทต้องไล่ scan + rebuild + redeploy ทุก image ทั่วทั้ง fleet — นับพันนับหมื่นตู้
• บาง image ที่ pull จาก Docker Hub โดยไม่ rebuild — ติดต่อมานานหลายเดือนหลัง patch ออก

ใน scenario ของบริษัทไทยที่ใช้ container — Log4Shell เป็น stress test แรกของวงการ. บริษัทที่ทำ image inventory ดี + ใช้ image scanner — patch จบใน 1-2 สัปดาห์. บริษัทที่ไม่มี inventory — บางที่ใช้เวลา 6 เดือนกว่าจะมั่นใจว่า patch หมดทุกที่. นี่คือเหตุผลที่ Software Bill of Materials (SBOM) กลายเป็น keyword สำคัญในปี 2022-2026 (EP.34 ลึกต่อ)

2. Privileged containers — ตู้ที่เปิดได้ทั้ง warehouse#

ปกติ container ควรรันด้วย สิทธิ์จำกัด — เห็นแค่ของในตู้ตัวเอง. แต่บางครั้ง developer ใส่ flag --privileged หรือ runAsUser: 0 (root) เพื่อให้ container ทำสิ่งที่ “ทำง่ายกว่า” — แล้วลืมถอดออกตอน production

Privileged container = ตู้คอนเทนเนอร์ที่มี กุญแจ master ของทั้ง warehouse. ถ้าโจรเข้ามาในตู้นี้ได้ — โจรเปิดได้ทุกตู้ + เปิด warehouse ออกไปข้างนอกได้ด้วย

ในข่าว pattern คลาสสิคที่เห็นบ่อย — บริษัทเริ่มต้น POC (proof of concept) ที่ dev ตั้ง container เป็น privileged: true เพื่อให้ทดสอบเร็ว → POC ผ่าน → ย้ายไป production — ลืมแก้ flag → 6 เดือนต่อมาโจรเจอ — เข้าผ่าน application bug ธรรมดา — แต่ escape ขึ้นเป็น root ของ host ได้เพราะ privileged

3. Container escape — เปิดจากในตู้ไปครอง warehouse#

Container escape = โจรอยู่ใน container ตัวหนึ่ง — แล้ว กระโดดออกจากตู้ ไปคุม host (ตึก / server) ทั้งหลัง. เป็น scenario ที่ rare แต่ devastating — เพราะถ้าโจรครอง host ได้ → คุมทุก container บนนั้น → ขยายต่อไปทั้ง cluster

วิธีที่เกิด escape ในข่าว:

• kernel vulnerability เช่น Dirty Pipe (CVE-2022-0847) — โจรในตู้แก้ไฟล์บน host kernel ได้
• container runtime vulnerability เช่น runC CVE-2019-5736 — โจรเขียนทับ binary ของ runC จากใน container
• mount ของ host เข้า container ผิดวิธี เช่น mount /var/run/docker.sock เข้า container ทั่วไป → container นั้นสั่ง Docker daemon ของ host ได้ → ครอง host
• privileged + capability ที่ใส่เกิน

container escape ไม่ค่อยเกิด — แต่ทุกครั้งที่เกิด → ข่าวใหญ่. เพราะมันบ่อนทำลายข้อสันนิษฐานหลักของ container ทั้งหมด

4. Secret leakage in Dockerfile — เปิด Dockerfile แล้วเจอรหัสผ่าน#

อันนี้เกิดบ่อยที่สุดในชีวิตจริง — และน่าเศร้าที่สุด. developer ใส่ secret ตรงๆ ใน Dockerfile หรือ commit Dockerfile ที่มี secret ขึ้น GitHub public — แล้วทั่วโลกเห็นใน 5 นาที

ตัวอย่างปัญหาที่เห็นได้ทั่วไป:

1
FROM node:18
2
COPY . /app
3
ENV DATABASE_PASSWORD=SuperSecret123
4
ENV AWS_SECRET_ACCESS_KEY=AKIA...

หรือแย่กว่านั้น — ใส่ secret ใน layer ที่ลบไปแล้วแต่ยังอยู่ใน image history:

1
COPY secret.json /tmp/secret.json
2
RUN ./install-with-secret /tmp/secret.json
3
RUN rm /tmp/secret.json   # ลบแล้ว แต่ยังอยู่ใน layer ก่อนหน้า!

ใน image — ทุก layer ถูกเก็บไว้แม้ลบไฟล์ใน layer ถัดไป. ใครก็ตามที่ pull image ของคุณ — docker history ได้ทุก layer — เห็น secret ที่คิดว่าลบแล้ว

มีข่าว popular ในวงการ — บริษัทใหญ่ลืม commit Dockerfile ขึ้น public repo — มี AWS key ข้างใน — โจร bot scan GitHub ตลอด 24 ชม. — ภายในชั่วโมงเดียวเริ่ม spin EC2 instances สำหรับ crypto mining — บิลของบริษัทเดือนนั้น 6 หลัก USD

มุมผู้บริหาร: 4 ข้อนี้ — ถ้าคุณจำได้ขั้นเดียวคือจำว่า ความเสี่ยงของ container ไม่ใช่ “container ปลอดภัยหรือไม่ปลอดภัย” — แต่คือ “ทีมเราเข้าใจ container ดีพอไหม”. มันเหมือนรถยนต์ — รถปลอดภัยหรือไม่ปลอดภัย ขึ้นกับคนขับ. คำถามที่ถามทีมได้ — “เรา scan image ก่อน deploy ไหม?” / “มี privileged container เหลือใน production ไหม — รายชื่อ?” / “Secret เก็บใน Dockerfile หรือใน secret manager?” / “ใครได้ดูว่า image ของบริษัทเรามี vulnerability ตัวไหน — มี dashboard ไหม?”. ถ้าได้คำตอบที่ชัดเจน 4 ข้อ — ทีมคุณ mature พอ. ถ้ายังงงๆ — ลงทุนใน image scanning + secret management ก่อนทำอย่างอื่น

Pod — กลุ่มตู้ที่ทำงานเป็นทีม#

Pod = กลุ่มตู้คอนเทนเนอร์ 1-N ตู้ ที่ K8s ปฏิบัติเป็น หน่วยเดียว — รันด้วยกัน + แชร์ network + แชร์ storage. Pod เป็น หน่วยเล็กที่สุด ที่ K8s จัดการ — ไม่ใช่ container เดี่ยวๆ

ส่วนใหญ่ Pod = container 1 ตัว. แต่บางกรณีต้องมี container เสริม (เรียก sidecar) เช่น container หลักรัน app + sidecar ทำหน้าที่ logging / proxy / mesh

Deployment — แม่แบบบอกว่าต้องการกี่ Pod#

Deployment = คำสั่งกับ K8s ว่า “ผมต้องการ Pod แบบนี้ (ใช้ image นี้) จำนวน 5 ตัว — ตลอดเวลา”. ถ้า Pod พังไป 1 ตัว — K8s สร้างใหม่ทันที เพื่อให้ครบ 5. ถ้าเวอร์ชันใหม่ของ image ออกมา — Deployment สั่งให้ K8s ทยอย rolling update ทีละ Pod โดยไม่ดาวน์

นี่คือ super power ของ K8s — self-healing + declarative. คุณบอกว่า “ต้องการอะไร” (5 ตู้ที่บรรจุแบบนี้) — ไม่ใช่ “ทำขั้นตอนอะไร”. K8s จัดการให้เอง

Service — ที่อยู่ของกลุ่ม Pod#

Pod แต่ละตัว IP ของมันเปลี่ยนได้ตลอด (Pod ตาย-เกิดใหม่ตลอดเวลา). ถ้าคุณบอกผู้ใช้ว่า “เข้า http://192.168.x.x” — มันใช้ไม่ได้

Service = ที่อยู่คงที่ ของกลุ่ม Pod. K8s ให้ IP + DNS name คงที่ — Service เป็น load balancer ภายใน ที่ส่งคำขอไปยัง Pod ที่พร้อมรับ

Ingress — ประตูจาก internet เข้ามายัง Service#

Ingress = ประตูหน้า warehouse ที่ผู้ใช้จากภายนอก (internet) วิ่งเข้ามา. ทำหน้าที่ routing — “URL /api/orders ไป Service A, URL /api/users ไป Service B” — และมัก terminate TLS ที่นี่ด้วย

ConfigMap + Secret — กล่องเก็บค่า config + รหัสลับ#

ConfigMap = กล่องเก็บค่า config ที่ Pod ดึงไปใช้ได้ (เช่น URL, feature flag, parameter). Secret = กล่องเก็บข้อมูลละเอียดอ่อน (password, API key, TLS cert) — ที่ K8s เก็บแยก + ควร encrypt at rest

จุดที่ต้องระวัง — K8s Secret ไม่ใช่ encrypted by default ใน etcd (database ของ K8s). ค่ามันเก็บเป็น base64 encoded ซึ่ง = ไม่ใช่ encryption. ต้องเปิด encryption at rest เอง หรือใช้ external secret manager (AWS Secrets Manager / HashiCorp Vault / Sealed Secrets)

RBAC + NetworkPolicy — กฎเข้าออก + กฎคุยกัน#

RBAC (Role-Based Access Control) ของ K8s = กฎว่าใครทำอะไรใน cluster ได้. คล้ายกับ Authorization ใน EP.16 — แต่ scope ของ K8s. กำหนดว่า user A เข้า namespace ไหน / สั่งอะไรได้ / ดูอะไรได้

NetworkPolicy = กฎว่า Pod ไหนคุยกับ Pod ไหนได้. by default — Pod ทุกตัวใน cluster คุยกันได้หมด (flat network). NetworkPolicy ทำให้คุณจำกัด — “Pod ของ frontend คุยกับ Pod ของ backend ได้ แต่ห้ามคุยกับ database โดยตรง”

นี่คือ microsegmentation ใน K8s (เชื่อมกับ EP.28). บริษัทที่ไม่ตั้ง NetworkPolicy = warehouse ที่ตู้ทุกตู้คุยกันได้หมด — เป็น playground สำหรับ lateral movement ของโจร

มุมผู้บริหาร: K8s ไม่ได้ secure by default ครับ. มันคือ engine ทรงพลัง ที่ถ้าตั้งดีคือเกราะป้องกัน — ถ้าตั้งไม่ดีคือประตูเปิดให้โจรเดินเข้า. default ของ K8s = ปลอดภัยน้อย เพื่อให้ใช้งานง่าย. คำถามที่ถามทีมได้ — “ทุก namespace มี NetworkPolicy ไหม?” / “Secret ใน etcd encrypt at rest ไหม?” / “ใครมี cluster-admin — รายชื่อ?” / “RBAC ตามหลัก least privilege ไหม หรือทุกคน admin?”. ถ้าตอบว่า “ทุกคน admin เพราะมันใช้ง่าย” — สีแดงครับ. K8s ที่ตั้งค่าผิดเป็นช่องโหว่ใหญ่ที่สุดที่บริษัทไทยเริ่มเจอ — เพราะ team dev โหลด K8s มาใช้เร็วกว่า team security เรียนทันท่วงที

ชั้น 1 — Image Scanning (ตรวจตู้ก่อนเข้า warehouse)#

ก่อน image จะถูก deploy เป็น Pod — ต้อง scan หาช่องโหว่ ก่อน. เครื่องมือยอดนิยม:

• Trivy (Aqua Security, open-source) — เร็ว + ใช้ง่าย + popular ที่สุดในวงการปัจจุบัน
• Snyk (commercial) — ครอบคลุม + UI ดี + integrate IDE
• Anchore — focus ที่ enterprise + policy engine แข็ง

Scanner ดู image ทุก layer — เทียบกับ CVE database — รายงานว่ามี vulnerability ตัวไหน level อะไร + แนะนำ version ที่ patch แล้ว. บริษัทที่ทำดี — scan ทุก image ใน CI pipeline + block image ที่มี critical CVE ออกจาก production

ชั้น 2 — Runtime Protection (ยามที่เดินตรวจ warehouse ตลอดเวลา)#

ตู้ที่ผ่านการตรวจตอน scan — ไม่ได้แปลว่ายังปลอดภัยอยู่ตลอด. Runtime protection = ยามที่ดู พฤติกรรมของ container ขณะรัน — จับ anomaly

• Falco (CNCF, open-source) — มาตรฐานของวงการ. ตรวจ system call ของ container — เห็น process ที่แปลกประหลาด เช่น container web server จู่ๆ รัน nc หรือ bash interactive
• Sysdig Secure (commercial) — Falco + dashboard + policy + cloud integration
• Aqua Runtime + Wiz Runtime — alternatives ในวงการ enterprise

ภาพในใจ — image scan คือ ตรวจตู้ตอนเข้าประตู warehouse / runtime protection คือ กล้องวงจรปิด + ยามเดินตรวจ ขณะตู้อยู่ในนั้น. ทั้งคู่ต้องมี — ขาดอันใดอันหนึ่งคือเสียมือไปข้างหนึ่ง

ชั้น 3 — Pod Security Standards (กฎความปลอดภัยของตู้)#

สมัยก่อน K8s มี Pod Security Policy (PSP) — แต่ deprecated ตั้งแต่ K8s 1.21 และถูกถอดใน 1.25. แทนที่ด้วย Pod Security Standards (PSS) — มาตรฐาน 3 ระดับ:

• Privileged — อะไรก็ได้ (สำหรับ system workload เท่านั้น)
• Baseline — กันสิ่งที่อันตรายเห็นชัด (เช่น privileged container, hostPath mount)
• Restricted — เข้มที่สุด (drop ทุก capability, รันด้วย non-root, read-only root filesystem)

บริษัทที่ทำดี — บังคับ Restricted ใน namespace ที่รัน workload ของลูกค้า. enforcement ทำผ่าน Pod Security Admission ของ K8s — block Pod ที่ไม่ตามมาตรฐาน

ชั้น 4 — Service Mesh + mTLS (ทุกการคุยกันมีลายเซ็น)#

ในเมืองของเรา — warehouse ใหญ่ที่ตู้ A คุยกับตู้ B ต้องผ่าน โทรศัพท์ภายในของ warehouse. ใครก็โทรหากันได้ — แต่ไม่รู้ว่าใครพูด

Service Mesh = ชั้นเสริมที่บังคับให้ทุกการสื่อสารระหว่าง Pod มี identity + เข้ารหัส + record. Istio + Linkerd เป็น 2 ตัวที่ popular ที่สุด

จุดเด่น — mTLS (mutual TLS) ใน mesh — ไม่ใช่แค่ Pod A เห็น Pod B (ฝั่งเดียวเหมือน HTTPS เว็บ) แต่ ทั้งคู่ยืนยันตัวกันด้วย certificate. ของในตู้ + ใครส่ง + ใครรับ — เซ็นชื่อทั้งสองฝั่ง

ผลพลอยได้ — observability ดีขึ้น + กำหนด policy ละเอียดได้ (allow X→Y, deny X→Z) + traffic shifting สำหรับ canary deployment. แลกกับ complexity ของ mesh ที่ต้องเรียนรู้ + overhead ทาง resource

ชั้น 5 — Admission Controllers (ยามที่อ่าน manifest ก่อนรับเข้า)#

ทุกครั้งที่มีคนสั่ง deploy อะไรขึ้น K8s — manifest (ไฟล์ YAML บอกว่าจะสร้างอะไร) วิ่งผ่าน Admission Controller ก่อนถึง cluster. คุณตั้ง policy ได้ — “ห้าม Pod ที่ใช้ image จาก registry ที่ไม่ใช่ของเรา” / “ห้าม privileged: true” / “ทุก Pod ต้องมี resource limit” / “ทุก Service ต้องมี NetworkPolicy คู่กัน”

เครื่องมือ:

• OPA Gatekeeper (Open Policy Agent) — ใช้ภาษา Rego เขียน policy
• Kyverno — ใช้ YAML เขียน policy (เรียนรู้ง่ายกว่า OPA สำหรับ team ที่ไม่ใช่ programmer)

Admission Controller คือ policy as code ที่บังคับใช้กับทุก deployment — ไม่ต้องพึ่ง human review

มุมผู้บริหาร: ครับ — 5 ชั้นนี้ — ไม่ต้องทำพร้อมกันหมด. ลำดับที่แนะนำในข่าวและคำแนะนำของวงการ = ชั้น 1 (Image scan) → ชั้น 3 (Pod Security Standards) → ชั้น 5 (Admission Controller) → ชั้น 2 (Runtime) → ชั้น 4 (Mesh). เพราะ Image scan + PSS + Admission Controller เริ่มลงทุนต่ำ + ผลกระทบสูง. Runtime + Mesh ต้องมี security ops พร้อม + ต้องมี culture ที่จัดการ alert ได้. คำถามที่ผู้บริหารถามทีม K8s ได้ — “เราอยู่ชั้นไหน?” + “ต่อไปจะเพิ่มชั้นไหน เหตุผลอะไร?” — คำตอบที่ดี = ทีมรู้ตัวว่าอยู่ตรงไหนของ maturity curve + มีแผนชัด. คำตอบ “เราใช้ K8s — ก็ปลอดภัยอยู่แล้ว” = ตอบไม่ตรงคำถาม

เคส 1 — Tesla Kubernetes cryptojacking (2018)#

กุมภาพันธ์ 2018 — บริษัท RedLock (ตอนนี้คือ Palo Alto Prisma Cloud) ตรวจพบว่า Tesla มี K8s dashboard เปิดอยู่บน internet โดยไม่มีรหัสผ่าน. โจรเจอ — เข้าผ่าน dashboard — สั่งให้ K8s ของ Tesla รัน Pod สำหรับ crypto mining (ขุด Monero)

ที่แสบกว่านั้น — โจรมีฝีมือ:

• ใช้ pool ของตัวเอง (ไม่ใช่ public pool) — ตรวจจับยากกว่า
• CPU usage จำกัด ไม่ให้สูงเด่นชัด — กล้องไม่ตรวจจับ
• เก็บความถี่ของการสื่อสารต่ำ — กลบ traffic anomaly
• ใช้ SSL + non-standard port — หลบ network monitoring

จุดสำคัญที่ผู้บริหารต้องเรียน — dashboard ของ K8s ที่ไม่ใส่รหัส ≠ น่ารักน่าเอ็นดู มันคือ ประตู warehouse เปิดทิ้งไว้ + ในนั้นมี server ของ Tesla. ใน scenario นี้ — ป้องกันได้ที่ ชั้น 5 (Admission Controller) + RBAC ที่ดีจาก K8s + dashboard ไม่ expose ไปนอก cluster

เคส 2 — Capital One (2019) — มุม K8s ที่ลืมพูด#

EP.32 เราเล่า Capital One ในมุม SSRF + IMDSv1 ของ AWS. แต่มีมุมที่น่าสนใจกว่านั้น — ถ้า Capital One มี proper K8s RBAC + NetworkPolicy — โจรอาจไปต่อไม่ได้ไกลขนาดนั้น

ในเคสนั้น — โจรเจาะผ่าน WAF misconfiguration → ได้สิทธิ์ของ container ของ web app → ใช้สิทธิ์นั้นเรียก AWS metadata service → ได้ AWS credential → ดูดข้อมูลจาก S3 ของ 100M+ customer

ถ้ามี NetworkPolicy ที่ deny outbound ของ container web app ไปยัง metadata endpoint (169.254.169.254) — โจรเจาะเข้าได้ แต่ดึง credential ไม่ได้. ถ้ามี RBAC ดี — service account ของ Pod web app ไม่มีสิทธิ์ดู S3 bucket ใด — แม้ได้ credential ก็ใช้ไม่ได้

นี่คือพลังของ defense in depth (EP.04) ในโลก K8s — เจาะชั้นนอกได้ แต่ติดชั้นใน. Capital One ไม่ได้มีชั้นในที่แน่นพอ. บทเรียนของวงการตั้งแต่นั้น — ทุก K8s production ต้องมี NetworkPolicy บังคับ outbound + RBAC แบบ least privilege

เคส 3 — Log4Shell ใน container (2021)#

ธันวาคม 2021 — Log4Shell ระเบิด — ทุก image ที่มี Log4j โดน. ในโลก container ผลกระทบขยายเร็วเป็นพิเศษเพราะ:

• base image ทางการของ Java เช่น openjdk มีหลายเวอร์ชันที่บัน Log4j
• บริษัทที่ใช้ image ของ third-party (Elastic, Splunk, monitoring tools) — บางตัวฝัง Log4j ภายใน — บริษัทไม่รู้ตัว
• ใน public image บน Docker Hub — มี image นับล้านที่ติด Log4Shell ตั้งแต่วันที่ CVE ออก
• บริษัทไม่มี SBOM — ไม่รู้ว่า image ของตัวเองมีอะไรอยู่ในนั้น — ใช้เวลาเดือนๆ กว่าจะ inventory เสร็จ

บริษัทที่ทำ image scanning + SBOM ดี — patch เสร็จใน 1-2 สัปดาห์. บริษัทที่ไม่มี — บางที่ใช้เวลา 6 เดือน — และในระหว่างนั้น โจรบอตสแกนหา Log4Shell ทั่ว internet 24/7

บทเรียนของ Log4Shell ไม่ใช่แค่ “patch ให้เร็ว” — บทเรียนใหญ่กว่าคือ “คุณต้องรู้ว่า image ของคุณมีอะไรอยู่ในนั้น” — SBOM + image scanning + dependency tracking — เป็น must-have ของวงการตั้งแต่ปี 2022. นี่นำเข้าสู่ EP.34 เลยครับ

มุมผู้บริหาร: 3 เคสนี้ — ถ้าจำได้แค่จุดเดียว — จำว่า โจรในยุค container ไม่ต้องเก่งกว่าทีมคุณมาก — แค่เจอ default config ที่ทีมคุณไม่ได้ไปเปลี่ยน. Tesla = dashboard ไม่ใส่รหัส. Capital One = NetworkPolicy ไม่ตั้ง. Log4Shell = ไม่มี SBOM. ทั้ง 3 เรื่องนี้ — ทำไม่ยาก + ไม่แพง — แค่ต้องรู้ว่าต้องทำ. คำถามที่ผู้บริหารต้องถามทุก quarter — “ตอนนี้ K8s ของเรา default ไหนที่เรายังไม่ได้แก้?” — ถ้าทีมตอบไม่ได้ทันที = ทีมไม่ได้คุมเอกสาร security baseline ของ cluster

สิ่งที่ผู้นำต้องจำ#

ข้อแรก — Container ไม่ใช่ secure by default — มันคือ powerful by default

นี่คือ mindset shift ที่สำคัญที่สุดของ EP นี้ครับ — เวลาทีมบอก “เรา deploy ใน container แล้ว — ปลอดภัยกว่าเดิม” — คุณต้องตั้งคำถามต่อ. container เร็วขึ้น + portable ขึ้น + scalable ขึ้น — แต่ ความปลอดภัยขึ้นกับวินัยของทีม + เครื่องมือที่ใช้ + วิธีตั้งค่า

ลองนึกเปรียบเทียบครับ — รถ Tesla ขับเองได้ ≠ ปลอดภัยอัตโนมัติ. ขึ้นกับคนที่นั่งหลังพวงมาลัย + การตั้งค่า + การบำรุงรักษา. container ก็เหมือนกัน — เป็น tool ที่ทรงพลัง แต่ปลอดภัยหรือไม่ ขึ้นกับวินัยของคนใช้

checklist 6 ข้อสำหรับผู้บริหารถามทีม K8s:

1. เรา pull image จาก registry ของเราเอง หรือจาก Docker Hub ตรงๆ? (คำตอบที่ดี = private registry + mirror จาก public)
2. เรา scan image ก่อน production ไหม — ใช้เครื่องมืออะไร — block ที่ระดับไหน? (Trivy / Snyk / Anchore + block critical CVE)
3. มี privileged container เหลือใน production ไหม — รายชื่อ? (คำตอบที่ดี = ศูนย์ หรือ <5 ตัวที่มี exception ชัดเจน)
4. NetworkPolicy ครบทุก namespace ไหม — ใช้ default deny? (ถ้าไม่มี — เริ่มเลย)
5. RBAC ของ K8s least privilege ไหม — ใครเป็น cluster-admin? (รายชื่อต้องสั้น + audit ได้)
6. Secret เก็บใน K8s Secret (base64) หรือ external secret manager? (Vault / AWS Secrets Manager / Sealed Secrets ดีกว่า raw K8s Secret)

ทำได้ 4-5 ข้อ — บริษัทคุณอยู่ในกลุ่ม mature ของวงการแล้ว. ทำได้ 1-2 ข้อ — ลงทุนใน 3 ข้อแรกก่อน — ROI สูงสุด

ข้อสอง — Default ของ K8s ทุกตัวคือเปิดเพื่อง่าย — security คือสิ่งที่ทีมต้อง opt-in

นี่คือเรื่องที่ผู้บริหารหลายคนยังไม่เห็นภาพ — K8s ออกแบบมาให้ใช้งานง่ายก่อน เพื่อให้ adoption เร็ว. ผลคือ default ของแทบทุก setting เปิดให้ผ่าน + อนุญาตทุกอย่าง — เพื่อให้ “งานเดิน”. Pod คุยกันได้หมด. Service account มีสิทธิ์เยอะ. dashboard เปิดได้ง่าย. Secret ไม่ encrypt at rest. NetworkPolicy ไม่มี.

ทีมที่ไม่รู้เรื่องนี้ — ติดตั้ง K8s — ใช้งานได้ → คิดว่า done. แต่จริงๆ แล้ว default = ปลอดภัยน้อยสุด ในทุกมิติ. ทีมที่ mature — รู้ว่าหลังติดตั้ง K8s — ต้อง harden ทุก default ก่อน production

เคส Tesla (dashboard) + Capital One (RBAC + NetworkPolicy) ทั้งคู่เป็นเคสคลาสสิคของ “default config risk” — ไม่ใช่ช่องโหว่ใน K8s — แต่เป็น default ที่ทีมไม่ได้ไปเปลี่ยน

วัฒนธรรมที่บริษัทคุณควรสร้าง — “K8s production-ready != K8s ทำงานได้”. ก่อนขึ้น production — ต้องมี K8s security baseline checklist ที่ทำตามทุกข้อ. มาตรฐานที่ใช้อ้างได้ในวงการ — CIS Kubernetes Benchmark + NSA/CISA Kubernetes Hardening Guide + OWASP Kubernetes Top 10. ทั้งสามฟรี + อ่านได้ทุก operator. ถ้าทีม K8s ไม่เคยได้ยินอย่างใดอย่างหนึ่ง = สีเหลือง