Kubernetes Pod Security RBAC ABAC Policy — คู่มือฉบับสมบูรณ์ 2026 | SiamCafe Blog

ในโลกของ Container Orchestration ที่ Kubernetes ครองตำแหน่งราชา ความปลอดภัยกลายเป็นหัวใจสำคัญที่ไม่สามารถมองข้ามได้ โดยเฉพาะอย่างยิ่งในระดับ Pod ซึ่งเป็นหน่วยการทำงานที่เล็กที่สุดและสำคัญที่สุดหน่วยหนึ่ง การจัดการความปลอดภัยที่ซับซ้อนด้วยเครื่องมืออย่าง Pod Security Standards (PSS), RBAC (Role-Based Access Control) และ ABAC (Attribute-Based Access Control) นั้นเป็นทักษะที่ DevOps และ Security Engineer ทุกคนต้องเชี่ยวชาญ คู่มือฉบับสมบูรณ์ปี 2026 นี้จะพาคุณเจาะลึกทุกแง่มุม ตั้งแต่พื้นฐานจนถึงการออกแบบนโยบายขั้นสูง พร้อมตัวอย่างโค้ดและแนวทางปฏิบัติจริงจากสนามรบ

บทนำ: ทำไม Pod Security ถึงสำคัญในยุค 2026

การโจมตีผ่านคอนเทนเนอร์และช่องโหว่ใน Kubernetes cluster เป็นหนึ่งในภัยคุกคามที่เติบโตเร็วที่สุดในวงการไซเบอร์เซคิวริตี้ ข้อมูลจากหน่วยงานวิจัยหลายแห่งชี้ว่า กว่า 90% ขององค์กรที่ใช้คอนเทนเนอร์ประสบปัญหาด้านความปลอดภัยอย่างน้อยหนึ่งครั้งในปีที่ผ่านมา Pod ซึ่งเป็น “กระบวนการ” ที่ทำงานอยู่จริงภายในคลัสเตอร์ มักเป็นเป้าหมายแรกที่ผู้ไม่ประสงค์ดีโจมตี เนื่องจากหากแฮกเกอร์สามารถยกระดับสิทธิ์ (Privilege Escalation) หรือหลบหนีออกจากคอนเทนเนอร์ (Container Escape) ได้สำเร็จ พวกเขาก็จะได้สิทธิ์ในการควบคุมโหนดและคลัสเตอร์โดยสมบูรณ์

ใน Kubernetes รุ่นใหม่ๆ (v1.25 เป็นต้นไป) แนวคิดการรักษาความปลอดภัยได้พัฒนาจาก Pod Security Policies (PSP) ที่ล้าสมัยและซับซ้อน ไปสู่ชุดเครื่องมือที่ทรงพลังและยืดหยุ่นยิ่งขึ้น นั่นคือการผสมผสานระหว่าง Pod Security Standards (PSS/PSA), RBAC และ ABAC การเข้าใจกลไกเหล่านี้อย่างลึกซึ้งและการนำไปประยุกต์ใช้อย่างถูกต้องคือเกราะป้องกันที่สำคัญที่สุดสำหรับคลัสเตอร์ Kubernetes ของคุณในปี 2026 และอนาคต

พื้นฐานที่ต้องรู้: Pod Security Standards (PSS) และ Admission Control

Pod Security Standards (PSS) คือกรอบนโยบายที่กำหนดโดยชุมชน Kubernetes (ผ่าน SIG-Security) เพื่อควบคุมการสร้าง Pod โดยแบ่งระดับความเข้มงวดออกเป็น 3 โปรไฟล์หลัก ซึ่งแทนที่ PSP แบบเดิมอย่างเป็นทางการ

• Privileged: โปรไฟล์ที่ไม่มีข้อจำกัด เปิดใช้งานความสามารถของระบบทั้งหมด มักใช้กับ Pod ของระบบ (system Pods) เช่น CNI, CSI drivers

