Что такое ролевая модель доступа в Kubernetes?

Что такое ролевая модель доступа (RBAC) в Kubernetes?

Ролевая модель доступа (Role-Based Access Control, RBAC) — это механизм управления разрешениями в Kubernetes, который регулирует, какие действия могут выполнять пользователи, сервисные аккаунты или группы внутри кластера. RBAC позволяет назначать права доступа на основе ролей, которые объединяют наборы правил, а затем привязывать эти роли к конкретным субъектам (пользователям или сервисным аккаунтам). Это критически важный компонент безопасности Kubernetes, обеспечивающий принцип наименьших привилегий.

Ключевые компоненты RBAC

1. Субъекты (Subjects):

   • Пользователи (Users): Внешние пользователи, аутентифицированные через сертификаты, токены или другие механизмы.
   • Группы (Groups): Коллекции пользователей (например, dev-team, admins).
   • Сервисные аккаунты (ServiceAccounts): Аккаунты для внутренних компонентов (подов, приложений).

2. Ресурсы (Resources):

   • Объекты Kubernetes, такие как Pods, Deployments, Services, ConfigMaps, Secrets и другие.
   • Также включают API-группы (например, apps/v1, networking.k8s.io/v1).

3. Роли (Roles) и ClusterRoles:

   • Role: Определяет права доступа в рамках конкретного namespace. Например, разрешает чтение Pods только в namespace default.
   • ClusterRole: Определяет права доступа на уровне всего кластера (например, доступ к узлам или PersistentVolumes) или может использоваться в нескольких namespace.

4. Привязки ролей (RoleBindings) и ClusterRoleBindings:

   • RoleBinding: Связывает Role или ClusterRole с субъектами в рамках конкретного namespace.
   • ClusterRoleBinding: Связывает ClusterRole с субъектами на уровне всего кластера.

Примеры правил в RBAC

Правила в ролях определяются с помощью полей:

• apiGroups: API-группы (например, "" для core API, "apps").
• resources: Типы ресурсов (например, pods, deployments).
• verbs: Действия (например, get, list, create, update, delete, watch).

Пример Role, разрешающей чтение Pods в namespace default:

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

Пример RoleBinding, связывающей эту роль с пользователем alice:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: default
  name: read-pods
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Практическое применение RBAC

• Изоляция команд: Разработчики получают доступ только к своим namespace, а администраторы — ко всему кластеру.
• Безопасность сервисных аккаунтов: Ограничение прав для Pods (например, приложению в production можно запретить удаление ресурсов).
• Аудит и соответствие требованиям: Чёткое логирование действий пользователей на основе их ролей.

Важные аспекты настройки RBAC

• Принцип наименьших привилегий: Назначать только необходимые права.
• Регулярный аудит ролей: Проверять неиспользуемые или избыточные разрешения.
• Использование ClusterRoles для повторного использования: Например, создать ClusterRole view, которую можно применять в разных namespace через RoleBinding.
• Интеграция с внешними системами: RBAC часто комбинируют с OpenID Connect, LDAP или корпоративными системами управления идентификацией.

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

Для проверки прав доступа можно использовать команды kubectl auth can-i:

# Проверить, может ли текущий пользователь создавать Pods
kubectl auth can-i create pods

# Проверить для конкретного пользователя
kubectl auth can-i list deployments --as=alice

Также полезны инструменты вроде kubectl-whoami или встроенные механизмы аудита Kubernetes.

Заключение

RBAC в Kubernetes — это мощный и гибкий механизм, который стал стандартом для управления доступом с версии 1.6. Его правильная настройка требует понимания как бизнес-логики доступа, так и технических деталей Kubernetes API. В production-средах RBAC обычно дополняют сетевыми политиками (NetworkPolicies), Pod Security Standards и внешними системами аутентификации для создания многоуровневой системы безопасности.