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

Индекс LLMS: [llms.txt](/llms.txt)

---

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

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

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

```bash
kubectl create serviceaccount devops-sa -n staging
```

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

```bash
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
```

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

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

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

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

```yaml
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 по всему кластеру:

```yaml
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"]
```

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

## Создание RoleBinding и ClusterRoleBinding

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

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

```yaml
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):

```yaml
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
```

| Binding | Scope | Role type | Когда использовать |
|---|---|---|---|
| RoleBinding | Один namespace | Role или ClusterRole | Чтение/запись в конкретном ns |
| ClusterRoleBinding | Весь кластер | ClusterRole | Глобальные права (node, pv, dns) |

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

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

```bash
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` для предпросмотра:

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

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

```bash
kubectl get rolebindings,clusterrolebindings --all-namespaces -o json | \
  jq '.items[] | select(.subjects[]?.name=="devops-sa") | {name: .metadata.name, kind: .kind, namespace: .metadata.namespace}'
```

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

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