Hướng dẫn phân quyền trong k8s cho người dùng chi tiết

Phân quyền trong K8s là một nền tảng bảo mật quan trọng, thường được triển khai thông qua cơ chế Role-Based Access Control (RBAC) để kiểm soát quyền truy cập của user, group và service account vào tài nguyên trong cluster. Bài viết này được mình đúc kết từ quá trình triển khai và rà soát phân quyền thực tế trên nhiều hệ thống Kubernetes tại Vietnix, giúp bạn nắm rõ cách định nghĩa rule, tổ chức quyền truy cập và áp dụng đúng cho workload, control plane cũng như các công cụ DevOps như ArgoCD.

Những điểm chính

• Quan điểm của mình: Trong năm 2026, việc thiết kế và vận hành RBAC chặt chẽ theo nguyên tắc “ít quyền nhất có thể” sẽ là nền tảng bắt buộc nếu bạn muốn giữ cụm Kubernetes an toàn và dễ kiểm soát về lâu dài.
• Tổng quan về RBAC: Hiểu rõ RBAC là cơ chế phân quyền dựa trên vai trò, giúp bạn nắm được nền tảng cốt lõi để kiểm soát truy cập và bảo mật trong Kubernetes.
• Cách phân quyền cho các thành phần: Tìm hiểu cách phân quyền cho các thành phần khác nhau như workload, control plane và các công cụ như ArgoCD, giúp bạn áp dụng đúng chính sách bảo mật cho từng trường hợp cụ thể.
• Quản lý quyền trên ArgoCD: Tìm hiểu cách quản lý người dùng và phân quyền trực tiếp trên ArgoCD, giúp bạn bảo mật quy trình GitOps và kiểm soát chặt chẽ các hành động triển khai.
• Giới thiệu Vietnix: Biết đến Vietnix là nhà cung cấp Enterprise Cloud mạnh mẽ, giúp bạn có một nền tảng hạ tầng đáng tin cậy để triển khai các giải pháp Kubernetes của bạn.
• Câu hỏi thường gặp: Giải đáp các thắc mắc liên quan đến phân quyền trong k8s.

Tổng quan RBAC và phân quyền trong Kubernetes

Role-based access control (RBAC) trong Kubernetes là cơ chế điều khiển truy cập dựa trên vai trò gán cho user, group hoặc service account, thay vì gán trực tiếp quyền lẻ cho từng đối tượng. RBAC sử dụng API group rbac.authorization.k8s.io để định nghĩa và áp dụng các chính sách phân quyền thông qua Kubernetes API, giúp quản lý quyền truy cập tài nguyên một cách cấu trúc và có thể khai báo dưới dạng manifest.

Trong một cluster Kubernetes, RBAC quyết định user hoặc service account có được phép thực hiện thao tác cụ thể (ví dụ: get, list, watch, create, update) lên tài nguyên như Pod, Deployment, ConfigMap, Secret, Node hay các non-resource endpoint như /healthz. Cơ chế này đặc biệt quan trọng trong môi trường nhiều người dùng, ví dụ như khi cần cho developer tự xem Pod và log ở namespace dev mà không có quyền truy cập vào môi trường pro.

Định nghĩa rules và ví dụ phân quyền trong RBAC

Trong RBAC Kubernetes, mỗi Role/ClusterRole chứa danh sách rules với các trường chính apiGroups, resources, verbs, tùy chọn resourceNames và nonResourceURLs. apiGroups xác định nhóm API, resources chỉ loại tài nguyên, verbs là tập hành động cho phép, còn resourceNames giới hạn trên một số đối tượng cụ thể. nonResourceURLs được dùng cho các endpoint không phải resource như /healthz hoặc /metrics.

Wildcard * trong apiGroups, resources hoặc verbs cho phép cấp quyền rất rộng nên thường chỉ xuất hiện trong các ClusterRole đặc biệt như cluster-admin. Các kịch bản phân quyền chi tiết cho developer hoặc hệ thống thường khai báo rules cụ thể theo từng tài nguyên, thao tác và namespace để tránh phạm vi quyền quá lớn. Ví dụ Role trong namespace dev chỉ cho phép get, list, watch Pod và xem log, rồi gán cho một ServiceAccount dùng với kubectl.

