ตั้งค่า RBAC ใน Argo CD กำหนดสิทธิ์ผู้ใช้งานอย่างปลอดภัย

Categories

ตั้งค่า RBAC ใน Argo CD กำหนดสิทธิ์ผู้ใช้งานอย่างปลอดภัย

RBAC คืออะไร เหตุใดจึงสำคัญในการจัดการ Argo CD

Role-Based Access Control (RBAC) เป็นกลไกการควบคุมการเข้าถึงที่กำหนดสิทธิ์ให้แก่ผู้ใช้งานตามบทบาทของพวกเขา ใน Argo CD RBAC ช่วยให้คุณควบคุมว่าใครสามารถดำเนินการอะไรกับ Application ใน Kubernetes Cluster ได้

การจัดการสิทธิ์ที่ดีช่วยลดความเสี่ยงด้านความปลอดภัยและป้องกันการแก้ไขแอปพลิเคชันโดยไม่ได้รับอนุญาต หากคุณใช้ Cloud VPS จาก ผู้ให้บริการโฮสติ้ง ที่มีการตั้งค่า Kubernetes และ Argo CD ควรปฏิบัติตามหลักการ RBAC อย่างเข้มงวด

Argo CD RBAC Model และส่วนประกอบหลัก

Argo CD RBAC ประกอบด้วย 3 องค์ประกอบหลัก:

  • Roles: ชุดสิทธิ์ที่ระบุว่าสามารถทำอะไรได้
  • Users: บัญชีผู้ใช้งาน
  • Policies: กฎที่เชื่อมโยง Role กับ User

Argo CD มี Built-in Roles เช่น Admin, ReadOnly และ Exec ที่ใช้งานได้ทันที

argocd-rbac-cm ConfigMap ที่ควรรู้จัก

การตั้งค่า RBAC ใน Argo CD จัดเก็บในไฟล์ ConfigMap ชื่อ argocd-rbac-cm ที่อยู่ใน Namespace argocd

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  policy.default: 'role:readonly'
  policy.csv: |
    p, role:admin, applications, *, */*, allow
    p, role:readonly, applications, get, */*, allow
    g, admin-user, role:admin
    g, dev-user, role:developer

ConfigMap นี้มีส่วนสำคัญ 2 ส่วน คือ policy.default และ policy.csv

รูปแบบ policy.csv – ไวยากรณ์และตัวอย่าง

policy.csv ใช้ Casbin syntax โดยมีรูปแบบดังนี้:

p, role:name, resource, action, object, effect
g, user/group, role

คำอธิบายแต่ละส่วน:

  • p = Policy rule
  • role:name = ชื่อ Role
  • resource = ทรัพยากร (applications, repositories, clusters)
  • action = การกระทำ (get, create, update, delete, sync)
  • object = ลักษณะทรัพยากร (namespace/name หรือ *)
  • effect = allow หรือ deny
  • g = Group mapping ระหว่าง User กับ Role

Built-in Roles: Admin, ReadOnly และ Exec

Argo CD มี 3 Built-in Roles สำหรับใช้งานทั่วไป:

p, role:admin, *, *, *, allow
p, role:readonly, applications, get, *, allow
p, role:readonly, applications, sync, *, deny
p, role:exec, applications, exec, *, allow
  • Admin: สิทธิ์เต็มเพื่อดำเนินการทั้งหมด
  • ReadOnly: ดูข้อมูลเท่านั้น ไม่สามารถแก้ไขหรือ Sync ได้
  • Exec: สามารถ Exec เข้า Pod ได้เท่านั้น

สร้าง Custom Role สำหรับทีม DevOps

สำหรับการจัดการในสภาพแวดล้อมจริง อาจต้องสร้าง Custom Role ให้เหมาะสมกับความต้องการของทีม

