ความปลอดภัยของ Container และ Kubernetes เบื้องต้น

ความปลอดภัยของ container และ Kubernetes (kubernetes container security) คือการป้องกันระบบที่แพ็กแอปเป็น container แล้วรันเป็นจำนวนมาก container คือหน่วยที่รวมแอปกับสิ่งที่แอปต้องใช้ไว้ด้วยกัน และรันแยกจากแอปอื่นบนเครื่องเดียวกัน Kubernetes คือซอฟต์แวร์ที่จัดการ container เป็นกลุ่มใหญ่ เช่น สั่งให้รัน ย้ายที่รัน และเพิ่มจำนวนโดยอัตโนมัติ กลุ่มเครื่องทั้งหมดที่ Kubernetes ดูแลเรียกว่า cluster บทความนี้อธิบายความเสี่ยงหลักตาม NIST SP 800-190 และขั้นตอนพื้นฐาน 6 ข้อ

container ต่างจากเครื่องเสมือนอย่างไร

VM (เครื่องเสมือน) แต่ละเครื่องมีระบบปฏิบัติการ (OS) ของตัวเอง และถูกแยกจากกันด้วย hypervisor (ซอฟต์แวร์ที่แบ่งฮาร์ดแวร์ให้เครื่องเสมือนแต่ละเครื่อง) ส่วน container หลายตัวใช้ kernel (แกนกลางของระบบปฏิบัติการ) ตัวเดียวกันร่วมกัน NIST ระบุว่า container แยกจากกันได้ดี แต่เส้นแบ่งไม่ชัดเท่า VM ถ้าตั้งค่าหละหลวม container อาจเข้าถึงกันเอง และเข้าถึงเครื่องโฮสต์ (เครื่องที่รัน container) ได้ง่ายกว่า VM NIST ไม่ได้ให้เลือกอย่างใดอย่างหนึ่ง องค์กรใช้ VM จัดการฮาร์ดแวร์ และใช้ container แพ็กแอปควบคู่กันได้

ความเสี่ยงหลัก 5 ส่วนตาม NIST SP 800-190

NIST แบ่งความเสี่ยงตามส่วนประกอบของระบบ container เป็น 5 ส่วน ดังนี้:

• Image (ไฟล์ต้นแบบที่ใช้สร้าง container): อาจมีช่องโหว่ ตั้งค่าบกพร่อง มีมัลแวร์ หรือฝังรหัสผ่านไว้เป็นข้อความธรรมดา และอาจมาจากแหล่งที่ไม่น่าเชื่อถือ
• Registry (คลังเก็บ image): ใช้ช่องทางเชื่อมต่อที่ไม่ปลอดภัย มี image เก่าค้างอยู่ และจำกัดสิทธิ์เข้าถึงไม่พอ
• Orchestrator (ตัวจัดการ container เช่น Kubernetes): ผู้ดูแลมีสิทธิ์กว้างเกินไป มีคนเข้าถึงโดยไม่ได้รับอนุญาต ข้อมูลที่ส่งระหว่าง container แยกออกจากกันไม่ดีพอ และรันงานที่มีความสำคัญต่างกันปนกัน
• Container: ช่องโหว่ในซอฟต์แวร์ที่ใช้รัน container (เรียกว่า runtime) เครือข่ายที่เข้าถึงได้ไม่จำกัด การตั้งค่า runtime ไม่ปลอดภัย ช่องโหว่ของตัวแอป และ container ที่ไม่มีใครอนุมัติแต่มีคนเปิดขึ้นมา
• Host OS (ระบบปฏิบัติการของเครื่องโฮสต์): พื้นที่ที่ผู้โจมตีลองโจมตีได้ (attack surface) กว้าง ใช้ kernel ร่วมกัน ส่วนประกอบมีช่องโหว่ สิทธิ์ผู้ใช้ไม่เหมาะสม และมีการแก้ไขระบบไฟล์โดยไม่ชอบ

