Управление доступом#

Описание#

В данном разделе описан стандартный процесс управления доступом к кластеру DropApp на основе существующего каталога пользователей (LDAP/Active Directory).

В качестве механизма авторизации используется RBAC Kubernetes - создание ролей и кластерных ролей (Role/ClusterRole), определяющих допустимые действия над ресурсами кластера, и привязка этих ролей привязываются к группам и/или отдельным пользователям через объекты RoleBinding и ClusterRoleBinding. Группы и учетные записи берутся из корпоративного каталога, что позволяет использовать единый источник прав и идентичностей для всех систем, включая Kubernetes.

Ниже описаны типовые шаги:

  • выбор уровня доступа (пространство имен или весь кластер);

  • проектирование набора разрешений;

  • создание ролей;

  • создание привязок к группам AD/LDA;

  • проверка корректности работы (тестовый логин, попытка выполнения разрешенных и запрещенных операций).

Также приведены рекомендации по именованию ролей и привязок, принципам разделения обязанностей и минимально необходимым правам, чтобы обеспечить единообразный подход к управлению доступом во всех командах.

Контекст использования#

Основная цель — обеспечить безопасное, предсказуемое и управляемое распределение прав в кластере DropApp за счет использования централизованного каталога пользователей. Вместо ручной выдачи прав на уровне отдельных учетных записей в кластере используются существующие группы и организационные структуры в LDAP/Active Directory. Это снижает риск ошибок, исключает дублирование учетных записей и упрощает отзыв доступа при увольнении или смене роли сотрудника: достаточно обновить членство в группах в одном месте.

Также целью являются прозрачность и контроль. Формализованный процесс создания ролей и привязки их к группам позволяет документировать, кто и почему имеет тот или иной доступ, а также воспроизводить настройки в других кластерах (dev/stage/prod) через единый подход и инфраструктуру как код (Helm, Kustomize, GitOps и т.п.). В результате, команды разработки получают понятную модель прав, а служба безопасности — контролируемый и проверяемый механизм управления доступом.

Предварительные условия (пример групп пользователей)#

Перед настройкой ролей и привязок (RBAC) необходимо выполнить следующие условия:

  • развернут кластер DropApp;

  • созданы выделенные под команды пространства имен:

    • team-a;

    • team-b;

    • team-c.

  • настроена интеграция аутентификации Dex с корпоративным каталогом (LDAP или Active Directory).

    Важно

    При аутентификации пользователь получает токен, в котором есть информация о его группах из каталога. DropApp использует эти группы для принятия решений в RBAC.

  • определены группы пользователей;

  • заведена учетная запись с правами cluster-admin.

Группы пользователей#

В каталоге определены группы, отражающие роль сотрудника и его принадлежность к команде, например:

  • Администраторы команд:

    • team-a-admins;

    • team-b-admins;

    • team-c-admins.

  • Разработчики:

    • team-a-developers;

    • team-b-developers;

    • team-c-developers.

  • Тестировщики:

    • team-a-testers;

    • team-b-testers;

    • team-c-testers.

Пользователи включены в соответствующие группы в каталоге (например, разработчик команды A состоит в team-a-developers).

Права cluster-admin#

Предварительным условием является созданная учетная запись с правами cluster-admin (или эквивалентными), от имени которой будут создаваться объекты:

  • ClusterRole;

  • RoleBinding в пространствах имен команд.

Добавление ролей#

В данном разделе описан пример настройки ролей и привязок:

  • Администраторы команд — администраторы пространств имен (через RoleBinding на стандартную ClusterRole admin).

  • Тестировщики - имеют доступ только на чтение в рамках пространства имен (через ClusterRole view).

  • Разработчики - имеют доступ к управлению рабочими нагрузками и конфигурацией в рамках пространства имен, но не являются администраторами (через пользовательскую ClusterRole team-developer).

Привязка просмотра проектов и пространств имен#

Настройте каждому пользователю роль на просмотр проектов и пространств имен на уровне кластера. Пользователь сможет просматривать только те пространства имен, к которым у него есть доступ. В кластере DropApp есть роли projects-viewer и namespace-list:

project-namespace-viewer-crb
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: projects-viewer-crb
subjects:
- kind: Group
  name: team-a-admins
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: team-b-admins
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: team-c-admins
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: team-a-developers
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: team-b-developers
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: team-c-developers
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: team-a-testers
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: team-b-testers
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: team-c-testers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: projects-viewer
  apiGroup: rbac.authorization.k8s.io
---
# RoleBinding (не ClusterRoleBinding!) для просмотра пространств имен team-a
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-a-ns-viewer
  namespace: team-a
subjects:
- kind: Group
  name: team-a-admins
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: team-a-developers
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: team-a-testers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: namespace-list
  apiGroup: rbac.authorization.k8s.io
---
# RoleBinding (не ClusterRoleBinding!) для просмотра пространств имен team-b
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-b-ns-viewer
  namespace: team-b
subjects:
- kind: Group
  name: team-b-admins
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: team-b-developers
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: team-b-testers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: namespace-list
  apiGroup: rbac.authorization.k8s.io
