Ответ
RBAC (Role-Based Access Control) в Kubernetes — это механизм управления доступом, который регулирует, какие действия (verbs) могут выполнять пользователи, группы или сервисные аккаунты (субъекты) над ресурсами (objects) в кластере. Это стандартный и наиболее рекомендуемый способ контроля доступа в K8s.
Основные компоненты RBAC:
- Role / ClusterRole: Определяет набор правил доступа.
- Role: Действует в пределах конкретного namespace.
- ClusterRole: Действует на уровне всего кластера (для кластерных ресурсов типа Nodes, PersistentVolumes) или может быть использован для предоставления доступа к ресурсам во всех/определённых namespaces.
- RoleBinding / ClusterRoleBinding: Связывает Role или ClusterRole с одним или несколькими субъектами.
- RoleBinding: Привязывает Role к субъектам в рамках одного namespace.
- ClusterRoleBinding: Привязывает ClusterRole к субъектам на уровне всего кластера.
Практический пример: Предоставление сервисному аккаунту права читать Pods в namespace monitoring.
1. Создаём ServiceAccount:
apiVersion: v1
kind: ServiceAccount
metadata:
name: pod-reader-sa
namespace: monitoring2. Создаём 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Ответ 18+ 🔞
А, RBAC в кубере! Ну это ж классика, ёпта. Система, которая пытается сделать так, чтобы всякие левые сервисные аккаунты не шарились там, где им не положено. Типа чтоб какой-нибудь прометеус не начал вдруг удалять поды, а дженкинс — секреты читать. В общем, чтоб бардака не было, а то потом волнение ебать — кто что натворил, и подозрение ебать чувствую на каждого.
Смотри, суть проще пареной репы, если не заморачиваться. Есть у нас Роли (Role) и КластерРоли (ClusterRole). Первые — как местные пацаны, только в своём неймспейсе рулят. Вторые — уже хуй с горы, на весь кластер замах. В них ты пишешь правила: что можно трогать (поды, сервисы, деплойменты) и что с этим делать (смотреть, создавать, удалять — это verbs).
А чтобы эти правила кому-то применить, нужны Привязки (RoleBinding и ClusterRoleBinding). Это как пропуск выписать. Связал роль с сервисным аккаунтом — и всё, чувак может работать в отведённых рамках. Не связал — сидит, бздит, и нихуя не может.
Вот смотри, реальный пример, как дать какому-то сервису право только смотреть на поды в неймспейсе monitoring, но не трогать. Чисто для мониторинга.
1. Делаем сервисный аккаунт — нашего наблюдателя.
apiVersion: v1
kind: ServiceAccount
metadata:
name: pod-reader-sa
namespace: monitoringПросто создали учётку. Пока что это просто имя, доверия ебать ноль.
2. Пишем роль — инструкцию, что можно.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: monitoring
name: pod-reader-role
rules:
- apiGroups: [""] # Это ядро API, группы типа pods, services
resources: ["pods"] # Конкретно поды
verbs: ["get", "list", "watch"] # Только смотреть, вынюхивать, но не менять!Вот эта штука говорит: в неймспейсе monitoring можно листать и читать поды. Всё. Попробуй удалить — получишь отлуп.
3. Выдаём пропуск — привязываем роль к аккаунту.
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Всё, готово. Теперь pod-reader-sa — законный зритель.
А где это в жизни нужно? Да овердохуища где!
- Твоему CI/CD (типа Jenkins): Даёшь сервисному аккаунту роль на
createиupdateдеплойментов в неймспейсеprod, но НИКОГДА не даёшьdeleteили доступ вkube-system. А то будет вам хиросима и нигерсраки. - Изоляция команд: Чуваки из команды "А" — боги в своём
team-aнеймспейсе. А вteam-bу них роль только на чтение, чтобы не шаловливые ручки тянули. - Для прометеуса: Делаешь ClusterRole (чтоб во всех неймспейсах мог смотреть) с правами
get,list,watchна поды, эндпоинты и всё такое. Привязываешь через ClusterRoleBinding к его сервисному аккаунту. И он летает по всему кластеру и собирает метрики. - Главный принцип — минимальные привилегии. Не надо каждой мартышлюшке-приложению давать админские права. Создал для неё отдельный сервисный аккаунт, выдал ровно то, что нужно для работы, и спи спокойно.
А если что-то не работает? Не охуевай, есть команда для проверки:
kubectl auth can-i list pods --as=system:serviceaccount:monitoring:pod-reader-sa -n monitoringСпросишь у системы: "А можно этому чуваку листать поды?". Она тебе честно ответит yes или no. Если no — значит, где-то накосячил в привязках, иди ищи, распиздяй.
Вот и вся магия. Сначала кажется, что хуй в пальто, но привыкнешь — удобная хуйня. Главное — не давать лишнего, а то потом сам от себя охуеешь, когда всё полетит к чёрту.