Baseline: โปรไฟล์มาตรฐานที่ป้องกันการยกระดับสิทธิ์ที่รู้จักกันดี เหมาะสำหรับแอปพลิเคชันทั่วไปที่ไม่ต้องการความสามารถพิเศษของระบบ

Restricted: โปรไฟล์ที่เข้มงวดที่สุด ตามหลักปฏิบัติด้านความปลอดภัยที่ดีที่สุด (best practices) ในปัจจุบัน

กลไกที่บังคับใช้มาตรฐานเหล่านี้เรียกว่า Pod Security Admission (PSA) ซึ่งเป็น admission controller ที่ถูก built-in มาตั้งแต่ Kubernetes v1.22 และเสถียรใน v1.25 PSA จะตรวจสอบ Pod ที่ถูกสร้างหรืออัปเดตทันที โดยประเมินตามโหมดการทำงาน 3 โหมด:

1. enforce: นโยบายจะปฏิเสธ Pod ที่ละเมิดมาตรฐานทันที
2. audit: อนุญาตให้ Pod ทำงานได้ แต่จะบันทึกเหตุการณ์การละเมิดใน audit logs
3. warn: แสดงคำเตือน (warning) แก่ผู้ใช้ แต่ยังอนุญาตให้ Pod ทำงานต่อ

การกำหนด Pod Security Standards ผ่าน Namespace Labels

วิธีการกำหนดนโยบาย PSS ที่ง่ายและเป็นที่นิยมที่สุดคือการติดฉลาก (label) ลงบน Namespace นี่คือตัวอย่างการสร้าง Namespace ที่บังคับใช้โปรไฟล์ “Restricted” ในโหมด enforce และตรวจสอบ (audit) สำหรับโปรไฟล์ “Baseline”

apiVersion: v1
kind: Namespace
metadata:
  name: production-apps
  labels:
    # บังคับใช้โปรไฟล์ Restricted อย่างเข้มงวด
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: v1.29
    # ตรวจสอบและบันทึก log หากละเมิด Baseline
    pod-security.kubernetes.io/audit: baseline
    pod-security.kubernetes.io/audit-version: v1.29
    # แสดงคำเตือนหากละเมิด Baseline
    pod-security.kubernetes.io/warn: baseline
    pod-security.kubernetes.io/warn-version: v1.29

เมื่อพยายามสร้าง Pod ที่รันในโหมด privileged (ซึ่งขัดกับโปรไฟล์ restricted) ใน namespace นี้ คุณจะได้รับ error ทันที:

apiVersion: v1
kind: Pod
metadata:
  name: rejected-pod
  namespace: production-apps
spec:
  containers:
  - name: nginx
    image: nginx
    securityContext:
      privileged: true  # ละเมิดนโยบาย Restricted!

ผลลัพธ์: Error from server (Forbidden): error when creating "pod.yaml": pods "rejected-pod" is forbidden: violates PodSecurity "restricted:latest": privileged (container "nginx" must not set securityContext.privileged=true)

RBAC (Role-Based Access Control): การควบคุมการเข้าถึงแบบละเอียด

ในขณะที่ PSS ควบคุมว่า Pod ควรมีลักษณะอย่างไร RBAC จะควบคุมว่า “ใคร” มีสิทธิ์ทำ “อะไร” ได้บ้างภายในคลัสเตอร์ RBAC เป็นกลไกพื้นฐานสำหรับการจัดการสิทธิ์การเข้าถึงทรัพยากร Kubernetes อย่างละเอียด โดยผูกโยงระหว่างผู้ใช้/บริการ (User/ServiceAccount), บทบาท (Role/ClusterRole) และการอนุญาต (Permissions)

องค์ประกอบหลักของ RBAC

• ServiceAccount (SA): บัญชีประจำตัวสำหรับกระบวนการ (Pod) หรือการทำงานอัตโนมัติภายในคลัสเตอร์

