Какими механизмами в Kubernetes организуется доступ к кастомным ресурсам (Custom Resource Definitions, CRD)?

Доступ к кастомным ресурсам (CR) организуется через RBAC (Role-Based Access Control). Механизм тот же, что и для встроенных ресурсов, но с указанием API-группы CRD.

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

1. ClusterRole / Role: Определяют набор правил (правил доступа). ClusterRole — для доступа в масштабе кластера, Role — в пределах namespace.
2. ClusterRoleBinding / RoleBinding: Связывают субъекта (пользователя, группу, ServiceAccount) с ролью.

Пример: Предоставление доступа ServiceAccount к CRD crontabs.stable.example.com.

Сначала создаём Role в namespace monitoring, который разрешает основные операции с ресурсом crontabs:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: monitoring
  name: crontab-editor
rules:
- apiGroups: ["stable.example.com"] # API-группа CRD
  resources: ["crontabs"]           # Имя ресурса (множественное число)
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Затем привязываем эту роль к ServiceAccount monitor-bot:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: grant-crontab-access
  namespace: monitoring
subjects:
- kind: ServiceAccount
  name: monitor-bot
  namespace: monitoring
roleRef:
  kind: Role
  name: crontab-editor
  apiGroup: rbac.authorization.k8s.io

Теперь Pod, использующий ServiceAccount monitor-bot, сможет управлять Crontab-ресурсами в namespace monitoring. Для кластерных CRD (с scope: Cluster) и доступа из разных namespace используется связка ClusterRole и ClusterRoleBinding.