RBAC і ServiceAccount

Ви навчитеся проєктувати доступ Kubernetes за принципом найменших привілеїв, пов’язувати ServiceAccount із Role або ClusterRole, перевіряти фактичні дозволи та діагностувати відповідь Forbidden.

• authentication, authorization та admission
• Role і ClusterRole
• RoleBinding і ClusterRoleBinding
• ServiceAccount і короткоживучі токени
• kubectl auth can-i та impersonation

Authentication встановлює особу сторони, що викликає API. Authorization перевіряє, чи дозволено цій особі виконати verb над resource або non-resource URL. Admission виконується після authorization і може перевірити або змінити об’єкт. Помилка 401 означає, що особу не встановлено; 403 Forbidden — особа відома, але дію не дозволено.

RBAC — один з authorizer Kubernetes. Його правила лише дозволяють дії: deny-правил і пріоритету між правилами немає, а підсумкові повноваження є об’єднанням усіх відповідних bindings.

Role містить namespaced permissions та існує в одному namespace. ClusterRole є cluster-scoped: вона може описувати cluster resources або повторно використовуваний набір namespaced permissions.

RoleBinding надає права лише в namespace самої прив’язки й може посилатися на Role із цього namespace або на ClusterRole. ClusterRoleBinding надає права в усьому кластері. roleRef після створення незмінний; для зміни ролі binding створюють заново.

• subjects: User, Group або ServiceAccount
• apiGroups: API-групи ресурсів
• resources і subresources: наприклад pods та pods/log
• verbs: get, list, watch, create, update, patch, delete

ServiceAccount — namespaced identity для workload. Pod використовує spec.serviceAccountName; без нього призначається default ServiceAccount свого namespace. ServiceAccount сам собою не надає прав — їх надають bindings.

Сучасний kubelet монтує короткоживучий, автоматично оновлюваний projected token через TokenRequest API. Постійні token Secrets не рекомендуються. Якщо контейнеру не потрібен Kubernetes API, вимикайте automountServiceAccountToken, як у лабораторному ServiceAccount.

Least privilege означає мінімальні verbs, resources і namespace. Wildcards автоматично охоплять і майбутні ресурси, тому особливо небезпечні. Доступ get, list або watch до Secrets розкриває їхній вміст.

Право створювати Pods або інші workloads часто дозволяє підключити доступні namespace Secrets і ServiceAccounts. Обережно надавайте bind, escalate та impersonate: ці verbs обходять звичайні межі делегування. cluster-admin і група system:masters призначені лише для виняткових адміністративних операцій.

• Спочатку визначте суб’єкт, ресурс, verb і scope; лише потім пишіть правило
• Надавайте перевагу RoleBinding та окремому ServiceAccount для кожного workload
• Не додавайте wildcard заради усунення Forbidden
• Перевіряйте як дозволені, так і заборонені операції
• Ураховуйте subresources: pods/log відрізняється від pods
• Зміни RBAC рецензуйте як зміни production-коду
• Команди з --as виконуйте лише з облікового запису з правом impersonate

Практика розрахована на навчальний kind-кластер, де поточний адміністратор може виконувати impersonation. Спочатку створіть namespace, потім збережіть наступні три об’єкти як rbac-lab.yaml.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: reader
  namespace: lab-rbac
automountServiceAccountToken: false
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: lab-rbac
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader
  namespace: lab-rbac
subjects:
  - kind: ServiceAccount
    name: reader
    namespace: lab-rbac
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pod-reader

Застосуйте маніфест і перевірте позитивні та негативні випадки. Очікуються відповіді yes для читання Pods і logs у lab-rbac; no для create Pods, читання Secrets і доступу до Pods у default.

kubectl create namespace lab-rbac
kubectl apply -f rbac-lab.yaml
kubectl get serviceaccount,role,rolebinding -n lab-rbac
kubectl auth can-i get pods --as=system:serviceaccount:lab-rbac:reader -n lab-rbac
kubectl auth can-i get pods --subresource=log --as=system:serviceaccount:lab-rbac:reader -n lab-rbac
kubectl auth can-i create pods --as=system:serviceaccount:lab-rbac:reader -n lab-rbac
kubectl auth can-i get secrets --as=system:serviceaccount:lab-rbac:reader -n lab-rbac
kubectl auth can-i get pods --as=system:serviceaccount:lab-rbac:reader -n default
kubectl auth can-i --list --as=system:serviceaccount:lab-rbac:reader -n lab-rbac

Якщо API відповідає Forbidden на саму спробу impersonation, поточному обліковому запису не дозволено verb impersonate. Не розширюйте його права автоматично: виконайте перевірку через затверджену адміністративну процедуру.

Навмисно спрямуйте RoleBinding на неіснуючий ServiceAccount. Читання від імені reader отримає Forbidden, а can-i поверне no. Зіставте subject, roleRef і правила Role, потім відновіть прив’язку.

kubectl patch rolebinding pod-reader -n lab-rbac --type=json -p='[{"op":"replace","path":"/subjects/0/name","value":"wrong-reader"}]'
kubectl get pods -n lab-rbac --as=system:serviceaccount:lab-rbac:reader
kubectl auth can-i get pods -n lab-rbac --as=system:serviceaccount:lab-rbac:reader
kubectl get rolebinding pod-reader -n lab-rbac -o yaml
kubectl describe role pod-reader -n lab-rbac
kubectl patch rolebinding pod-reader -n lab-rbac --type=json -p='[{"op":"replace","path":"/subjects/0/name","value":"reader"}]'
kubectl auth can-i get pods -n lab-rbac --as=system:serviceaccount:lab-rbac:reader
kubectl delete namespace lab-rbac

Діагностичний ланцюжок: context та identity → verb/resource/subresource → namespace → усі bindings суб’єкта → roleRef → rules → admission і зовнішні authorizers. Не лікуйте 403 наданням cluster-admin.

• Чому RBAC не може виразити явний deny?
• Чим RoleBinding на ClusterRole відрізняється від ClusterRoleBinding?
• Чому list Secrets майже рівнозначний читанню кожного Secret?
• Коли Pod не слід монтувати ServiceAccount token?
• Чому --as може завершитися Forbidden ще до перевірки цільової дії?
• Які ризики несуть bind, escalate та impersonate?

Модуль засвоєно, якщо ви будуєте мінімальну матрицю суб’єкт → verb → resource → scope, підтверджуєте дозволи через can-i та знаходите неправильний subject без розширення ролі.