Для улучшения работы сайта мы используем файлы cookies. Оставаясь на сайте, вы соглашаетесь с политикой обработки персональных данных.

Реализация модели доступа на основе ролей в Nova на основе групп LDAP

Данный сценарий описывает реализацию политики доступа на основе ролей в Nova Container Platform для доступа к ресурсам kubernetes в воображаемом процессе разработки приложения. Для этого проектируется и реализуется ряд уровней доступа, соответствующих различных ролям в команде разработки.

В Nova уже имеются средства для настройки аутентификации и авторизации в режиме единого окна. Задача реализации матрицы доступа сводится к подключению провайдера аутентификации и конфигурации соответствующих ролей внутри kubernetes и StarVault. В примере используется LDAP в качестве провайдера аутентификации.

1. Проектирование модели доступа на основе ролей

В примере предполагается наличие ролей QA, DevOps, разработчиков, технических менеджеров, служебных учетных записей конвейера разработки и администраторов кластера.

Атрибутирование ролей пользователям осуществляется с помощью групп Active Directory или другого LDAP-каталога.

Ниже представлена таблица соответствия ролей воображаемой модели доступа ролям Kubernetes.

Роль в модели Описание Соответствие кластерным ролям Kubernetes в каждом пространстве имён Соответствие кластерным ролям в масштабе кластера Группа в LDAP-каталоге

QA

Получать список и содержимое объектов, журналы контейнеров, но не секреты.

view

view

auth-demo-qa-users + auth-demo-project-users

DevOps

Изменять и удалять объекты, кроме ресурсных квот.

admin

view

auth-demo-devops-users + auth-demo-project-users

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

Изменять объекты, кроме секретов.

edit

view

auth-demo-dev-users + auth-demo-project-users

Технические менеджеры

Дополнительно к правам DevOps: изменять ресурсные квоты, создавать и удалять.

admin + tech-man (дополнительная роль)

view

auth-demo-owner-users + auth-demo-project-users

Служебные учетные записи

Дополнительно к правам технических менеджеров: создавать CRD.

admin + tech-man (дополнительная роль)

view + ci-job (дополнительная роль)

отсутствует, создаются служебные учетные записи kubernetes + auth-demo-project-users

Администраторы кластера

Полный доступ, распределение квот, сетевых политик и политик доступа.

cluster-admin

auth-demo-sre

Особенности использования встроенных ролей на разных уровнях пространства имен и кластера:

  1. роль view на кластерном уровне используется, чтобы избежать ошибок непредвиденных ошибок доступа, мешающих осуществлять навигацию внутри веб-консоли или получать базовые списки с помощью утилиты kubectl;

  2. использования кластерных ролей в пространстве имен требует создания объекта RoleBinding, а на уровне кластера - ClusterRoleBinding;

  3. в данном примере для простоты конфигурации используются только кластерные роли ClusterRole, подробнее о средствах реализации доступа на основе ролей можно ознакомиться в разделе Использование RBAC для разграничения доступа в Kubernetes.

2. Создание групп в LDAP-каталоге

Создайте группы в LDAP-каталоге и внесите в них соответствующих пользователей. Ниже представлен шаблон таблицы для создания групп, заполненный данными для примера сценария.

Группа Группа в LDAP Члены группы

Администраторы кластера

auth-demo-sre

ivan-petrov

Члены вымышленной проектной группы

auth-demo-project-users

auth-demo-qa-user, auth-demo-devops-user, auth-demo-dev-user, auth-demo-owner-user

QA-инженеры проекты

auth-demo-qa-users

auth-demo-qa-user

DevOps-инженеры проекта

auth-demo-devops-users

auth-demo-devops-user

Технический менеджер проекта

auth-demo-owner-users

auth-demo-owner-user

3. Конфигурация метода аутентификации

Выполните действия, согласно инструкции.

4. Создание сервисной учетной записи

В целях демонстрации в данном примере используется вымышленная сервисная учетная запись. Чтобы ее использовать, создайте следующий объект в kubernetes.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: ci-service-account
  namespace: auth-demo-namespace

О получении реквизитов доступа этой учетной записи можно подробнее ознакомиться в статье базы знаний "Создание учетной записи для не интерактивного доступа".