Ví dụ rule phổ biến gồm rule đọc Pod (apiGroups: [""], resources: ["pods"], verbs: ["get","list","watch"]), rule thao tác Deployment trong group apps, rule quản lý Job/CronJob trong group batch, rule truy cập một ConfigMap duy nhất bằng resourceNames và rule đọc Node trong ClusterRole. Với non-resource rules, RBAC cho phép truy cập các URL như /healthz, /metrics để phục vụ monitoring và kiểm tra tình trạng hệ thống. Trong ArgoCD, rules được khai báo trong policy.csv dưới dạng p, subject, resource, action, object, dùng để kiểm soát các hành động như sync ứng dụng hoặc thao tác lên Deployment theo project/application.

Phân quyền cho workload (user, ServiceAccount, kubectl)

Bước 1: Xác định nhu cầu và namespace phân quyền

Xác định namespace (ví dụ dev) và phạm vi quyền cần cấp, chẳng hạn chỉ cho phép xem Pod và log phục vụ debug. Quyết định dùng ServiceAccount để gắn quyền và dùng token ServiceAccount này làm thông tin đăng nhập cho kubectl.

Bước 2: Tạo ServiceAccount dùng để phân quyền

Bạn tạo ServiceAccount trong namespace mục tiêu, ví dụ dev-reader trong dev. ServiceAccount này sẽ được bind với Role/ClusterRole và token của nó dùng trong kubeconfig.

kubectl create serviceaccount dev-reader -n dev

Bước 3: Tạo Role định nghĩa quyền trên workload

Bạn viết Role chỉ định rõ apiGroups, resources, verbs để giới hạn thao tác trên Pod và log. Ví dụ cho phép get, list, watch với pods và pods/log trong namespace dev.

kubectl apply -f - << 'EOF'
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-logs-reader
  namespace: dev
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
EOF

Bước 4: Tạo RoleBinding gán Role cho ServiceAccount

Bạn tạo RoleBinding trong cùng namespace để gán Role pod-logs-reader cho ServiceAccount dev-reader. RoleBinding xác định subject là ServiceAccount và tham chiếu Role thông qua roleRef.

kubectl apply -f - << 'EOF'
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-logs-reader-binding
  namespace: dev
subjects:
  - kind: ServiceAccount
    name: dev-reader
    namespace: dev
roleRef:
  kind: Role
  name: pod-logs-reader
  apiGroup: rbac.authorization.k8s.io
EOF

Bước 5: Lấy token ServiceAccount và cấu hình kubeconfig

Liệt kê Secret gắn với ServiceAccount dev-reader trong namespace dev, giải mã token từ Secret và cấu hình user, context trong kubeconfig để dùng với kubectl.

#Tạo token cho ServiceAccount (ví dụ set thời hạn 24 giờ) và lưu vào biến TOKEN 
$TOKEN=$(kubectl create token dev-reader -n dev --duration=24h)

#Thêm user vào kubeconfig bằng token vừa tạo
$kubectl config set-credentials dev-reader --token="$TOKEN"

User "dev-reader" set.

##Tạo context mới liên kết user dev-reader với namespace dev
$kubectl config set-context dev-reader-dev --cluster=cloud-docs --namespace=dev --user=dev-reader 

#Chuyển sang sử dụng context vừa tạo kubectl config use-context dev-reader-dev
$kubectl config use-context dev-reader-dev

Switched to context "dev-reader-dev".

#Kiểm tra lại quyền của user (Xác minh RBAC hoạt động)
$kubectl auth can-i get pods
yes

$kubectl auth can-i get pods/log
yes

$kubectl auth can-i delete pods
no

Phân quyền cho control plane và node

Bước 1: Kiểm tra các ClusterRole hệ thống cho control plane

Bạn liệt kê các ClusterRole có prefix system: để xem các role hệ thống dành cho kube-scheduler, controller-manager, kube-proxy. Sau đó xác định ClusterRole nào đang được dùng cho từng thành phần thông qua ClusterRoleBinding.

