Настройка RBAC через ClusterRoleBinding
В контексте описанной выше интеграции критически важно правильно разграничить доступ к Kubernetes-кластеру. Аутсорсинговая команда не должна иметь полный доступ ко всем неймспейсам — это риск безопасности. Используем ClusterRoleBinding и RoleBinding в связке с ServiceAccount или внешними identity-провайдерами (OIDC).
Сценарий
- Есть аутсорсинговая DevOps-команда, которая управляет CI/CD, мониторингом и слаботочной инфраструктурой (IoT Hub).
- Им нужен доступ только к определённым неймспейсам (
monitoring,iot-hub,ci-cd) с возможностью просмотра подов, логов, запуска отладки. - Доступ к нодам, secrets (кроме их собственных) и критическим компонентам (kube-system) — запрещён.
Решение: ClusterRole + ClusterRoleBinding (для глобальных прав) и RoleBinding (для неймспейс-специфичных)
Создадим ClusterRole с минимальными правами для чтения ресурсов во всём кластере (например, просмотр нод, storage classes — это бывает нужно для понимания топологии, но без права изменять). А затем через RoleBinding дадим более широкие (например, CRUD подов) только в нужных неймспейсах.
Шаг 1. Создаём ServiceAccount для аутсорсера
Хорошей практикой является создание отдельного ServiceAccount для каждой аутсорсинговой команды, а не использование пользовательских аккаунтов (User). Это упрощает аудит.
apiVersion: v1
kind: ServiceAccount
metadata:
name: outsourcing-devops
namespace: default
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: readonly-global
rules:
- apiGroups: [""]
resources: ["nodes", "persistentvolumes", "storageclasses", "namespaces"]
verbs: ["get", "list", "watch"]
- apiGroupsШаг 3. Создаём Role для каждого неймспейса, где нужны расширенные права
В неймспейсах monitoring, iot-hub и ci-cd дадим права на управление подами, деплойментами, сервисами, конфигмапами и секретами (только в этих неймспейсах).
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: devops-manager
namespace: monitoring
rules:
- apiGroups: ["", "apps", "batch"]
resources: ["pods", "pods/log", "pods/exec", "deployments", "statefulsets", "daemonsets", "services", "configmaps", "secrets", "jobs", "cronjobs"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["autoscaling"]
resources: ["horizontalpodautoscalers"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: devops-manager
namespace: iot-hub
rules:
- apiGroups: ["", "apps", "batch"]
resources: ["pods", "pods/log", "pods/exec", "deployments", "statefulsets", "daemonsets", "services", "configmaps", "secrets", "jobs", "cronjobs"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: devops-manager
namespace: ci-cd
rules:
- apiGroups: ["", "apps", "batch"]
resources: ["pods", "pods/log", "pods/exec", "deployments", "statefulsets", "daemonsets", "services", "configmaps", "secrets", "jobs", "cronjobs"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
Шаг 4. Связываем ServiceAccount с правами через RoleBinding (неймспейс-специфичные)
Теперь привязываем ServiceAccount outsourcing-devops к каждой Role.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: outsourcing-devops-monitoring
namespace: monitoring
subjects:
- kind: ServiceAccount
name: outsourcing-devops
namespace: default
roleRef:
kind: Role
name: devops-manager
apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: outsourcing-devops-iot-hub
namespace: iot-hub
subjects:
- kind: ServiceAccount
name: outsourcing-devops
namespace: default
roleRef:
kind: Role
name: devops-manager
apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: outsourcing-devops-ci-cd
namespace: ci-cd
subjects:
- kind: ServiceAccount
name: outsourcing-devops
namespace: default
roleRef:
kind: Role
name: devops-manager
apiGroup: rbac.authorization.k8s.io
Шаг 5. Связываем ServiceAccount с глобальными правами только на чтение через ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: outsourcing-devops-global-readonly
subjects:
- kind: ServiceAccount
name: outsourcing-devops
namespace: default
roleRef:
kind: ClusterRole
name: readonly-global
apiGroup: rbac.authorization.k8s.io
Итоговая модель доступа
| Ресурс | Доступ |
|---|---|
| Nodes (ноды) | Только чтение (get, list, watch) |
| PersistentVolumes (PV) | Только чтение |
| StorageClasses | Только чтение |
| Namespaces (все) | Только чтение |
Pods, Deployments, Services, ConfigMaps, Secrets, Jobs, HPA в неймспейсах monitoring, iot-hub, ci-cd |
Полный CRUD (create, read, update, delete) |
Pods, Deployments, Services, ConfigMaps, Secrets, Jobs, HPA в остальных неймспейсах (например, default, kube-system, production) |
Нет доступа |
| RoleBindings, ClusterRoles, ServiceAccounts (RBAC) | Нет доступа |
Данная конфигурация:
- Даёт аутсорсинговой команде минимально необходимые права (принцип least privilege).
- Позволяет видеть глобальную инфраструктуру (ноды, PV, StorageClasses) без возможности изменять.
- Даёт полный контроль над приложениями только в целевых неймспейсах.
- Запрещает изменять права доступа (RBAC), что защищает от эскалации привилегий.
Дополнительные рекомендации по безопасности
- Вести аудит – включить аудит Kubernetes API, чтобы отслеживать действия аутсорсеров.
- Использовать Pod Security Admission – настроить политики безопасности для подов в этих неймспейсах (например, запретить запуск с root, ограничить capabilities).
- Network Policies – ограничить сетевой трафик между неймспейсами, чтобы изолировать рабочие нагрузки аутсорсеров.
- Resource Quotas – установить квоты на CPU/RAM в неймспейсах, чтобы предотвратить истощение ресурсов кластера.
- ServiceAccount токены – выдавать ограниченные по времени токены или использовать внешние OIDC-провайдеры.
- Регулярный пересмотр прав – периодически проверять, не нужны ли команде более широкие права, и отзывать лишние.
Если потребуется более гибкий доступ (например, дать права только на pods/log без права на exec), можно детализировать правила в Role.
0