Role / ClusterRole: ชุดของกฎ (rules) ที่กำหนดสิทธิ์ (verbs) ต่อทรัพยากร (resources) ใน namespace (Role) หรือทั้งคลัสเตอร์ (ClusterRole)

RoleBinding / ClusterRoleBinding: การเชื่อมโยง (bind) บทบาทกับผู้ใช้, กลุ่ม หรือ ServiceAccount

ตัวอย่าง: จำกัดสิทธิ์การสร้าง Pod ที่ไม่ปลอดภัย

สมมติว่าเราต้องการป้องกันไม่ให้ Developer ทีมหนึ่งสร้าง Pod ที่มี securityContext ที่อันตรายได้ เราสามารถสร้าง ClusterRole ที่อนุญาตแค่การสร้าง Pod ที่ปลอดภัยเท่านั้น

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: safe-pod-creator
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["create", "get", "list", "watch"]
  # ใช้ ResourceNames ร่วมกับ admission webhook หรือใช้ rule แบบมีเงื่อนไขไม่ได้โดยตรงใน RBAC แบบดั้งเดิม
  # นี่เป็นข้อจำกัดที่นำไปสู่การใช้วงจร ABAC หรือ Dynamic Admission Control ร่วมกัน
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: bind-developers-to-safe-role
subjects:
- kind: Group
  name: "developers"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: safe-pod-creator
  apiGroup: rbac.authorization.k8s.io

อย่างไรก็ตาม RBAC แบบดั้งเดิมมีข้อจำกัดสำคัญ: ไม่สามารถกำหนดเงื่อนไข (condition) ตามแอตทริบิวต์ของคำขอ (request attributes) ได้ เช่น เราไม่สามารถเขียนกฎว่า “อนุญาตให้สร้าง Pod ได้ก็ต่อเมื่อ securityContext.privileged=false” ได้ภายใน RBAC rule โดยตรง นี่คือจุดที่ ABAC และเครื่องมืออื่นๆ เข้ามาเติมเต็ม

ABAC (Attribute-Based Access Control) และการประยุกต์ใช้ร่วมกับ Kubernetes

ABAC เป็นโมเดลการควบคุมการเข้าถึงที่พิจารณาลักษณะ (attributes) หลายด้านในการตัดสินใจอนุญาตหรือปฏิเสธ ลักษณะเหล่านี้อาจมาจากผู้ใช้ (เช่น หน่วยงาน, บทบาท), ทรัพยากร (เช่น ป้ายชื่อ, namespace), และสภาพแวดล้อม (เช่น เวลา, ที่อยู่ IP) Kubernetes มี ABAC mode แบบดั้งเดิมที่ใช้ไฟล์นโยบาย (policy file) แต่มีความซับซ้อนและไม่สะดวกในการจัดการสำหรับคลัสเตอร์ขนาดใหญ่

ในยุค 2026 แนวทางการใช้ ABAC ที่เป็นที่นิยมและทรงพลังคือการผ่าน Dynamic Admission Controllers โดยเฉพาะ Validating Admission Webhooks ร่วมกับเครื่องมือเช่น:

• Open Policy Agent (OPA) / Gatekeeper: มาตรฐาน de facto สำหรับนโยบายใน Kubernetes ที่ใช้ภาษา Rego ในการเขียน policy แบบ declarative

Kyverno: เครื่องมือนโยบายแบบ native สำหรับ Kubernetes ใช้ YAML ในการเขียน policy ทำให้เรียนรู้และใช้งานง่าย

ตัวอย่างนโยบายด้วย Kyverno: ห้าม Pod ที่รันเป็น root

นี่คือตัวอย่างการใช้ Kyverno ซึ่งทำงานบนหลักการของ ABAC และ Admission Webhook เพื่อบังคับใช้นโยบายที่ซับซ้อน

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-non-root-pods
spec:
  validationFailureAction: Enforce
  background: false
  rules:
  - name: check-security-context
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "Running as root is not allowed. Please set runAsNonRoot to true or specify a non-root user in securityContext."
      pattern:
        spec:
          containers:
          - =(securityContext):
              =(runAsNonRoot): true
            =(image): "*"