NIST SP 800-190 ฉบับสมบูรณ์เผยแพร่เมื่อเดือนกันยายน 2017 หรือกว่า 9 ปีที่แล้ว ผู้เขียนไม่พบฉบับปรับปรุงใหม่ บทความนี้จึงใช้เป็นกรอบมองความเสี่ยงเท่านั้น วิธีตั้งค่า Kubernetes ในปัจจุบันให้ดูเอกสารทางการของ Kubernetes ในขั้นตอนถัดไป NIST เตือนว่าเครื่องมือตรวจช่องโหว่แบบเดิมมักตรวจช่องโหว่ภายใน container ไม่เจอ ทำให้รู้สึกปลอดภัยทั้งที่ยังไม่ปลอดภัย NIST จึงแนะนำเครื่องมือที่ออกแบบมาสำหรับ container และเชื่อมกับขั้นตอนสร้าง image (ดูบทความ DevSecOps) NIST ยังแนะนำอีกสองข้อ คือเก็บรหัสผ่านและ key (กุญแจดิจิทัลที่ใช้ยืนยันตัวตนหรือเข้ารหัส) ไว้นอก image โดยให้ตัวจัดการ container ส่งให้ตอนรัน และตั้ง image ให้รันด้วยผู้ใช้ที่ไม่มีสิทธิ์สูง

ขั้นตอนพื้นฐาน 6 ข้อ

ลำดับต่อไปนี้เป็นข้อเสนอของบทความนี้เอง เรียบเรียงจากเอกสารที่อ้างอิง ไม่ใช่ลำดับที่เอกสารฉบับใดกำหนด:

• ใช้ image ที่เชื่อถือได้ และสแกนก่อนใช้: ใช้เฉพาะ image จากแหล่งที่ตรวจสอบได้ และสแกนหาช่องโหว่ก่อนนำไปรัน
• กำหนดสิทธิ์ด้วย RBAC: RBAC (role-based access control คือการกำหนดสิทธิ์ตามบทบาท) ให้ผู้ใช้และบัญชีของโปรแกรมได้สิทธิ์เท่าที่จำเป็น
• บังคับใช้ Pod Security Standards: Pod คือหน่วยเล็กที่สุดที่ Kubernetes รัน ประกอบด้วย container หนึ่งตัวหรือมากกว่า มาตรฐานนี้กำหนดว่า Pod ทำอะไรได้บ้าง และบังคับใช้ทีละ namespace (ส่วนที่แบ่ง cluster ออกเป็นกลุ่ม เช่น ตามทีมหรือตามระบบ)
• จำกัดการสื่อสารด้วย NetworkPolicy: NetworkPolicy คือกฎที่กำหนดว่า Pod ติดต่อกับใครได้บ้าง
• ปกป้อง Secrets: Secrets คือออบเจ็กต์ของ Kubernetes ที่เก็บค่าลับ เช่น รหัสผ่านและ key ให้จำกัดว่าใครอ่านได้ และเปิดการเข้ารหัสตอนเก็บ
• เปิด audit log และทบทวนสิทธิ์เป็นระยะ: audit log คือบันทึกว่าใครทำอะไรกับ cluster ส่วนการทบทวนสิทธิ์ช่วยตัดสิทธิ์ที่ไม่ได้ใช้แล้ว

RBAC: ให้สิทธิ์เท่าที่จำเป็น

RBAC กำหนดว่าผู้ใช้และบัญชีของโปรแกรม (service account) ทำอะไรกับ Kubernetes API ได้บ้าง API คือช่องทางที่ใช้สั่งงาน cluster เอกสารแนวปฏิบัติ RBAC ของ Kubernetes แนะนำดังนี้ ใช้ RoleBinding (ผูกสิทธิ์ภายใน namespace เดียว) แทน ClusterRoleBinding (ผูกสิทธิ์ทั้ง cluster) เมื่อทำได้ เลี่ยง wildcard (*) เพราะครอบคลุมทรัพยากรชนิดใหม่ที่จะเกิดขึ้นภายหลังด้วย ใช้ cluster-admin (สิทธิ์สูงสุด) เฉพาะที่จำเป็น และไม่ใส่ผู้ใช้ในกลุ่ม system:masters เพราะกลุ่มนี้ข้ามการตรวจสิทธิ์ทั้งหมด และการลบ binding ก็ไม่ช่วยถอนสิทธิ์นั้น

สิทธิ์ที่ดูธรรมดาบางอย่างให้ผลเท่ากับสิทธิ์สูง สิทธิ์ get, list หรือ watch กับ Secrets ทำให้อ่านค่าลับได้ สิทธิ์สร้าง Pod ใน namespace หนึ่งทำให้เข้าถึง Secrets และ ConfigMap ใน namespace นั้นได้ทางอ้อม เพราะ Pod รันด้วย service account ใดก็ได้ใน namespace นั้น เอกสารจึงแนะนำให้ปิดการเมานต์ token ของ service account อัตโนมัติ (ไม่ให้แนบ token เข้าไปใน Pod เอง) ด้วย automountServiceAccountToken: false ในงานที่ไม่ต้องเรียก API เรื่องบัญชีของโปรแกรมดูบทความ non-human identity และ service account

