รู้จัก Open Policy Agent: แยก Authorization Policy ออกจากโค้ดแอป

ภาพรวม

OPA คืออะไร ถ้าพูดแบบคนทำระบบจริง ๆ OPA หรือ Open Policy Agent คือ “เครื่องตัดสินใจเรื่องกฎ” ที่แยกออกมาจากโค้ดหลัก

ปกติเราเขียน if else ไว้ในแอปเยอะมาก ใครเข้า endpoint นี้ได้ ราคาเกินเท่านี้ต้องให้ manager approve ไหม user จากประเทศนี้ใช้ feature นี้ได้หรือเปล่า pod นี้ deploy ได้ไหม

ตอนระบบเล็ก ๆ ยังไม่เป็นไร แต่พอ microservices เยอะขึ้น กฎกระจายเต็ม repo แก้ทีต้อง deploy หลาย service audit ก็ยาก ทีม security อ่านไม่รู้เรื่อง ทีม dev ก็ไม่อยากแตะ logic policy 😅

OPA เข้ามาช่วยตรงนี้ แนวคิดคือ แอปไม่ต้อง “ฝังกฎ” เองทั้งหมด แอปแค่ถาม OPA ว่า “request แบบนี้ อนุญาตไหม” แล้ว OPA ตอบกลับมาเป็น allow / deny หรือ decision อื่น ๆ

ภาษาที่ OPA ใช้เขียน policy ชื่อ Rego หน้าตาจะไม่เหมือน JavaScript หรือ Go ทั่วไป เพราะมันเน้นประกาศกฎมากกว่าเขียนขั้นตอน เช่น allow ถ้า user.role เป็น admin allow ถ้า owner ของ resource ตรงกับ user.id deny ถ้า action เป็น delete และ environment เป็น production

จุดสำคัญคือ input แอปส่งข้อมูลให้ OPA เป็น JSON เช่น user, role, action, resource, time, region จากนั้น OPA เอา input ไปเทียบกับ policy แล้วคืนผลลัพธ์กลับมา

ตัวอย่าง flow ง่าย ๆ API รับ request API สร้าง payload ว่าใครกำลังทำอะไรกับ resource ไหน API เรียก OPA OPA evaluate policy API ทำตาม decision

ประโยชน์ใหญ่คือ policy เปลี่ยนได้โดยไม่ต้องแก้ business code ถ้าบริษัทมีกฎใหม่ว่า intern ห้าม export data เราเพิ่ม policy ที่ OPA ไม่ต้องไล่แก้ทุก endpoint

OPA ไม่ได้ใช้แค่กับ backend API มันดังมากใน Kubernetes ด้วย ผ่านเครื่องมืออย่าง Gatekeeper เช่น ห้าม deploy container ที่ใช้ latest tag ต้องมี resource limit ห้ามเปิด privileged container namespace production ต้องมี label ครบ

พูดง่าย ๆ คือ OPA ทำให้ policy กลายเป็นของที่ test ได้ review ได้ version control ได้ ไม่ใช่ความรู้ลับที่ซ่อนอยู่ใน if else ของ service ใด service หนึ่ง

แต่ก็มีข้อควรระวัง อย่าโยนทุกอย่างเข้า OPA จนงง business logic ที่เป็นแก่นของแอปยังควรอยู่ในแอป OPA เหมาะกับ authorization, compliance, governance, deployment rule, access control ไม่ใช่ที่คำนวณ workflow ซับซ้อนทั้งหมด

อีกเรื่องคือ performance การเรียก OPA ทุก request ต้องออกแบบดี บางระบบใช้ OPA เป็น sidecar ใกล้ service บางระบบ bundle policy มาไว้ local บางระบบ cache decision บางประเภท ขึ้นกับ latency และความเสี่ยงของกฎนั้น

วิธีเริ่มที่ดี เลือก policy ที่ปวดจริงหนึ่งเรื่องก่อน เช่น RBAC ของ API หรือ policy Kubernetes เขียน Rego ให้ชัด ทำ test case สำหรับ allow และ deny แล้วค่อยขยาย

สรุปคือ OPA ไม่ใช่แค่ library อีกตัว แต่มันคือวิธีคิดว่า “กฎของระบบ” ควรถูกแยกออกมาเป็น first-class citizen

โค้ดหลักทำงานของมัน OPA ตัดสิน policy ทีม dev, security, platform คุยกันบนกฎชุดเดียว ระบบจึงเปลี่ยนง่ายขึ้น ตรวจสอบง่ายขึ้น และเสี่ยงน้อยลง 🚦

แนวทางนำไปใช้

• นำแนวคิดจากโพสต์นี้ไปทดลองกับงานจริงของคุณ
• แยกเป็นขั้นตอนเล็ก ๆ แล้วทำทีละส่วน
• บันทึกผลลัพธ์และสิ่งที่เรียนรู้เพื่อต่อยอด

สรุป

ทำความเข้าใจ OPA และภาษา Rego สำหรับรวมกฎสิทธิ์ไว้เป็น policy กลาง ช่วยให้หลาย service ตัดสินใจ authorization สอดคล้องกันและตรวจสอบย้อนหลังได้