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

RBAC (Role-Based Access Control) в Kubernetes — это механизм управления доступом, который регулирует, какие действия (verbs) могут выполнять пользователи, группы или сервисные аккаунты (субъекты) над ресурсами (objects) в кластере. Это стандартный и наиболее рекомендуемый способ контроля доступа в K8s.

Основные компоненты RBAC:

1. Role / ClusterRole: Определяет набор правил доступа.
   • Role: Действует в пределах конкретного namespace.
   • ClusterRole: Действует на уровне всего кластера (для кластерных ресурсов типа Nodes, PersistentVolumes) или может быть использован для предоставления доступа к ресурсам во всех/определённых namespaces.
2. RoleBinding / ClusterRoleBinding: Связывает Role или ClusterRole с одним или несколькими субъектами.
   • RoleBinding: Привязывает Role к субъектам в рамках одного namespace.
   • ClusterRoleBinding: Привязывает ClusterRole к субъектам на уровне всего кластера.

Практический пример: Предоставление сервисному аккаунту права читать Pods в namespace monitoring.

1. Создаём ServiceAccount:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-reader-sa
  namespace: monitoring

2. Создаём Role с правами на чтение Pods:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: monitoring
  name: pod-reader-role
rules:
- apiGroups: [""] # Ядро API группы (пустая строка)
  resources: ["pods"] # Ресурс
  verbs: ["get", "list", "watch"] # Разрешённые действия

3. Связываем Role с ServiceAccount через RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-binding
  namespace: monitoring
subjects:
- kind: ServiceAccount
  name: pod-reader-sa
  namespace: monitoring
roleRef:
  kind: Role
  name: pod-reader-role
  apiGroup: rbac.authorization.k8s.io

Типичные сценарии использования в DevOps:

• Доступ для CI/CD: Сервисному аккаунту Jenkins/GitLab Runner дают права на деплой (create, update) в определённых namespaces.
• Изоляция команд: Разработчикам команды "А" дают полный доступ в namespace team-a, но только чтение в team-b.
• Мониторинг: Сервисному аккаунту Prometheus дают права на get, list, watch для Pods, Services, Endpoints во всех namespaces через ClusterRole и ClusterRoleBinding.
• Минимальные привилегии: Для каждого приложения создаётся отдельный ServiceAccount с правами, строго необходимыми для его работы (принцип least privilege).

Проверка прав: Утилиты kubectl auth can-i помогают отлаживать политики:

kubectl auth can-i list pods --as=system:serviceaccount:monitoring:pod-reader-sa -n monitoring
# Ответ: yes