Авторизация в Kubernetes

Авторизация в K8s происходит на уровне API-сервера. Если у вас нет прав на конкретное действие, сервер вернет ошибку HTTP 403 (Forbidden).

Модули авторизации

Kubernetes поддерживает несколько модулей, которые проверяются по очереди. Если хотя бы один разрешил запрос — он проходит дальше.

• Node (Узел): Специальный режим для kubelet, позволяющий ему изменять только свои собственные ресурсы (свои поды, свои данные).
• ABAC (Attribute-Based Access Control): Управление доступом на основе атрибутов (сложно настраивать, требует перезагрузки API-сервера).
• RBAC (Role-Based Access Control): Стандарт де-факто. Гибкое управление на основе ролей.
• Webhook: Отправка запроса во внешнюю систему для принятия решения.

RBAC: Role-Based Access Control

Это основной механизм управления доступом. Его логика строится на связке трех элементов:

1. Subjects (Субъекты): Кому даем права? (User, Group, ServiceAccount).
2. Resources (Ресурсы): К чему даем доступ? (pods, secrets, configmaps).
3. Verbs (Глаголы): Что можно делать? (get, list, create, update, delete, watch).

Role и ClusterRole

Роли — это наборы правил. Они не говорят, кто имеет доступ, они описывают, какой это доступ.

• Role: Ограничена конкретным Namespace.
• ClusterRole: Действует на уровне всего кластера (включая ноды, неймспейсы и не-ресурсные URL).

Пример Role (только для namespace default):

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" указывает на основной API (v1)
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Пример ClusterRole (на весь кластер):

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

RoleBinding и ClusterRoleBinding

Сами по себе роли ничего не делают. Чтобы они заработали, их нужно «привязать» к субъекту с помощью Binding.

• RoleBinding: Привязывает Role или ClusterRole к пользователю внутри конкретного неймспейса.
• ClusterRoleBinding: Дает права, описанные в ClusterRole, сразу во всем кластере.

Пример RoleBinding (привязка пользователя к роли):

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane # Пользователь Джейн
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader # Ссылка на роль выше
  apiGroup: rbac.authorization.k8s.io

Пример ClusterRoleBinding (права для всей группы):

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager # Все менеджеры теперь видят секреты везде
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Итог

Вы можете использовать RoleBinding, чтобы привязать ClusterRole. В этом случае пользователь получит права из этой роли, но только внутри того неймспейса, где создан Binding. Это отличный способ переиспользовать общие роли (например, view или edit) без дублирования кода.