[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-bezopasnost-konteynerov-kak-rabotaet-rbac-v-kubernetes":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":20,"progress":21,"seo":22},319,"kak-rabotaet-rbac-v-kubernetes",9,"bezopasnost-konteynerov","Безопасность контейнеров","🛡️","Как работает RBAC в Kubernetes?","\u003C!-- grade: -->\n\n**RBAC (Role-Based Access Control)** — механизм авторизации в Kubernetes, который определяет, какой субъект (пользователь, группа, сервисный аккаунт) может выполнять какие действия (глаголы) над какими ресурсами. RBAC включён по умолчанию и является основным инструментом управления доступом в кластере.\n\n**Основные объекты RBAC:**\n\n| Объект | Область действия | Описание |\n|--------|-----------------|----------|\n| **Role** | Namespace | Набор разрешений в пределах одного namespace |\n| **ClusterRole** | Кластер | Набор разрешений на уровне всего кластера |\n| **RoleBinding** | Namespace | Привязывает Role или ClusterRole к субъекту в рамках namespace |\n| **ClusterRoleBinding** | Кластер | Привязывает ClusterRole к субъекту на уровне всего кластера |\n\n**Субъекты RBAC:**\n\n- **User** — обычный пользователь, управляемый внешней системой аутентификации (LDAP, OIDC и т.д.). Kubernetes не хранит учётные записи пользователей самостоятельно.\n- **Group** — группа пользователей для упрощения управления правами.\n- **ServiceAccount** — учётная запись для подов и внутренних сервисов кластера. В отличие от User, ServiceAccount — это полноценный ресурс Kubernetes.\n\n**1. Создание ServiceAccount для Java-приложения:**\n\n```yaml\napiVersion: v1\nkind: ServiceAccount\nmetadata:\n  name: banking-service-sa\n  namespace: banking\nautomountServiceAccountToken: false  # Не монтировать токен по умолчанию\n```\n\nПараметр `automountServiceAccountToken: false` означает, что токен сервисного аккаунта не будет автоматически смонтирован в файловую систему пода. Это важно, потому что смонтированный токен может быть использован злоумышленником для доступа к Kubernetes API при компрометации контейнера.\n\n**2. Role с минимальными правами (принцип наименьших привилегий):**\n\n```yaml\napiVersion: rbac.authorization.k8s.io\u002Fv1\nkind: Role\nmetadata:\n  name: banking-service-role\n  namespace: banking\nrules:\n# Чтение ConfigMaps (для конфигурации приложения)\n- apiGroups: [\"\"]\n  resources: [\"configmaps\"]\n  verbs: [\"get\", \"watch\"]\n  resourceNames: [\"banking-service-config\"]  # Доступ только к конкретному ConfigMap\n\n# Чтение секретов (только конкретных)\n- apiGroups: [\"\"]\n  resources: [\"secrets\"]\n  verbs: [\"get\"]\n  resourceNames: [\"banking-db-credentials\"]\n```\n\nПоле `resourceNames` ограничивает доступ конкретными именованными ресурсами — без него Role даёт доступ ко **всем** ресурсам указанного типа в namespace, что нарушает принцип наименьших привилегий.\n\n**3. RoleBinding — привязка роли к субъекту:**\n\n```yaml\napiVersion: rbac.authorization.k8s.io\u002Fv1\nkind: RoleBinding\nmetadata:\n  name: banking-service-binding\n  namespace: banking\nsubjects:\n- kind: ServiceAccount\n  name: banking-service-sa\n  namespace: banking\nroleRef:\n  kind: Role\n  name: banking-service-role\n  apiGroup: rbac.authorization.k8s.io\n```\n\nRoleBinding связывает субъект (ServiceAccount) с набором разрешений (Role). После создания этого ресурса сервисный аккаунт `banking-service-sa` получит только те права, которые определены в `banking-service-role`.\n\n**4. Использование ServiceAccount в Deployment:**\n\n```yaml\napiVersion: apps\u002Fv1\nkind: Deployment\nmetadata:\n  name: banking-service\n  namespace: banking\nspec:\n  template:\n    spec:\n      serviceAccountName: banking-service-sa\n      automountServiceAccountToken: true  # Включить только если приложению нужен доступ к K8s API\n      containers:\n      - name: app\n        image: registry.bank.local\u002Fbanking-service:1.0.0\n```\n\nЗначение `automountServiceAccountToken: true` на уровне Pod spec переопределяет настройку ServiceAccount. Устанавливайте его в `true` только в том случае, если приложению действительно необходим программный доступ к Kubernetes API (например, для service discovery или работы с ConfigMap).\n\n**5. ClusterRole для кросс-namespace доступа (пример для мониторинга):**\n\n```yaml\napiVersion: rbac.authorization.k8s.io\u002Fv1\nkind: ClusterRole\nmetadata:\n  name: monitoring-reader\nrules:\n- apiGroups: [\"\"]\n  resources: [\"pods\", \"services\", \"endpoints\"]\n  verbs: [\"get\", \"list\", \"watch\"]\n- apiGroups: [\"metrics.k8s.io\"]\n  resources: [\"pods\"]\n  verbs: [\"get\", \"list\"]\n```\n\nClusterRole отличается от Role тем, что работает на уровне всего кластера. Это необходимо, например, для систем мониторинга (Prometheus), которые должны собирать метрики из подов во всех namespace-ах.\n\n**Проверка прав (диагностика):**\n\n```bash\n# Проверить, может ли ServiceAccount получить секреты\nkubectl auth can-i get secrets \\\n    --as=system:serviceaccount:banking:banking-service-sa \\\n    -n banking\n\n# Вывести все права ServiceAccount в данном namespace\nkubectl auth can-i --list \\\n    --as=system:serviceaccount:banking:banking-service-sa \\\n    -n banking\n```\n\nКоманда `kubectl auth can-i` позволяет проверить, имеет ли конкретный субъект право на выполнение определённого действия. Это полезно для аудита и отладки проблем с доступом.\n\n**Типичные ошибки при настройке RBAC:**\n\n| Ошибка | Почему это опасно | Как правильно |\n|--------|-------------------|---------------|\n| Привязка `cluster-admin` к сервисному аккаунту приложения | Даёт полные права на всё в кластере — любая компрометация контейнера ведёт к компрометации всего кластера | Создавать отдельную Role с минимально необходимыми правами |\n| Разрешение `*` (wildcard) на все ресурсы и глаголы | Фактически эквивалент admin-доступа | Указывать конкретные ресурсы и глаголы |\n| Использование default ServiceAccount | Имеет автоматически монтируемый токен и может иметь унаследованные права | Создавать именованный ServiceAccount для каждого сервиса |\n| Отсутствие `resourceNames` в Role | Даёт доступ ко **всем** ресурсам данного типа, а не к конкретным | Указывать `resourceNames` везде, где это возможно |\n\n**Рекомендации для банковских систем:**\n\n- **Один микросервис — один ServiceAccount** с минимально необходимыми правами. Это обеспечивает изоляцию: компрометация одного сервиса не даёт доступа к ресурсам другого.\n- **Регулярный аудит RBAC** с помощью специализированных инструментов: `kubectl-who-can` (кто имеет доступ к ресурсу), `rbac-lookup` (какие права у субъекта), `rakkess` (обзор прав в namespace).\n- **Интеграция с корпоративным IdP** (LDAP\u002FActive Directory) через OIDC для аутентификации пользователей-администраторов.\n- **Запрет `automountServiceAccountToken`** по умолчанию — включать только для сервисов, которым действительно нужен доступ к Kubernetes API.","","middle",[15,16,17,18,19],"authorization","kubernetes","rbac","container-security","access-control",[],null,{"title":23,"description":24,"ogTitle":23,"ogDescription":25,"keywords":26,"schemaAnswer":34,"featuredSnippetReady":35},"RBAC в Kubernetes: Role, ClusterRole, RoleBinding — Gymterview","Как работает RBAC (Role-Based Access Control) в Kubernetes? Объекты Role, ClusterRole, RoleBinding, ClusterRoleBinding. ServiceAccount для Java-приложений, минимальные права и аудит RBAC.","Механизм авторизации RBAC в Kubernetes: объекты Role, ClusterRole, RoleBinding, настройка ServiceAccount с минимальными правами для Java-приложений.",[27,28,29,30,31,32,33],"RBAC Kubernetes","Role-Based Access Control","Role ClusterRole","RoleBinding","ServiceAccount Kubernetes","управление доступом Kubernetes","безопасность контейнеров","RBAC (Role-Based Access Control) — механизм авторизации в Kubernetes, определяющий, кто может выполнять какие действия над какими ресурсами. Основные объекты: Role (разрешения в namespace), ClusterRole (разрешения на уровне кластера), RoleBinding и ClusterRoleBinding (привязка ролей к субъектам). Субъекты — User, Group и ServiceAccount. Каждый микросервис должен иметь свой ServiceAccount с минимальными правами, использовать resourceNames для ограничения доступа к конкретным ресурсам и отключать automountServiceAccountToken по умолчанию.",true]