Как создать пользователя?

Создание пользователя.

Как ограничить права пользователю конкретными пространствами имён?

Чтобы ограничить права пользователя конкретными пространствами имён в экспериментальной ролевой модели, используйте в RoleBinding use-роль с соответствующим уровнем доступа. Пример….

В текущей ролевой модули используйте параметры namespaceSelector или limitNamespaces (устарел) в кастомном ресурсе ClusterAuthorizationRule.

Что, если два ClusterAuthorizationRules подходят для одного пользователя?

В примере пользователь jane.doe@example.com состоит в группе administrators. Созданы два ClusterAuthorizationRules:

1apiVersion: deckhouse.io/v1
2kind: ClusterAuthorizationRule
3metadata:
4  name: jane
5spec:
6  subjects:
7    - kind: User
8      name: jane.doe@example.com
9  accessLevel: User
10  namespaceSelector:
11    labelSelector:
12      matchLabels:
13        env: review
14---
15apiVersion: deckhouse.io/v1
16kind: ClusterAuthorizationRule
17metadata:
18  name: admin
19spec:
20  subjects:
21  - kind: Group
22    name: administrators
23  accessLevel: ClusterAdmin
24  namespaceSelector:
25    labelSelector:
26      matchExpressions:
27      - key: env
28        operator: In
29        values:
30        - prod
31        - stage
  1. jane.doe@example.com имеет право запрашивать и просматривать объекты среди всех пространств имён, помеченных env=review.
  2. Administrators могут запрашивать, редактировать, получать и удалять объекты на уровне кластера и из пространств имён, помеченных env=prod и env=stage.

Так как для Jane Doe подходят два правила, необходимо провести вычисления:

  • Jane Doe будет иметь самый сильный accessLevel среди всех подходящих правил — ClusterAdmin.
  • Опции namespaceSelector будут объединены так, что Jane Doe будет иметь доступ в пространства имён, помеченные меткой env со значением review, stage или prod.

Если есть правило без опции namespaceSelector и без опции limitNamespaces (устаревшая), это значит, что доступ разрешён во все пространства имён, кроме системных, что повлияет на результат вычисления доступных пространств имён для пользователя.

Как расширить роли или создать новую?

Экспериментальная ролевая модель построена на принципе агрегации, она собирает более мелкие роли в более обширные, тем самым предоставляя лёгкие способы расширения модели собственными ролями.

Создание новой роли подсистемы

Предположим, что текущие подсистемы не подходят под ролевое распределение в компании и требуется создать новую подсистему, которая будет включать в себя роли из подсистемы deckhouse, подсистемы kubernetes и модуля user-authn.

Для решения этой задачи создайте следующую роль:

1apiVersion: rbac.authorization.k8s.io/v1
2kind: ClusterRole
3metadata:
4  name: custom:manage:mycustom:manager
5  labels:
6    rbac.deckhouse.io/use-role: admin
7    rbac.deckhouse.io/kind: manage
8    rbac.deckhouse.io/level: subsystem
9    rbac.deckhouse.io/subsystem: custom
10    rbac.deckhouse.io/aggregate-to-all-as: manager
11aggregationRule:
12  clusterRoleSelectors:
13    - matchLabels:
14        rbac.deckhouse.io/kind: manage
15        rbac.deckhouse.io/aggregate-to-deckhouse-as: manager
16    - matchLabels:
17        rbac.deckhouse.io/kind: manage
18        rbac.deckhouse.io/aggregate-to-kubernetes-as: manager
19    - matchLabels:
20        rbac.deckhouse.io/kind: manage
21        module: user-authn
22rules: []

В начале указаны лейблы для новой роли:

  • показывает, какую роль хук должен использовать при создании use ролей:

    1rbac.deckhouse.io/use-role: admin

  • показывает, что роль должна обрабатываться как manage-роль:

    1rbac.deckhouse.io/kind: manage

    Этот лейбл обязателен.

  • показывает, что роль является ролью подсистемы, и обрабатываться будет соответственно:

    1rbac.deckhouse.io/level: subsystem

  • указывает подсистему, за которую отвечает роль:

    1rbac.deckhouse.io/subsystem: custom

  • позволяет manage:all-роли агрегировать эту роль в себя:

    1rbac.deckhouse.io/aggregate-to-all-as: manager

Далее указаны селекторы, именно они реализуют агрегацию:

  • агрегирует роль менеджера из подсистемы deckhouse:

    1rbac.deckhouse.io/kind: manage
2rbac.deckhouse.io/aggregate-to-deckhouse-as: manager

  • агрегирует все правила от модуля user-authn:

    1 rbac.deckhouse.io/kind: manage
2 module: user-authn

Таким образом роль получает права от подсистем deckhouse, kubernetes и от модуля user-authn.

Особенности:

  • ограничений на имя роли нет, но для читаемости лучше использовать этот стиль;
  • use-роли будут созданы в пространстве имён агрегированных подсистем и модуля, тип роли выбран лейблом.