kubectl get clusterrole | grep 'system:'
kubectl get clusterrolebinding | grep 'system:kube-scheduler'
kubectl get clusterrolebinding | grep 'system:kube-controller-manager'
kubectl get clusterrolebinding | grep 'system:node-proxier'

Bước 2: Kiểm tra quyền node/kubelet với ClusterRole system:node

Xem chi tiết ClusterRole system:node để hiểu phạm vi quyền cấp cho kubelet, đảm bảo kube-apiserver sử dụng Node authorizer và NodeRestriction để ràng buộc quyền kubelet theo node tương ứng.

kubectl get clusterrole system:node -o yaml

Cấu hình kube-apiserver liên quan:

--authorization-mode=Node,RBAC
--enable-admission-plugins=NodeRestriction

Bước 3: Hạn chế chỉnh sửa ClusterRole hệ thống, dùng aggregation nếu cần mở rộng

Tránh sửa trực tiếp ClusterRole hệ thống mà nên tạo ClusterRole mới với nhãn aggregate-to-* để mở rộng role người dùng như admin, edit, view. Sử dụng aggregationRule trong ClusterRole mục tiêu để tự động tổng hợp rules từ các ClusterRole con.

Phân quyền cho ArgoCD tương tác với workload trong cluster

Bước 1: Tạo ServiceAccount và ClusterRole/Role cho ArgoCD

Bạn tạo ServiceAccount trong namespace argocd để ArgoCD dùng khi thao tác với Kubernetes cluster. Sau đó tạo ClusterRole hoặc Role phù hợp (tùy phạm vi) cấp quyền quản lý các tài nguyên cần thiết như deployments, services, jobs.

kubectl create serviceaccount argocd-manager -n argocd

kubectl apply -f - << 'EOF'
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: argocd-manager-role
rules:
  - apiGroups: ["", "apps", "batch"]
    resources: ["pods","services","deployments","statefulsets","jobs","cronjobs"]
    verbs: ["get","list","watch","create","update","patch","delete"]
EOF

Bước 2: Gán ClusterRole cho ServiceAccount ArgoCD

Bạn tạo ClusterRoleBinding để ánh xạ argocd-manager-role với ServiceAccount argocd-manager. ServiceAccount này sau đó được cấu hình làm cluster credential trong ArgoCD.

kubectl apply -f - << 'EOF'
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: argocd-manager-binding
subjects:
  - kind: ServiceAccount
    name: argocd-manager
    namespace: argocd
roleRef:
  kind: ClusterRole
  name: argocd-manager-role
  apiGroup: rbac.authorization.k8s.io
EOF

Bước 3: Cấu hình RBAC nội bộ trong ArgoCD

Trong ConfigMap argocd-cm, định nghĩa account ArgoCD và bật login, apiKey cho user/role tương ứng. Trong ConfigMap argocd-rbac-cm, cấu hình file policy.csv với các rule dạng p, subject, resource, action, object và ánh xạ user vào role bằng dòng g, user, role.

Ví dụ rule ArgoCD:

