RBAC и ServiceAccount

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

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

Authentication устанавливает личность вызывающей стороны. 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 без расширения роли.