Pod Security Standards: จำกัดสิ่งที่ Pod ทำได้

Pod Security Standards กำหนดนโยบายสามระดับ เรียงจากหลวมไปเข้ม ดังนี้:

• Privileged: ไม่จำกัดอะไรเลย ใช้กับงานระบบที่เชื่อถือได้เท่านั้น Pod ข้ามการแยกตัวของ container ได้ เช่น ใช้เครือข่ายของเครื่องโฮสต์
• Baseline: จำกัดน้อยที่สุดเท่าที่ยังกันการยกระดับสิทธิ์ (privilege escalation คือการที่โปรเซสได้สิทธิ์สูงกว่าที่ควร) แบบที่รู้จักกันอยู่ได้ ห้ามสิ่งต่าง ๆ เช่น privileged container, hostNetwork, hostPID, hostIPC และ hostPath volume (โฟลเดอร์ของเครื่องโฮสต์ที่ต่อเข้ามาใน Pod)
• Restricted: เข้มที่สุด ตามแนวปฏิบัติปัจจุบันในการทำให้ Pod ปลอดภัย และรวมข้อกำหนดของ Baseline ทั้งหมด

Restricted เพิ่มข้อกำหนดหลายข้อ เช่น ต้องตั้ง runAsNonRoot เป็น true (ไม่รันด้วยผู้ใช้ root ซึ่งมีสิทธิ์สูงสุดในระบบ Linux) ต้องตั้ง allowPrivilegeEscalation เป็น false (ห้ามโปรเซสขอสิทธิ์เพิ่มระหว่างรัน) ต้องถอด capability (สิทธิ์ย่อยที่รวมกันเป็นสิทธิ์ของ root) ออกทั้งหมด และเพิ่มกลับได้เฉพาะ NET_BIND_SERVICE และต้องตั้ง seccomp profile (ตัวกรองว่า container เรียกคำสั่งใดของ kernel ได้บ้าง) เป็น RuntimeDefault หรือ Localhost

Pod Security Admission (ตัวตรวจที่ติดมากับ Kubernetes) ใช้บังคับนโยบายระดับ namespace ผ่าน label (ป้ายกำกับ) มีสามโหมด คือ enforce (ปฏิเสธ Pod ที่ผิดนโยบาย) audit (บันทึกลง audit log แต่ยังอนุญาต) และ warn (เตือนผู้ใช้แต่ยังอนุญาต) เอกสารระบุว่าฟีเจอร์นี้เสถียรตั้งแต่ Kubernetes v1.25 ตัวอย่างในเอกสารตั้ง enforce ที่ระดับ baseline และตั้ง audit กับ warn ที่ระดับ restricted วิธีนี้ทำให้เห็นว่า Pod ใดจะผิดหากเข้มขึ้น โดยยังไม่ปิดกั้นการทำงาน บทความนี้เห็นว่าแนวทางนี้เหมาะกับระบบที่รันอยู่แล้ว และเตือนให้ระวังการยกเว้น (exemption) ที่กว้างเกินไป เพราะคำขอที่เข้าข่ายยกเว้นจะถูกข้ามในทุกโหมด

NetworkPolicy และ Secrets

โดยปกติ Pod ทุกตัวใน cluster ติดต่อกันได้หมด เมื่อ NetworkPolicy เลือก Pod ใด Pod นั้นจะรับหรือส่งข้อมูลได้เฉพาะที่นโยบายอนุญาต เอกสาร Kubernetes แนะนำให้ตั้ง default-deny (ปฏิเสธทั้งหมดเป็นค่าตั้งต้น) ในทุก namespace แล้วเปิดเฉพาะเส้นทางที่จำเป็น ข้อควรระวังคือ NetworkPolicy ทำงานได้ก็ต่อเมื่อระบบเครือข่ายของ cluster (เรียกว่า CNI plugin) รองรับ ถ้าไม่รองรับ นโยบายที่สร้างไว้จะไม่มีผล แนวคิดการแบ่งส่วนเครือข่ายโดยทั่วไปดูบทความการแบ่งส่วนเครือข่าย

