# Kyverno คืออะไร? คู่มือ Kubernetes Policy-as-Code & Admission Control สำหรับ SME ไทย 2026
ในยุคที่ SME ไทยเริ่มย้ายระบบจาก VM ขึ้น Kubernetes มากขึ้น ปัญหาที่มักเกิดขึ้นไม่ใช่แค่ "รันได้หรือไม่" แต่คือ "ใครเอา Image ที่ไม่ปลอดภัยมา Deploy", "ทำไมมี Pod วิ่งในฐานะ root", หรือ "Cluster นี้ใครก็ Apply ได้โดยไม่มี Label Owner" คำถามเหล่านี้เกิดจากการที่ Kubernetes เป็นระบบที่เปิดกว้างมาก — ถ้าไม่มีคนคุม "Policy" คลัสเตอร์จะกลายเป็นของกลางที่ใครก็ทำอะไรก็ได้
Kyverno เข้ามาเพื่อแก้ปัญหานี้ โดยเป็น Policy Engine ที่เขียน Policy เป็น YAML (ไม่ต้องเขียน Rego เหมือน OPA Gatekeeper) ทำให้ทีมที่คุ้นเคยกับ Kubernetes อยู่แล้ว เริ่มใช้งานได้ภายในไม่กี่ชั่วโมง บทความนี้จะพาคุณเข้าใจแนวคิด Policy-as-Code, วิธีทำงานของ Admission Controller, และตัวอย่าง Policy ที่ SME ไทยควรติดตั้งทันทีในปี 2026
หลังอ่านจบ คุณจะได้แผนการ rollout Kyverno ใน Cluster ของตัวเอง ทั้ง audit mode, enforce mode และการบูรณาการเข้ากับ CI/CD Pipeline
Kyverno คืออะไร ต่างกับ OPA Gatekeeper ยังไง
Kyverno เป็นโปรเจกต์ open-source ภายใต้ CNCF ที่ทำหน้าที่เป็น Dynamic Admission Controller สำหรับ Kubernetes คือจะยืนดักทุก API Request ที่ส่งมาที่ kube-apiserver เพื่อตรวจสอบว่า Resource นั้นผ่านเงื่อนไขที่กำหนดไว้หรือไม่ ก่อน commit ลง etcd
จุดเด่นคือเขียน Policy เป็น YAML ปกติ ไม่ต้องเรียนภาษา Rego หรือ Go template ทำให้ทีม DevOps เริ่มต้นได้เร็ว และยังทำได้หลายอย่างกว่า validate เฉยๆ:
| เปรียบเทียบ | Kyverno | OPA Gatekeeper |
|-------------|---------|----------------|
| ภาษา Policy | YAML (K8s-native) | Rego |
| Learning curve | ต่ำ | สูง |
| Mutation | รองรับ native | ต้องใช้ external tool |
| Image verification | รองรับ built-in | ต้อง plug-in เพิ่ม |
| Community | CNCF Incubating | CNCF Graduated |
ทำไม SME ไทยถึงควรใช้ Policy-as-Code
หลาย SME คิดว่า Policy-as-Code เป็นของบริษัทใหญ่เท่านั้น แต่ความจริงคือยิ่งทีมเล็ก ยิ่งต้อง automate ไม่งั้น 1 คนต้องคอยไล่ review YAML ทุกตัวที่เพื่อน deploy
วิธีติดตั้ง Kyverno ใน Cluster
ขั้นตอนพื้นฐานสำหรับ SME ไทยที่ใช้ Kubernetes 1.28+ ขึ้นไป:
ตัวอย่าง Policy ที่ควรเริ่มก่อน
```yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-owner-label
spec:
validationFailureAction: Audit
rules:
match:
any:
kinds: ["Deployment", "StatefulSet"]
validate:
message: "ทุก Workload ต้องมี label 'owner'"
pattern:
metadata:
labels:
owner: "?*"
```
นี่คือ Policy ง่ายๆ ที่บังคับให้ Deployment ทุกตัวใส่ owner label ซึ่งช่วยให้ทีม cost allocation และ incident response หาคนรับผิดชอบได้ทันที
Comparison: Kyverno vs OPA Gatekeeper vs Validating Webhook แบบ Custom
| หัวข้อ | Kyverno | OPA Gatekeeper | Custom Webhook |
|--------|---------|----------------|----------------|
| ใช้เวลา rollout | 1-3 วัน | 1-2 สัปดาห์ | 1 เดือนขึ้นไป |
| ค่าบำรุงรักษา | ต่ำ | ปานกลาง | สูงมาก |
| เหมาะกับ | SME, Mid-Market | Enterprise ที่ใช้ Rego อยู่แล้ว | ทีมที่มี requirement พิเศษจริงๆ |
| Mutation | Native | ไม่รองรับ | ได้ แต่ต้องเขียนเอง |
| ค่าใช้จ่าย | Free (Open-source) | Free | Dev cost สูง |
สรุป + ขั้นตอนถัดไป
Kyverno เป็นจุดเริ่มต้นที่ดีสำหรับ SME ไทยที่อยากทำ Policy-as-Code โดยไม่ต้องลงทุนเรียน Rego ใหม่ เริ่มจาก audit mode เพื่อเรียนรู้ รวบรวม violations แล้วค่อยๆ ปิดช่องโหว่ด้วย enforce mode เมื่อทีมพร้อม
Key takeaways:
ต้องการที่ปรึกษาวางระบบ Kubernetes Security และ Policy-as-Code ให้ SME ไทย? ทีม ADS FIT พร้อมช่วยวางแผน rollout Kyverno ให้คลัสเตอร์ของคุณปลอดภัยตามมาตรฐาน CIS Benchmark และ PDPA ติดต่อเราที่ contact@adsfit.co.th หรืออ่านบทความอื่นๆ เกี่ยวกับ Kubernetes Security ในบล็อกของเรา