5. Конфигурация модели RBAC в kubernetes

В данном примере используется имя auth-demo-namespace. Перед началом работы замените имена auth-demo-namespace, а также наименования групп на соответствующие вашему сценарию

  1. Выдайте права администраторам кластера. Для этого создайте следующий объект в kubernetes:

    • ClusterRoleBinding для администраторов кластера.

      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRoleBinding
      metadata:
        name: cluster-admin-binding
      roleRef:
        name: cluster-admin
        kind: ClusterRole
      subjects:
      - kind: Group
        name: auth-demo-sre
        apiGroup: rbac.authorization.k8s.io

      В дополнение ко встроенным кластерным ролям в данной модели используются специфичные для сценария роли. Поэтому в начале процесса конфигурации kubernetes необходимо создать эти роли. Для этого создайте следующие объекты в kubernetes:

    • ClusterRole для технических менеджеров.

      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRole
      metadata:
        name: tech-man
      rules:
        - apiGroups: [""]
          resources: ["resourcequotas", "resourcequotas/status"]
          verbs: ["create", "get", "list", "watch", "update", "delete"]
    • ClusterRole для служебных учетных записей.

      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRole
      metadata:
        name: ci-job
      rules:
        - apiGroups: ["apiextensions.k8s.io"]
          resources: ["customresourcedefinitions"]
          verbs: ["create", "get", "list", "watch", "update"]
  2. Сопоставьте созданные роли группам в конкретных пространствах имён:

    • RoleBinding для QA в пространстве имен auth-demo-namespace.

      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
        name: qa-view-binding
        namespace: auth-demo-namespace
      roleRef:
        name: view
        kind: ClusterRole
      subjects:
      - kind: Group
        name: auth-demo-qa-users
        apiGroup: rbac.authorization.k8s.io
    • RoleBinding для DevOps в пространстве имен auth-demo-namespace.

      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
        name: devops-admin-binding
        namespace: auth-demo-namespace
      roleRef:
        name: admin
        kind: ClusterRole
      subjects:
      - kind: Group
        name: auth-demo-devops-users
        apiGroup: rbac.authorization.k8s.io
    • RoleBinding для разработчиков в пространстве имен auth-demo-namespace.

      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
        name: dev-edit-binding
        namespace: auth-demo-namespace
      roleRef:
        name: edit
        kind: ClusterRole
      subjects:
      - kind: Group
        name: auth-demo-dev-users
        apiGroup: rbac.authorization.k8s.io
    • RoleBinding для технических менеджеров в пространстве имен auth-demo-namespace.

      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
        name: tech-man-admin-binding
        namespace: auth-demo-namespace
      roleRef:
        name: admin
        kind: ClusterRole
      subjects:
      - kind: Group
        name: auth-demo-owner-users
        apiGroup: rbac.authorization.k8s.io
    • RoleBinding для служебной учетной записи в пространстве имен auth-demo-namespace.

      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
        name: ci-admin-binding
        namespace: auth-demo-namespace
      roleRef:
        name: admin
        kind: ClusterRole
      subjects:
      - kind: ServiceAccount
        name: ci-service-account
        namespace: auth-demo-namespace
    • RoleBinding для технических менеджеров в пространстве имен auth-demo-namespace.

      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
        name: tech-man-quota-binding
        namespace: auth-demo-namespace
      roleRef:
        name: tech-man
        kind: ClusterRole
      subjects:
      - kind: Group
        name: auth-demo-owner-users
        apiGroup: rbac.authorization.k8s.io
  3. Выдайте права на уровне кластера:

    • ClusterRoleBinding для QA на уровне кластера.

      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRoleBinding
      metadata:
        name: auth-demo-view-cluster-binding
      roleRef:
        name: view
        kind: ClusterRole
      subjects:
      - kind: Group
        name: auth-demo-project-users
        apiGroup: rbac.authorization.k8s.io
    • ClusterRoleBinding для служебных учетных записей на уровне кластера.

      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRoleBinding
      metadata:
        name: ci-job-cluster-binding
      roleRef:
        name: ci-job
        kind: ClusterRole
      subjects:
      - kind: ServiceAccount
        name: ci-service-account
        namespace: auth-demo-namespace