Secrets เก็บค่าในรูป base64 ซึ่งเป็นเพียงการแปลงรูปแบบ ไม่ใช่การเข้ารหัส และโดยค่าตั้งต้น Secrets จะถูกเก็บใน etcd (ฐานข้อมูลของ cluster) แบบไม่เข้ารหัส ผู้ดูแลต้องเปิด encryption at rest (การเข้ารหัสข้อมูลที่เก็บอยู่) เอง นอกจากนั้นควรจำกัดสิทธิ์ list และ watch กับ Secrets ไม่นำไฟล์ Secret ที่ถอดรหัสได้เข้า repository (ที่เก็บโค้ด) และพิจารณาใช้ที่เก็บค่าลับภายนอก ซึ่งส่วนเสริมของ Kubernetes ชื่อ Secrets Store CSI Driver (ตัวดึงค่าลับจากที่เก็บภายนอกมาให้ Pod) รองรับ แนวคิดนี้ตรงกับที่ NIST แนะนำว่าไม่ควรฝังค่าลับไว้ใน image

ตรวจเทียบมาตรฐาน CIS และคู่มือของ NSA/CISA

CIS Kubernetes Benchmark (ชุดข้อกำหนดการตั้งค่า Kubernetes ที่ Center for Internet Security จัดทำ) ใช้เป็นรายการตรวจว่า cluster ตั้งค่าตามแนวปฏิบัติหรือไม่ หน้าเว็บของ CIS ระบุว่าดาวน์โหลด PDF ได้ฟรีสำหรับการใช้ที่ไม่ใช่เชิงพาณิชย์ ตอนที่ผู้เขียนเปิดดู (ตุลาคม 2026) หน้านั้นแสดงเวอร์ชัน 2.1.0 สำหรับ Kubernetes ทั่วไป และมีเวอร์ชันแยกสำหรับบริการ Kubernetes ของผู้ให้บริการคลาวด์ คือ EKS (Amazon), AKS (Microsoft Azure) และ GKE (Google) ให้เลือกฉบับที่ตรงกับสิ่งที่ใช้อยู่ ผู้เขียนไม่ได้เปิดอ่านตัวเอกสาร จึงไม่ได้สรุปรายข้อ

คู่มือ Kubernetes Hardening Guide ของ NSA และ CISA ฉบับล่าสุดที่ผู้เขียนพบคือเวอร์ชัน 1.2 ลงวันที่สิงหาคม 2022 (เวอร์ชัน 1.0 ออกเดือนสิงหาคม 2021 และ 1.1 เดือนมีนาคม 2022) เอกสารนี้เก่ากว่า 4 ปีแล้ว ผู้เขียนเปิดไฟล์ PDF โดยตรงไม่ได้ เพราะเซิร์ฟเวอร์ปฏิเสธการดาวน์โหลดอัตโนมัติ จึงสรุปจากผลการค้นหาเท่านั้น ผลการค้นหาระบุว่าคู่มือแนะนำให้สแกน container และ Pod หาช่องโหว่ รัน container ด้วยสิทธิ์น้อยที่สุด แยกเครือข่าย ใช้การยืนยันตัวตนที่เข้ม และตรวจ log ก่อนอ้างอิง ควรอ่านต้นฉบับและตรวจว่ามีเวอร์ชันใหม่กว่าหรือไม่ ส่วนรายละเอียดการตั้งค่า ให้ใช้เอกสารปัจจุบันของ Kubernetes เป็นหลัก

ข้อผิดพลาดที่พบบ่อย

• นำ image จากภายนอกมารันโดยไม่ตรวจ: เช่น หยิบ image ของบุคคลที่สามมาใช้ตอนแก้ปัญหา ซอฟต์แวร์ที่ไม่น่าเชื่อถืออาจมีมัลแวร์หรือช่องโหว่ที่รู้กันแล้ว (ความเห็นของเราเอง)
• ฝังรหัสผ่านหรือ key ไว้ใน image: ใครเข้าถึง image ได้ก็อ่านค่าลับได้
• ให้ cluster-admin หรือสิทธิ์กว้างเพื่อความสะดวก: บัญชีเดียวที่ถูกยึด ก็เปิดทางให้ผู้โจมตีควบคุมได้ทั้ง cluster
• เข้าใจว่า base64 ใน Secrets คือการเข้ารหัส: ใครอ่านไฟล์ได้ก็ถอดค่ากลับมาได้
• สร้าง NetworkPolicy แต่ไม่ตรวจว่าระบบเครือข่ายรองรับ: นโยบายไม่มีผล และไม่มีใครรู้ตัว