นโยบายนี้จะสกัดกั้นการสร้าง Pod ใดๆ ที่ container ภายในไม่ได้กำหนด securityContext.runAsNonRoot: true โดยอัตโนมัติ โดยไม่ต้องพึ่งพาการติดป้ายชื่อ namespace หรือการจำกัดสิทธิ์แบบหยาบๆ จาก RBAC

การออกแบบสถาปัตยกรรมความปลอดภัยแบบผสมผสาน (Hybrid Security Architecture)

ในสภาพแวดล้อมการผลิตจริง การใช้เครื่องมือเพียงอย่างเดียวมักไม่เพียงพอ ระบบความปลอดภัยที่แข็งแกร่งในปี 2026 ถูกออกแบบเป็นชั้นๆ (Defense in Depth) โดยผสมผสาน PSS, RBAC, และ ABAC-based policies เข้าด้วยกัน

Use Case จริง: ระบบ Multi-Tenant สำหรับ SaaS Provider

บริษัท SaaS แห่งหนึ่งมีคลัสเตอร์ Kubernetes เดียวให้บริการลูกค้าหลายราย (Multi-Tenant) โดยแยก tenant ผ่าน namespace (ลูกค้า 1 tenant ต่อ 1 namespace) สถาปัตยกรรมความปลอดภัยถูกออกแบบดังนี้:

1. ชั้นที่ 1 (Namespace Isolation & Baseline): ทุก namespace ของลูกค้าต้องติด label pod-security.kubernetes.io/enforce: baseline เพื่อป้องกันความเสี่ยงพื้นฐาน
2. ชั้นที่ 2 (Tenant RBAC): สร้าง ServiceAccount และ RoleBinding เฉพาะใน namespace ของลูกค้าแต่ละราย เพื่อป้องกันการข้ามกันขโมยข้อมูล
3. ชั้นที่ 3 (Advanced ABAC Policies ด้วย Gatekeeper):
   • บังคับให้ Pod ทุกตัวใน namespace “tenant-a” ต้องมี label cost-center: a เพื่อติดตามค่าใช้จ่าย
   • ห้ามใช้ container images จาก registry ที่ไม่ได้รับอนุญาต (นอกจาก Docker Hub และ registry ภายใน)
   • บังคับให้ทุก Pod กำหนด resource requests และ limits เพื่อป้องกันการแย่งทรัพยากร

แนวปฏิบัติที่ดีที่สุด (Best Practices) ปี 2026

จากการเรียนรู้และข้อผิดพลาดในอดีต ต่อไปนี้คือแนวทางที่ควรปฏิบัติสำหรับการรักษาความปลอดภัย Pod ใน Kubernetes

1. เริ่มต้นด้วย Pod Security Standards ในโหมด Warn และ Audit

อย่าข้ามไปบังคับใช้ (enforce) ทันทีในคลัสเตอร์ที่มีอยู่ เริ่มต้นด้วยการติดฉลาก namespace ในโหมด warn และ audit ก่อนเพื่อเก็บข้อมูลและทำความเข้าใจว่า workload ใดบ้างที่ขัดกับนโยบาย จากนั้นค่อยๆ แก้ไข workload และยกระดับเป็น enforce

2. ใช้ Namespace เป็นขอบเขตความปลอดภัยหลัก

ออกแบบและแบ่งแยกแอปพลิเคชัน/ทีม/สภาพแวดล้อมด้วย namespace ให้ชัดเจน การกำหนดนโยบาย PSS และ RBAC ทำได้ง่ายและมีประสิทธิภาพมากที่สุดในระดับ namespace

3. ใช้ ServiceAccount เฉพาะสำหรับแต่ละ Workload

