Bài 38: Kubernetes Security: RBAC, Secret và NetworkPolicy

Chốt ý nhanh

Chủ đề	Điểm cần nhớ
RBAC	Giới hạn ai được làm gì trong cluster, là nền bảo vệ nền tảng nhất của Kubernetes.
Secret	Lưu thông tin nhạy cảm theo cách có tổ chức hơn hard-code trong manifest, nhưng không có nghĩa tự động an toàn tuyệt đối.
NetworkPolicy	Giúp kiểm soát pod nào được nói chuyện với pod nào, giảm lan rộng khi một workload bị compromise.

Phần thực hành mở rộng: security trong Kubernetes là kiểm soát quyền và phạm vi ảnh hưởng

Kubernetes security rất dễ bị học theo kiểu liệt kê tính năng. Nhưng góc nhìn vận hành tốt hơn là: nếu một tài khoản, pod hay namespace gặp sự cố, nó lan được tới đâu? RBAC, Secret và NetworkPolicy đều xoay quanh câu hỏi đó.

Lab 1: Quan sát RBAC hiện có trong cluster

kubectl get roles,rolebindings -A
kubectl get clusterroles,clusterrolebindings

Lab này giúp anh thấy cluster thật ngoài đời thường đã có rất nhiều role mặc định, không nên cấp bừa quyền cluster-admin cho mọi thứ.

Lab 2: Kiểm tra quyền của một service account

kubectl auth can-i get pods --as=system:serviceaccount:default:default
kubectl auth can-i list secrets --as=system:serviceaccount:default:default -A

Đây là cách cực thực tế để kiểm tra phạm vi quyền thay vì đoán.

Lab 3: Tạo Secret và mount vào pod

kubectl create secret generic app-secret --from-literal=DB_PASSWORD=example123
kubectl describe secret app-secret
kubectl get secret app-secret -o yaml

Qua đây anh có thể giải thích luôn vì sao Secret base64 không đồng nghĩa với mã hóa thật nếu không có thêm lớp bảo vệ ở etcd và quyền truy cập.

Lab 4: Viết NetworkPolicy tối thiểu

Mô phỏng một policy chỉ cho pod frontend truy cập backend ở cổng cần thiết. Sau đó kiểm tra ứng dụng nào bị chặn ngoài ý muốn. Bài tập này buộc người học nghĩ về traffic thật, không chỉ copy policy.

Lab 5: Rà soát blast radius của một namespace

service account nào đang có quyền quá rộng
secret nào nhiều pod cùng đọc
namespace có policy mặc định deny hay chưa

Tình huống thực tế

Một pod web bị khai thác RCE nhưng service account của nó lại đọc được secret toàn namespace, đồng thời cluster không có NetworkPolicy nên pod đó nói chuyện được khắp nơi. Lúc này sự cố nhỏ có thể thành sự cố toàn cụm chỉ vì quyền cấp quá rộng.

Lỗi phổ biến

Cấp cluster-admin cho tool nội bộ chỉ để “cho chạy nhanh”.
Nhét secret thẳng vào Git hoặc env file công khai.
Tạo NetworkPolicy nhưng không hiểu default behavior của CNI.
Không audit định kỳ service account và binding.

Kết bài

Nếu bài này chắc, anh sẽ nhìn Kubernetes security như bài toán giảm blast radius chứ không phải sưu tầm tính năng. Sang bài GitOps với Argo CD, tư duy quyền và kiểm soát thay đổi sẽ còn quan trọng hơn vì manifest bắt đầu đi qua một pipeline tự động hóa rộng hơn.