ขั้นแรกที่ทำได้ทันที

• ทำรายการ cluster และ namespace: จดเจ้าของและความสำคัญของแต่ละอัน รวมถึงอันที่ใช้ทดสอบ
• เปิดโหมด warn และ audit ของ Pod Security Admission: ตั้งที่ระดับ restricted ใน namespace แล้วดูว่า Pod ใดจะผิด โดยยังไม่ปิดกั้นการทำงาน
• ตรวจสิทธิ์: หาว่าใครมี cluster-admin หรืออยู่ในกลุ่ม system:masters และตรวจ binding ที่ให้สิทธิ์กับ system:unauthenticated ซึ่งหมายถึงใครก็ตามที่เข้าถึง API server ได้
• ลองตั้ง default-deny NetworkPolicy: ทดลองใน namespace ทดสอบก่อน และยืนยันว่า CNI plugin รองรับ
• ตรวจ Secrets: หา Secret ที่เก็บอยู่ใน repository และเปิด encryption at rest
• ดาวน์โหลด CIS Benchmark ฉบับที่ตรงกับ cluster: แล้วตรวจตามรายการ

หากต้องการดูภาพรวมความปลอดภัยขององค์กร ลองใช้แบบประเมินตนเอง และถ้ามีหลาย cluster หลายคลาวด์ ดูว่าแพลตฟอร์มแบบรวมช่วยได้อย่างไรในบทความ CNAPP คืออะไร และต่างจาก CSPM และ CWPP อย่างไร

ขอบเขตและความถูกต้องของข้อมูล

ข้อมูลมาจาก NIST SP 800-190 ฉบับเดือนกันยายน 2017 (ผู้เขียนอ่านไฟล์ PDF ส่วนบทสรุป สารบัญ และหัวข้อที่อ้างถึง) และหน้าเอกสารของ Kubernetes ที่อ่านเมื่อวันที่ 27 ตุลาคม 2026 เอกสารของ Kubernetes เปลี่ยนไปตามเวอร์ชัน ควรตรวจหน้าของเวอร์ชันที่ใช้อยู่ ผู้เขียนไม่ได้อ่านเนื้อหาของ CIS Benchmark และไม่ได้เปิดไฟล์คู่มือ NSA/CISA บทความนี้เป็นความรู้เบื้องต้น ไม่ใช่เช็กลิสต์ครบถ้วน เอกสารของ Kubernetes เองก็ระบุว่าเช็กลิสต์ความปลอดภัยของตนไม่ได้ครบทุกเรื่อง

แหล่งอ้างอิงและข้อมูลเพิ่มเติม

• NIST SP 800-190: Application Container Security Guide: ความเสี่ยง 5 ส่วนและมาตรการรับมือสำหรับระบบ container
• CIS Kubernetes Benchmark: ชุดข้อกำหนดการตั้งค่า Kubernetes และเวอร์ชันสำหรับบริการของผู้ให้บริการคลาวด์
• Kubernetes: Pod Security Standards: นโยบาย Privileged, Baseline และ Restricted พร้อมรายการข้อกำหนด
• Kubernetes: Pod Security Admission: โหมด enforce, audit, warn และ label ของ namespace
• Kubernetes: RBAC good practices: แนวปฏิบัติเรื่องสิทธิ์เท่าที่จำเป็นและความเสี่ยงของการยกระดับสิทธิ์
• Kubernetes: Good practices for Secrets: การเข้ารหัสตอนเก็บ การจำกัดสิทธิ์ และที่เก็บค่าลับภายนอก
• Kubernetes: Network Policies: การแยก Pod ค่าตั้งต้น และข้อกำหนดเรื่องระบบเครือข่าย
• Kubernetes: Security checklist: เช็กลิสต์พื้นฐานด้านสิทธิ์ เครือข่าย และ Pod
• NSA/CISA Kubernetes Hardening Guide v1.2 (PDF): คู่มือ Kubernetes ของ NSA และ CISA ฉบับสิงหาคม 2022 (อาจเปิดผ่านเบราว์เซอร์ได้เท่านั้น)