---
# RoleBinding (не ClusterRoleBinding!) для просмотра пространств имен team-c
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-a-ns-viewer
  namespace: team-c
subjects:
- kind: Group
  name: team-c-admins
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: team-c-developers
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: team-c-testers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: namespace-list
  apiGroup: rbac.authorization.k8s.io

Создание кластерной роли для разработчиков#

Для создания общей кластерной роли team-developer, которая будет применяться ко всем командам через RoleBinding выполните шаги:

  1. Создайте файл настроек:

    rbac-clusterrole-team-developer.yaml
    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: team-developer
rules:
  - apiGroups: ["apps"]
    resources:
      - deployments
      - statefulsets
      - daemonsets
      - replicasets
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

  - apiGroups: ["batch"]
    resources:
      - jobs
      - cronjobs
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

  # Базовые ресурсы и конфигурация
  - apiGroups: [""]
    resources:
      - pods
      - pods/log
      - services
      - configmaps
      - secrets
      - endpoints
      - persistentvolumeclaims
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

  # Диагностика
  - apiGroups: [""]
    resources:
      - events
    verbs: ["get", "list", "watch"]

  # Только чтение serviceaccounts (чтобы не выдавать себе повышенные права)
  - apiGroups: [""]
    resources:
      - serviceaccounts
    verbs: ["get", "list", "watch"]

  2. Примените настройку от имени пользователя с правами cluster-admin:

    kubectl apply -f rbac-clusterrole-team-developer.yaml

Назначение администраторов пространств имен#

Администраторы команд должны иметь полный контроль в пределах своего пространства имен, но не быть cluster-admin:

  1. Используя стандартную ClusterRole admin создайте RoleBinding для каждого пространства имен:

    Пример для team-a:

    rbac-team-a-admins-rolebinding.yaml
    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ns-admins
  namespace: team-a
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
  - kind: Group
    apiGroup: rbac.authorization.k8s.io
    name: team-a-admins

    Пример для team-b:

    rbac-team-b-admins-rolebinding.yaml
    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ns-admins
  namespace: team-b
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
  - kind: Group
    apiGroup: rbac.authorization.k8s.io
    name: team-b-admins
---

    Пример для team-c:

    rbac-team-c-admins-rolebinding.yaml
    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ns-admins
  namespace: team-c
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
  - kind: Group
    apiGroup: rbac.authorization.k8s.io
    name: team-c-admins

  2. Примените настройки:

    kubectl apply -f rbac-team-a-admins-rolebinding.yaml

    kubectl apply -f rbac-team-b-admins-rolebinding.yaml

    kubectl apply -f rbac-team-c-admins-rolebinding.yaml

Назначение прав view для тестировщиков#

Тестировщики должны иметь доступ только на чтение в рамках пространства имен. Для этого используйте стандартную ClusterRole view:

  1. Создайте единый файл конфигурации RoleBinding для трех пространств имен:

    rbac-testers-rolebindings.yaml
    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ns-testers-view
  namespace: team-a
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
  - kind: Group
    apiGroup: rbac.authorization.k8s.io
    name: team-a-testers
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ns-testers-view
  namespace: team-b
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
  - kind: Group
    apiGroup: rbac.authorization.k8s.io
    name: team-b-testers
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ns-testers-view
  namespace: team-c
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
  - kind: Group
    apiGroup: rbac.authorization.k8s.io
    name: team-c-testers

  2. Примените конфигурацию:

    kubectl apply -f rbac-testers-rolebindings.yaml

Назначение прав team-developer для разработчиков#

Разработчики должны иметь права на работу с рабочими нагрузками и конфигурацией, но без административных возможностей и без прав изменять RBAC или настройки на уровне пространства имен:

  1. Создайте RoleBinding в каждом пространстве имен, привязывающий кластерную роль team-developer к группе разработчиков команды:

    rbac-developers-rolebindings.yaml
    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ns-developers
  namespace: team-a
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: team-developer
subjects:
  - kind: Group
    apiGroup: rbac.authorization.k8s.io
    name: team-a-developers
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ns-developers
  namespace: team-b
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: team-developer
subjects:
  - kind: Group
    apiGroup: rbac.authorization.k8s.io
    name: team-b-developers
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ns-developers
  namespace: team-c
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: team-developer
subjects:
  - kind: Group
    apiGroup: rbac.authorization.k8s.io
    name: team-c-developers

  2. Примените конфигурацию:

    kubectl apply -f rbac-developers-rolebindings.yaml

Заключение#

Использование стандартных ролей (admin, view) в сочетании с пользовательской кластерной ролью team-developer позволяет обеспечить понятную ролевую модель:

  • администраторы управляют пространством имен;

  • разработчики управляют рабочими нагрузками и конфигурацией;

  • тестировщики наблюдают за состоянием системы.

Такой подход легко масштабируется на новые команды и окружения (dev/stage/prod), подходит для реализации через компонент GitOps и упрощает аудит: все права заданы декларативно, прозрачно и воспроизводимо.

При необходимости модель можно расширять — добавлять новые роли, уточнять набор разрешений, вводить дополнительные группы — не меняя общую архитектуру решения.