RBAC hoạt động thế nào cùng với ServiceAccount, và bạn bảo mật một cluster Kubernetes ra sao?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** quản trị *ai được làm gì* trên API. Quyền được cấp cho các **subject** (người dùng, nhóm, **ServiceAccount**) bằng cách **binding** chúng vào các **Role** liệt kê những động từ (verb) được phép trên tài nguyên. RBAC là một lớp trong chiến lược làm cứng (hardening) cluster rộng hơn.

## Mô hình RBAC

```text
SUBJECT (user / nhóm / ServiceAccount)
   │  được bind bởi
   ▼
RoleBinding ───────► Role         (theo namespace: quyền trong MỘT namespace)
ClusterRoleBinding ► ClusterRole  (toàn cluster, hoặc tái dùng qua nhiều namespace)

Role/ClusterRole = một tập RULE: "các VERB này trên các RESOURCE này"
Binding có tính CỘNG DỒN và KHÔNG có deny — bạn chỉ cấp đúng thứ cần thiết.
```

## Ví dụ Role + RoleBinding

```yaml
# Một Role: quyền chỉ đọc Pod trong namespace "app"
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 Role đó vào một 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: danh tính cho Pod

```text
ServiceAccount là DANH TÍNH mà một Pod dùng để nói chuyện với API server.
  → Mọi Pod đều có một cái (SA "default" của namespace nếu không chỉ định).
  → Một token projected được mount vào Pod; RBAC quyết định token đó làm được gì.
Thực hành tốt: cho mỗi workload một SA RIÊNG với RBAC quyền tối thiểu,
và đặt automountServiceAccountToken: false khi Pod không cần truy cập API.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # tắt nếu không cần gọi API
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # chạy Pod dưới danh tính này
```

## Phòng thủ theo chiều sâu — vượt ngoài RBAC

```text
AUTH        → RBAC quyền tối thiểu; ServiceAccount riêng cho từng workload; audit truy cập
NETWORK     → NetworkPolicy mặc-định-từ-chối (Pod không nói chuyện được trừ khi cho phép)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, bỏ bớt capability
              seccomp profile; Pod Security Admission (restricted) để cưỡng chế
SECRETS     → mã hóa khi lưu cho etcd; trình quản lý secret bên ngoài; RBAC chặt trên secret
IMAGES      → quét image, dùng registry tin cậy, cưỡng chế bằng admission (policy engine)
API/etcd    → hạn chế & mã hóa etcd; TLS mọi nơi; giới hạn truy cập anonymous & cluster-admin
CHUỖI CUNG ỨNG→ image ký số, 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          # người dùng hiện tại làm được gì?
```

## Tại sao điều này quan trọng

Bảo mật một cluster là trách nhiệm của senior, và RBAC cùng ServiceAccount là nền tảng của nó, nên hiểu cả hai là kiến thức bảo mật thiết yếu. Mô hình RBAC thanh lịch và đáng nội hóa: quyền có tính **cộng dồn thuần túy, không có deny**, được cấp bằng cách **bind các subject** (người dùng, nhóm, và đặc biệt là **ServiceAccount**) vào các **Role** (theo namespace) hoặc **ClusterRole** (toàn cluster) liệt kê các **verb được phép trên tài nguyên** — nghĩa là bảo mật tốt đến từ việc chỉ cấp đúng thứ mỗi workload cần (**quyền tối thiểu**) thay vì dựa vào các lệnh từ chối. Hiểu rằng **ServiceAccount là danh tính mà một Pod dùng để gọi API** — rằng mọi Pod đều có một token, rằng SA `default` là cái bẫy cấp quyền thừa phổ biến, và rằng bạn nên cho mỗi workload một SA quyền tối thiểu riêng (và tắt automount token khi không cần truy cập API) — là điều rất thực tế và là nguồn cấu hình sai thường gặp trong thực tế. Quan trọng là một kỹ sư senior biết RBAC chỉ là một lớp của **phòng thủ theo chiều sâu**: NetworkPolicy mặc-định-từ-chối, các thiết lập **securityContext** đã làm cứng (non-root, root filesystem chỉ đọc, bỏ bớt capability, seccomp), **Pod Security Admission**, **mã hóa khi lưu** và trình quản lý bên ngoài cho Secret, quét và ký image, các admission controller (OPA/Gatekeeper, Kyverno), cùng truy cập etcd/API bị khóa chặt — tất cả kết hợp để bảo vệ một cluster. Vì một cluster Kubernetes là mục tiêu giá trị cao nơi chỉ một ServiceAccount cấp quyền thừa hoặc một NetworkPolicy mở có thể dẫn đến xâm phạm toàn bộ, thành thạo RBAC và bộ công cụ làm cứng rộng hơn là điều nền tảng để vận hành cluster an toàn ở production.

Mô hình RBAC

Ví dụ Role + RoleBinding

ServiceAccount: danh tính cho Pod

Phòng thủ theo chiều sâu — vượt ngoài RBAC

Tại sao điều này quan trọng

Câu hỏi liên quan