หลีกเลี่ยงการใช้ default ServiceAccount เพราะมีสิทธิ์จำกัด (หรืออาจมีสิทธิ์มากหากถูกปรับแต่ง) สร้าง ServiceAccount เฉพาะสำหรับแต่ละ deployment หรือชุด workload และให้สิทธิ์น้อยที่สุด (Principle of Least Privilege – PoLP) ผ่าน RBAC

4. ผสมผสานเครื่องมือให้เหมาะกับงาน

• ใช้ PSA สำหรับมาตรฐานความปลอดภัยพื้นฐานที่ต้องใช้กับทุก namespace
• ใช้ RBAC สำหรับควบคุมสิทธิ์การเข้าถึงของมนุษย์และบริการ
• ใช้ OPA/Gatekeeper หรือ Kyverno สำหรับนโยบายที่ซับซ้อน เช่น การบังคับใช้ label, ตรวจสอบ image registry, หรือนโยบายตามกฎหมาย (compliance)

5. นโยบายเป็นโค้ด (Policy as Code) และการตรวจสอบอย่างต่อเนื่อง

จัดการไฟล์นโยบาย RBAC, Kyverno ClusterPolicy, หรือ OPA Constraints ด้วย Git (GitOps) ใช้ CI/CD pipeline ในการทดสอบและ deploy นโยบายใหม่ๆ ดำเนินการตรวจสอบ (scan) คลัสเตอร์อย่างต่อเนื่องด้วยเครื่องมือเช่น Kubescape, kubeaudit, หรือ Polaris เพื่อหาช่องโหว่ที่อาจหลงเหลือ

6. เตรียมพร้อมสำหรับสถานการณ์ฉุกเฉิน (Break-Glass)

ออกแบบช่องทางสำหรับสถานการณ์ฉุกเฉินเสมอ เช่น การสร้าง namespace พิเศษที่ใช้โปรไฟล์ “privileged” สำหรับการแก้ไขปัญหาเร่งด่วนโดยทีม SRE ที่มีสิทธิ์สูง ซึ่งถูกควบคุมและตรวจสอบอย่างเคร่งครัดผ่าน audit logs

Summary

การรักษาความปลอดภัยให้กับ Pod ใน Kubernetes ปี 2026 ไม่ใช่การเลือกใช้เครื่องมือใดเครื่องมือหนึ่งระหว่าง PSS, RBAC หรือ ABAC แต่คือศิลปะในการผสมผสานเครื่องมือเหล่านี้เข้าด้วยกันอย่างเหมาะสมตามบริบทขององค์กรและความซับซ้อนของ workload เริ่มจากพื้นฐานที่มั่นคงด้วย Pod Security Standards ในระดับที่เหมาะสม เพิ่มการควบคุมการเข้าถึงอย่างละเอียดด้วย RBAC และขยายขีดความสามารถด้วยนโยบายขั้นสูงแบบ ABAC ผ่าน Dynamic Admission Controllers อย่าง OPA/Gatekeeper หรือ Kyverno จุดสำคัญที่สุดคือการยึดหลัก “สิทธิ์น้อยที่สุด” (Least Privilege) และการป้องกันเป็นชั้นๆ (Defense in Depth) พร้อมทั้งการตรวจสอบและปรับปรุงนโยบายอย่างสม่ำเสมอ เทคโนโลยีจะก้าวหน้าไปเรื่อยๆ แต่หลักการพื้นฐานของความปลอดภัยยังคงเดิม การลงทุนเวลาเพื่อเข้าใจและออกแบบระบบความปลอดภัยที่ดีตั้งแต่วันนี้ จะเป็นเกราะป้องกันที่คุ้มค่าที่สุดสำหรับระบบคลัสเตอร์ Kubernetes ของคุณในโลกไซเบอร์ที่เต็มไปด้วยภัยคุกคามที่พัฒนาอย่างไม่หยุดนิ่ง