Расширение пользовательской роли

Например, в кластере появился новый кластерный (пример для manage-роли) CRD-объект — MySuperResource, и нужно дополнить собственную роль из примера выше правами на взаимодействие с этим ресурсом.

Первым делом нужно дополнить роль новым селектором:

1rbac.deckhouse.io/kind: manage
2rbac.deckhouse.io/aggregate-to-custom-as: manager

Этот селектор позволит агрегировать роли к новой подсистеме через указание этого лейбла. После добавления нового селектора роль будет выглядеть так:

1 apiVersion: rbac.authorization.k8s.io/v1
2 kind: ClusterRole
3 metadata:
4   name: custom:manage:mycustom:manager
5   labels:
6     rbac.deckhouse.io/use-role: admin
7     rbac.deckhouse.io/kind: manage
8     rbac.deckhouse.io/level: subsystem
9     rbac.deckhouse.io/subsystem: custom
10     rbac.deckhouse.io/aggregate-to-all-as: manager
11 aggregationRule:
12   clusterRoleSelectors:
13     - matchLabels:
14         rbac.deckhouse.io/kind: manage
15         rbac.deckhouse.io/aggregate-to-deckhouse-as: manager
16     - matchLabels:
17         rbac.deckhouse.io/kind: manage
18         rbac.deckhouse.io/aggregate-to-kubernetes-as: manager
19     - matchLabels:
20         rbac.deckhouse.io/kind: manage
21         module: user-authn
22     - matchLabels:
23         rbac.deckhouse.io/kind: manage
24         rbac.deckhouse.io/aggregate-to-custom-as: manager
25 rules: []

Далее нужно создать новую роль, в которой следует определить права для нового ресурса. Например, только чтение:

1 apiVersion: rbac.authorization.k8s.io/v1
2 kind: ClusterRole
3 metadata:
4   labels:
5     rbac.deckhouse.io/aggregate-to-custom-as: manager
6     rbac.deckhouse.io/kind: manage
7   name: custom:manage:permission:mycustom:superresource:view
8 rules:
9 - apiGroups:
10   - mygroup.io
11   resources:
12   - mysuperresources
13   verbs:
14   - get
15   - list
16   - watch

Роль дополнит своими правами роль подсистемы, дав права на просмотр нового объекта.

Особенности:

  • ограничений на имя роли нет, но для читаемости лучше использовать этот стиль.

Расширение существующих manage subsystem-ролей

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

Пример для расширения роли менеджера из подсистемы deckhouse(d8:manage:deckhouse:manager):

1apiVersion: rbac.authorization.k8s.io/v1
2kind: ClusterRole
3metadata:
4  labels:
5    rbac.deckhouse.io/aggregate-to-deckhouse-as: manager
6    rbac.deckhouse.io/kind: manage
7  name: custom:manage:permission:mycustommodule:superresource:view
8rules:
9- apiGroups:
10  - mygroup.io
11  resources:
12  - mysuperresources
13  verbs:
14  - get
15  - list
16  - watch

Таким образом новая роль расширит роль d8:manage:deckhouse.

Расширение manage subsystem-ролей с добавлением нового пространства имён

Если необходимо добавить новое пространство имён (для создания в нём use-роли с помощью хука), потребуется добавить лишь один лейбл:

1"rbac.deckhouse.io/namespace": namespace

Этот лейбл сообщает хуку, что в этом пространстве имён нужно создать use-роль:

1 apiVersion: rbac.authorization.k8s.io/v1
2 kind: ClusterRole
3 metadata:
4   labels:
5     rbac.deckhouse.io/aggregate-to-deckhouse-as: manager
6     rbac.deckhouse.io/kind: manage
7     rbac.deckhouse.io/namespace: namespace
8   name: custom:manage:permission:mycustom:superresource:view
9 rules:
10 - apiGroups:
11   - mygroup.io
12   resources:
13   - mysuperresources
14   verbs:
15   - get
16   - list
17   - watch

Хук мониторит ClusterRoleBinding и при создании биндинга ходит по всем manage-ролям, чтобы найти все объединенные в них роли с помощью проверки правила агрегации. Затем он берёт пространство имён из лейбла rbac.deckhouse.io/namespace и создает use-роль в этом пространстве имён.

Расширение существующих use-ролей

Если ресурс принадлежит пространству имён, необходимо расширить use-роль вместо manage-роли. Разница лишь в лейблах и имени:

1 apiVersion: rbac.authorization.k8s.io/v1
2 kind: ClusterRole
3 metadata:
4   labels:
5     rbac.deckhouse.io/aggregate-to-kubernetes-as: user
6     rbac.deckhouse.io/kind: use
7   name: custom:use:capability:mycustom:superresource:view
8 rules:
9 - apiGroups:
10   - mygroup.io
11   resources:
12   - mysuperresources
13   verbs:
14   - get
15   - list
16   - watch

Эта роль дополнит роль d8:use:role:user:kubernetes.