p, role:developer, applications, get, */*, allow
p, role:developer, applications, sync, prod-*, deny
p, role:developer, applications, sync, dev-*, allow
p, role:devops, applications, *, *, allow
p, role:devops, repositories, *, *, allow
p, role:devops, clusters, *, *, allow
g, john.dev, role:developer
g, alice.ops, role:devops
g, team-backend, role:developer

ในตัวอย่างนี้ Developer สามารถ Sync Application ใน dev namespace เท่านั้น แต่ไม่สามารถ Sync prod ได้

Project-level RBAC สำหรับการควบคุมที่ละเอียดยิ่งขึ้น

นอกจาก Global RBAC Argo CD ยังสนับสนุน Project-level RBAC ที่ให้ความยืดหยุ่นมากขึ้น

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: development
spec:
  roles:
  - name: developer
    description: "Developer role for dev apps"
    policies:
    - p, proj:development:developer, applications, sync, development/*, allow
  - name: qa
    policies:
    - p, proj:development:qa, applications, get, development/*, allow

วิธีนี้ให้สิทธิ์ที่เจาะจงต่อ Project นั้นๆ โดยไม่ส่งผลต่อ Project อื่น

ตัวอย่างการตั้งค่า RBAC สำหรับทีม Dev และ Ops

นี่คือตัวอย่าง policy.csv ที่สมบูรณ์สำหรับสภาพแวดล้อมจริง:

# Default role
policy.default: 'role:readonly'

# Built-in roles
p, role:admin, *, *, *, allow
p, role:readonly, applications, get, *, allow

# Custom roles
p, role:developer, applications, get, dev-*, allow
p, role:developer, applications, sync, dev-*, allow
p, role:developer, applications, get, shared-*, allow

p, role:ops, applications, *, *, allow
p, role:ops, repositories, *, *, allow
p, role:ops, clusters, *, *, allow
p, role:ops, accounts, *, *, allow

# User group mappings
g, dev-team, role:developer
g, ops-team, role:ops
g, admin-user, role:admin

ทดสอบนโยบาย RBAC ด้วย argocd admin

ใช้คำสั่ง argocd admin เพื่อทดสอบว่านโยบาย RBAC ทำงานถูกต้องหรือไม่:

argocd admin settings rbac can role:developer \
  sync applications dev-app/my-app \
  --policy-file policy.csv

หรือทดสอบสิทธิ์สำหรับ User เฉพาะ:

argocd admin settings rbac can john.dev \
  sync applications prod-app/my-app \
  --policy-file policy.csv

ผลลัพธ์จะแสดง “ALLOWED” หรือ “DENIED” ตามนโยบายที่ตั้งไว้

Best Practices สำหรับ RBAC ใน Argo CD

  • Principle of Least Privilege: ให้สิทธิ์เพียงที่จำเป็น ไม่ให้มากเกินไป
  • ใช้ Group Mapping: จัดกลุ่มผู้ใช้งานตามบทบาท แล้วกำหนด Role ให้กลุ่ม
  • Separate Dev/Staging/Prod: ใช้ Namespace หรือ Project แยกกัน ให้สิทธิ์ต่างกัน
  • Audit และ Monitor: ติดตามการเข้าถึงของผู้ใช้งาน และตรวจสอบบันทึก
  • Regular Review: ตรวจสอบนโยบาย RBAC เป็นระยะเพื่อให้เป็นปัจจุบัน
  • เอกสารชัดเจน: บันทึกไว้ว่า Role ใดมีสิทธิ์อะไรบ้าง

การปรับปรุง ConfigMap RBAC

เมื่อต้องการอัปเดต policy ให้ใช้คำสั่ง kubectl edit:

kubectl edit configmap argocd-rbac-cm -n argocd

หลังจากบันทึก Argo CD จะโหลด policy ใหม่โดยอัตโนมัติ ไม่ต้อง Restart

หากใช้ ผู้ให้บริการโฮสติ้ง Cloud VPS ที่มีการจัดการ Kubernetes อย่างมืออาชีพ ควรใช้ GitOps approach โดยเก็บ ConfigMap ไว้ใน Git Repository แล้วใช้ Argo CD เองเพื่อจัดการการอัปเดต

สรุปและขั้นตอนถัดไป

การตั้งค่า RBAC ใน Argo CD เป็นขั้นตอนสำคัญเพื่อรักษาความปลอดภัยของสภาพแวดล้อม Kubernetes สรุปได้ว่า:

  • ศึกษา RBAC Model และ Casbin Syntax
  • ออกแบบ Role ตามความต้องการของทีม
  • สร้าง policy.csv ใน argocd-rbac-cm
  • ทดสอบนโยบายด้วย argocd admin
  • ติดตามและตรวจสอบเป็นประจำ

สำหรับการปรับใช้บน Cloud VPS ของ ผู้ให้บริการโฮสติ้ง ที่มีทีมจัดการเฉพาะด้าน ขอแนะนำให้ติดต่อสอบถามรายละเอียดเพิ่มเติมเพื่อให้ได้การตั้งค่าที่เหมาะสมที่สุดกับสถาปัตยกรรมของคุณ

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