Перейти к содержимому

Создание пользователя, роли в Kubernetes и их связка через RBAC

Раздел: Посты Слов: 517 3 мин
Lead DevOps

В Kubernetes нет отдельных «пользователей» в классическом смысле — есть ServiceAccount’ы и сертификаты, привязанные к ролям через RBAC. Без правильной настройки любой, у кого есть kubeconfig, получает доступ ко всему кластеру. Ниже — полный цикл: создаём ServiceAccount, определяем права, привязываем и проверяем.

Создание ServiceAccount и генерация kubeconfig

Сначала создаём ServiceAccount в нужном namespace:

kubectl create serviceaccount devops-sa -n staging

Для генерации kubeconfig берём токен из secrets и формируем файл:

SA_NAME=devops-sa
SA_NS=staging

TOKEN=$(kubectl -n $SA_NS get secret $(kubectl -n $SA_NS get sa $SA_NAME -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode)

kubectl config set-credentials $SA_NAME --token=$TOKEN
kubectl config set-context devops-staging --cluster=$(kubectl config current-context) --user=$SA_NAME --namespace=$SA_NS
kubectl config use-context devops-staging
Предупреждение

] Токен ServiceAccount’а — это просто bearer token. Если kubeconfig утечёт, у злоумышленника будет доступ с правами этого SA. Храните файл с правами 600.

Определение Role и ClusterRole

Role — namespace-скопированная сущность, ClusterRole — кластерная. Разница критична: Role не даст прав за пределами своего namespace, ClusterRole — даст.

Пример Role, разрешающей читать pods и запускать поды в namespace staging:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: staging
  name: pod-reader-writer
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch", "create", "delete"]

Пример ClusterRole для управления ingress по всему кластеру:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: ingress-manager
rules:
  - apiGroups: ["networking.k8s.io"]
    resources: ["ingresses"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
Подсказка

] Список apiGroups пустой строкой "" соответствует core API group (v1). Для apps, networking, batch — указывайте соответствующие группы. Полный список групп можно посмотреть через kubectl api-resources.

Создание RoleBinding и ClusterRoleBinding

RoleBinding привязывает Role к субъекту внутри namespace. ClusterRoleBinding — к ClusterRole в масштабе кластера.

Привязка Role к ServiceAccount в namespace staging:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: devops-pod-access
  namespace: staging
subjects:
  - kind: ServiceAccount
    name: devops-sa
    namespace: staging
roleRef:
  kind: Role
  name: pod-reader-writer
  apiGroup: rbac.authorization.k8s.io

Привязка ClusterRole к тому же SA (теперь с правами на весь кластер для ingress):

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: devops-ingress-access
subjects:
  - kind: ServiceAccount
    name: devops-sa
    namespace: staging
roleRef:
  kind: ClusterRole
  name: ingress-manager
  apiGroup: rbac.authorization.k8s.io
BindingScopeRole typeКогда использовать
RoleBindingОдин namespaceRole или ClusterRoleЧтение/запись в конкретном ns
ClusterRoleBindingВесь кластерClusterRoleГлобальные права (node, pv, dns)

Проверка и отладка прав доступа

После применения YAML проверяем, что SA действительно получил нужные права:

kubectl auth can-i get pods --as=system:serviceaccount:staging:devops-sa -n staging
kubectl auth can-i create pods --as=system:serviceaccount:staging:devops-sa -n staging
kubectl auth can-i get ingresses --as=system:serviceaccount:staging:devops-sa

Последняя команда проверяет через ClusterRoleBinding — она вернёт yes, если привязка корректна.

Если что-то не работает, смотрим audit log или используем kubectl auth reconcile с --dry-run=server для предпросмотра:

kubectl auth reconcile role-binding.yaml --dry-run=server

Ещё один полезный приём — проверить, какие RoleBinding’ы привязаны к конкретному SA:

kubectl get rolebindings,clusterrolebindings --all-namespaces -o json | \
  jq '.items[] | select(.subjects[]?.name=="devops-sa") | {name: .metadata.name, kind: .kind, namespace: .metadata.namespace}'
Примечание

] kubectl auth can-i проверяет только разрешения, но не учитывает NetworkPolicy или PodSecurityPolicy. Если pod не запускается — проблема может быть и в них.

Итог: RBAC в Kubernetes работает цепочкой — SA → Role/ClusterRole → Binding. Каждое звено можно проверять отдельно, что сильно упрощает отладку. Начинайте с минимальных прав и расширяйте по мере необходимости, не давайте cluster-admin без крайней необходимости.

Изменено 23.09.2026