p, role:dev, applications, sync, dev/*
g, user:alice, role:dev

Tạo user mới trên ArgoCD thông qua ConfigMap argocd-cm

Bước 1: Sao chép cấu hình argocd-cm mặc định

Bạn lấy ConfigMap argocd-cm trong namespace cài ArgoCD (ví dụ argocd) và lưu ra file argocd-cm.yaml. Trong phần data, giữ lại khóa url hiện có để không thay đổi endpoint truy cập ArgoCD.

kubectl -n argocd get configmap argocd-cm -o yaml > argocd-cm.yaml

Bước 2: Khai báo account user mới và capabilities

Trong trường data của argocd-cm.yaml, bạn thêm dòng accounts.<username>: <capabilities> , ví dụ tạo user hanli với quyền login:

data:
  url: https://argocd.example.com
  accounts.hanli: login

Các capabilities hợp lệ gồm login (đăng nhập UI/CLI) và apiKey (tạo token gọi API).

Sau đó bạn cập nhật lại ConfigMap:

kubectl apply -f argocd-cm.yaml

Bước 3: Đặt mật khẩu cho user ArgoCD

Sau khi ConfigMap được áp dụng, ArgoCD tạo account hanli với trạng thái readonly mặc định. Thiết lập mật khẩu cho hanli bằng CLI ArgoCD, sử dụng mật khẩu admin hiện tại cho tham số --current-password.

argocd account update-password \
  --account hanli \
  --current-password <ADMIN_PASSWORD> \
  --new-password hanli \
  --grpc-web

Cấu hình phân quyền ArgoCD qua ConfigMap argocd-rbac-cm

Bước 1: Lấy cấu hình argocd-rbac-cm mặc định

Bạn lấy ConfigMap argocd-rbac-cm và lưu ra file argocd-rbac-cm.yaml.

kubectl -n argocd get configmap argocd-rbac-cm -o yaml > argocd-rbac-cm.yaml

Trong cấu hình mặc định, trường policy.default: role:readonly áp dụng role readonly cho user không có rule cụ thể.

Bước 2: Định nghĩa rule trong policy.csv

Trong argocd-rbac-cm.yaml, thêm khóa policy.csv trong data và viết các dòng policy theo định dạng:

p, <subject>, <resource>, <action>, <object>, <effect>

Ví dụ cấp quyền cho user hanli được thực hiện action restart Deployment trên tất cả ứng dụng thuộc project default:

data:
  policy.default: role:readonly
  policy.csv: |
    p, hanli, applications, action/apps/Deployment/restart, default/*, allow

Trong đó: resource là applications, action dùng format action/<group>/<Kind>/<tên-action>, object default/* nghĩa là mọi application trong project default. Bạn áp dụng lại ConfigMap:

kubectl apply -f argocd-rbac-cm.yaml

Bước 3: Tạo role chung và gán cho nhiều user (tùy chọn)

Để tránh lặp lại rule cho nhiều user, bạn có thể tạo role logic rồi gán nhiều user vào role thông qua dòng g,.

data:
  policy.default: role:readonly
  policy.csv: |
    p, role:deployment-restart, applications, action/apps/Deployment/restart, default/*, allow
    g, hanli, role:deployment-restart
    g, natsu, role:deployment-restart
    g, lucy, role:deployment-restart

Khi ConfigMap được cập nhật, các user được ánh xạ qua role sẽ có quyền theo rule đã định nghĩa.

Vietnix – Nền tảng Enterprise Cloud tối ưu cho mọi giải pháp Kubernetes

Để triển khai và quản lý hiệu quả các hệ thống Kubernetes, đặc biệt là khi thiết lập các cơ chế phân quyền phức tạp, đòi hỏi một hạ tầng đám mây với hiệu năng cao và khả năng tùy biến linh hoạt. Vietnix cung cấp dịch vụ Enterprise Cloud hiệu suất vượt trội, lý tưởng để bạn xây dựng và vận hành các cụm Kubernetes. Với các tùy chọn cấu hình mạnh mẽ, bộ vi xử lý hiệu suất cao, ổ cứng NVMe siêu tốc và kết nối mạng ổn định, Vietnix đảm bảo bạn có một nền tảng vững chắc để triển khai các control plane, quản lý RBAC và bảo vệ các workload của mình.

Thông tin liên hệ:

• Website: https://vietnix.vn/
• Hotline: 1800 1093
• Email: sales@vietnix.com.vn
• Địa chỉ: 265 Hồng Lạc, Phường Bảy Hiền, Thành Phố Hồ Chí Minh

Phân quyền trong K8s thông qua cơ chế RBAC là một yếu tố nền tảng và không thể thiếu để đảm bảo an ninh và quản lý hiệu quả một cụm Kubernetes. Việc hiểu rõ cách định nghĩa quy tắc, tạo và gán quyền sẽ là chìa khóa để xây dựng một môi trường Kubernetes không chỉ mạnh mẽ, linh hoạt mà còn an toàn và tuân thủ các tiêu chuẩn bảo mật hiện đại.