RBAC ทำงานร่วมกับ ServiceAccount อย่างไร และคุณรักษาความปลอดภัยของ cluster Kubernetes อย่างไร?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** กำกับว่า *ใครทำอะไรได้* บน API สิทธิ์ถูกมอบให้ **subject** (ผู้ใช้, กลุ่ม, **ServiceAccount**) โดยการ **bind** พวกมันเข้ากับ **Role** ที่ระบุรายการ verb ที่อนุญาตบนทรัพยากร RBAC เป็นชั้นหนึ่งของกลยุทธ์การทำให้ cluster แข็งแกร่ง (hardening) ที่กว้างกว่า

## โมเดล RBAC

```text
SUBJECT (user / group / ServiceAccount)
   │  bound by
   ▼
RoleBinding ───────► Role         (namespaced: สิทธิ์ภายใน namespace เดียว)
ClusterRoleBinding ► ClusterRole  (ทั้ง cluster, หรือใช้ซ้ำข้าม namespace)

Role/ClusterRole = ชุดของ RULE: "VERB เหล่านี้บน RESOURCE เหล่านี้"
Binding มีลักษณะบวกเพิ่ม (ADDITIVE) และไม่มี deny — คุณมอบเฉพาะสิ่งที่จำเป็น
```

## ตัวอย่าง Role + RoleBinding

```yaml
# A Role: read-only access to Pods in the "app" namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: app
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
# Bind that Role to a ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: app
  name: read-pods
subjects:
  - kind: ServiceAccount
    name: my-app
    namespace: app
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```

## ServiceAccount: อัตลักษณ์สำหรับ Pod

```text
ServiceAccount คืออัตลักษณ์ (IDENTITY) ที่ Pod ใช้คุยกับ API server
  → ทุก Pod ได้หนึ่งตัว (SA "default" ของ namespace ถ้าไม่ระบุ)
  → token แบบ projected ถูก mount เข้า Pod; RBAC ตัดสินว่า token นั้นทำอะไรได้
แนวปฏิบัติที่ดี: ให้แต่ละ workload มี SA ของตัวเองพร้อม RBAC สิทธิ์น้อยที่สุด
และตั้ง automountServiceAccountToken: false เมื่อ Pod ไม่ต้องเข้าถึง API
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # ปิดถ้าไม่ต้องเรียก API
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # รัน Pod ภายใต้อัตลักษณ์นี้
```

## Defense in depth — เหนือกว่า RBAC

```text
AUTH        → RBAC สิทธิ์น้อยที่สุด; ServiceAccount ต่อ workload; audit การเข้าถึง
NETWORK     → NetworkPolicy แบบ default-deny (Pod คุยกันไม่ได้เว้นแต่อนุญาต)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, drop capability
              seccomp profile; Pod Security Admission (restricted) เพื่อบังคับใช้
SECRETS     → encryption at rest สำหรับ etcd; ตัวจัดการ secret ภายนอก; RBAC ที่รัดกุมบน secret
IMAGES      → scan image, ใช้ registry ที่เชื่อถือได้, บังคับด้วย admission (เช่น policy engine)
API/etcd    → จำกัด & เข้ารหัส etcd; TLS ทุกที่; จำกัดการเข้าถึงแบบ anonymous & cluster-admin
SUPPLY CHAIN→ image ที่ลงลายเซ็น, admission control (OPA/Gatekeeper, Kyverno)
```

```bash
kubectl auth can-i list pods --as=system:serviceaccount:app:my-app -n app
kubectl auth can-i --list -n app          # ผู้ใช้ปัจจุบันทำอะไรได้บ้าง?
```

## ทำไมจึงสำคัญ

การรักษาความปลอดภัยของ cluster เป็นความรับผิดชอบระดับ senior และ RBAC กับ ServiceAccount คือรากฐานของมัน ดังนั้นการเข้าใจทั้งสองจึงเป็นความรู้ด้านความปลอดภัยที่จำเป็น โมเดล RBAC งดงามและควรซึมซับไว้: สิทธิ์มีลักษณะ **บวกเพิ่มล้วน ๆ ไม่มี deny** มอบให้โดยการ **bind subject** (ผู้ใช้, กลุ่ม และโดยเฉพาะ **ServiceAccount**) เข้ากับ **Role** (ตาม namespace) หรือ **ClusterRole** (ทั้ง cluster) ที่ระบุ **verb ที่อนุญาตบนทรัพยากร** — ซึ่งหมายความว่าความปลอดภัยที่ดีมาจากการมอบเฉพาะสิ่งที่แต่ละ workload ต้องการ (**สิทธิ์น้อยที่สุด**) แทนที่จะพึ่งพาการปฏิเสธ การเข้าใจว่า **ServiceAccount คืออัตลักษณ์ที่ Pod ใช้เรียก API** — ว่าทุก Pod ได้ token, ว่า SA `default` เป็นกับดักการให้สิทธิ์เกินที่พบบ่อย และว่าคุณควรให้แต่ละ workload มี SA สิทธิ์น้อยที่สุดของตัวเอง (และปิดการ automount token เมื่อไม่ต้องเข้าถึง API) — เป็นเรื่องเชิงปฏิบัติโดยตรงและเป็นแหล่งของการตั้งค่าผิดในโลกจริงที่พบบ่อย ที่สำคัญ วิศวกร senior รู้ว่า RBAC เป็นเพียงชั้นหนึ่งของ **defense in depth**: **NetworkPolicy** แบบ default-deny, การตั้งค่า **securityContext** ที่แข็งแกร่ง (non-root, root filesystem อ่านอย่างเดียว, drop capability, seccomp), **Pod Security Admission**, **encryption at rest** และตัวจัดการภายนอกสำหรับ Secret, การ scan และลงลายเซ็น image, admission controller (OPA/Gatekeeper, Kyverno) และการเข้าถึง etcd/API ที่ถูกล็อกแน่น — ทั้งหมดรวมกันเพื่อปกป้อง cluster เพราะ cluster ของ Kubernetes เป็นเป้าหมายที่มีมูลค่าสูงซึ่ง ServiceAccount ที่มีสิทธิ์เกินเพียงตัวเดียวหรือ NetworkPolicy ที่เปิดโล่งเพียงอันเดียวสามารถนำไปสู่การถูกยึดครองทั้งหมด การเชี่ยวชาญ RBAC และชุดเครื่องมือ hardening ที่กว้างกว่าจึงเป็นรากฐานของการดำเนินการ cluster อย่างปลอดภัยใน production

โมเดล RBAC

ตัวอย่าง Role + RoleBinding

ServiceAccount: อัตลักษณ์สำหรับ Pod

Defense in depth — เหนือกว่า RBAC

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง