Для реализации текущей ролевой модели в кластере должен быть включён модуль user-authz
.
Модуль создаёт набор кластерных ролей (ClusterRole), подходящий для большинства задач по управлению доступом пользователей и групп.
С версии Deckhouse Kubernetes Platform v1.64 в модуле реализована экспериментальная модель ролевого доступа. Текущая модель ролевого доступа продолжит работать, но в будущем будет объявлена устаревшей (deprecated).
Функциональности экспериментальной и текущей моделей ролевого доступа несовместимы. Автоматическая конвертация ресурсов невозможна.
Особенности текущей ролевой модели:
- Реализует role-based-подсистему сквозной авторизации, расширяя функционал стандартного механизма RBAC.
- Настройка прав доступа происходит с помощью кастомных ресурсов ClusterAuthorizationRule и AuthorizationRule.
- Управление доступом к инструментам масштабирования (параметр
allowScale
ресурса ClusterAuthorizationRule или AuthorizationRule). - Управление доступом к форвардингу портов (параметр
portForwarding
ресурса ClusterAuthorizationRule или AuthorizationRule). - Управление списком разрешённых пространств имён в формате labelSelector (параметр
namespaceSelector
ресурса ClusterAuthorizationRule).
Высокоуровневые роли, используемые для реализации модели
Для реализации текущей ролевой модели с помощью модуля user-authz
, кроме использования RBAC, можно использовать удобный набор высокоуровневых ролей:
Роль | Примеры доступных действий | Ограничения |
---|---|---|
User | Просмотр подов, логов, Deployment | Нет доступа к секретам, портам, контейнерам |
PrivilegedUser | Вход в контейнеры (kubectl exec ), чтение секретов, удаление подов |
Не может изменять Deployment/Service |
Editor | Создание/удаление Deployment, Service, ConfigMap | Нет доступа к ReplicaSet, ClusterRoles |
Admin | Удаление ReplicaSet, управление RBAC в пространстве имён | Нет доступа к ресурсам на уровне кластера |
ClusterEditor | Создание DaemonSet, ClusterRole, ClusterXXXMetric, KeepalivedInstance (только тех, что могут понадобиться для прикладных задач) | Не может удалять MachineSets |
ClusterAdmin | Полный доступ к ClusterRoleBindings, Machines, OpenstackInstanceClasses | Может повысить свои права |
SuperAdmin | Любые действия (включая * в RBAC), но с учетом limitNamespaces |
Ограничения только через политики кластера |
Режим multitenancy (авторизация по пространству имён) в данный момент реализован по временной схеме и не гарантирует безопасность.
В случае, если в ресурсе ClusterAuthorizationRule используется namespaceSelector
, параметры limitNamespaces
и allowAccessToSystemNamespace
не учитываются.
Если вебхук, который реализовывает систему авторизации, по какой-то причине будет недоступен, опции allowAccessToSystemNamespaces
, namespaceSelector
и limitNamespaces
в кастомных ресурсах перестанут применяться и пользователи будут иметь доступ во все пространства имён. После восстановления доступности вебхука опции продолжат работать.
Список доступа для каждой высокоуровневой роли по умолчанию
Сокращения для verbs
:
- read —
get
,list
,watch
; - read-write —
get
,list
,watch
,create
,delete
,deletecollection
,patch
,update
; - write —
create
,delete
,deletecollection
,patch
,update
.
Роль User
:
read:
- apiextensions.k8s.io/customresourcedefinitions
- apps/daemonsets
- apps/deployments
- apps/replicasets
- apps/statefulsets
- autoscaling.k8s.io/verticalpodautoscalers
- autoscaling/horizontalpodautoscalers
- batch/cronjobs
- batch/jobs
- configmaps
- discovery.k8s.io/endpointslices
- endpoints
- events
- events.k8s.io/events
- extensions/daemonsets
- extensions/deployments
- extensions/ingresses
- extensions/replicasets
- extensions/replicationcontrollers
- limitranges
- metrics.k8s.io/nodes
- metrics.k8s.io/pods
- namespaces
- networking.k8s.io/ingresses
- networking.k8s.io/networkpolicies
- nodes
- persistentvolumeclaims
- persistentvolumes
- pods
- pods/log
- policy/poddisruptionbudgets
- rbac.authorization.k8s.io/rolebindings
- rbac.authorization.k8s.io/roles
- replicationcontrollers
- resourcequotas
- serviceaccounts
- services
- storage.k8s.io/storageclasses
Роль PrivilegedUser
(включает все правила из роли User
):
create:
- pods/eviction
create,get:
- pods/attach
- pods/exec
delete,deletecollection:
- pods
read:
- secrets
Роль Editor
(включает все правила из роли User
, PrivilegedUser
):
read-write:
- apps/deployments
- apps/statefulsets
- autoscaling.k8s.io/verticalpodautoscalers
- autoscaling/horizontalpodautoscalers
- batch/cronjobs
- batch/jobs
- configmaps
- discovery.k8s.io/endpointslices
- endpoints
- extensions/deployments
- extensions/ingresses
- networking.k8s.io/ingresses
- persistentvolumeclaims
- policy/poddisruptionbudgets
- serviceaccounts
- services
write:
- secrets
Роль Admin
(включает все правила из роли User
, PrivilegedUser
, Editor
):
create,patch,update:
- pods
delete,deletecollection:
- apps/replicasets
- extensions/replicasets
Роль ClusterEditor
(включает все правила из роли User
, PrivilegedUser
, Editor
):
read:
- rbac.authorization.k8s.io/clusterrolebindings
- rbac.authorization.k8s.io/clusterroles
write:
- apiextensions.k8s.io/customresourcedefinitions
- apps/daemonsets
- extensions/daemonsets
- storage.k8s.io/storageclasses
Роль ClusterAdmin
(включает все правила из роли User
, PrivilegedUser
, Editor
, Admin
, ClusterEditor
):
read-write:
- deckhouse.io/clusterauthorizationrules
write:
- limitranges
- namespaces
- networking.k8s.io/networkpolicies
- rbac.authorization.k8s.io/clusterrolebindings
- rbac.authorization.k8s.io/clusterroles
- rbac.authorization.k8s.io/rolebindings
- rbac.authorization.k8s.io/roles
- resourcequotas
Вы можете получить дополнительный список правил доступа для роли модуля из кластера (существующие пользовательские правила и нестандартные правила из других модулей Deckhouse) с помощью команды:
D8_ROLE_NAME=Editor
d8 k get clusterrole -A -o jsonpath="{range .items[?(@.metadata.annotations.user-authz\.deckhouse\.io/access-level=='$D8_ROLE_NAME')]}{.rules}{'\n'}{end}" | jq -s add
Пример AuthorizationRule
Используйте AuthorizationRule для установки правил доступа для пользователей внутри определённого пространства имен.
apiVersion: deckhouse.io/v1alpha1
kind: AuthorizationRule
metadata:
name: beeline
spec:
accessLevel: Admin
subjects:
- kind: Admin
name: admin@example.com
Пример ClusterAuthorizationRule
ClusterAuthorizationRule можно использовать для установки правил доступа для пользователей как на уровне всего кластера, так и на уровне определенных пространств имен.
apiVersion: deckhouse.io/v1
kind: ClusterAuthorizationRule
metadata:
name: test-rule
spec:
subjects:
- kind: User
name: some@example.com
- kind: ServiceAccount
name: gitlab-runner-deploy
namespace: d8-service-accounts
- kind: Group
name: some-group-name
accessLevel: PrivilegedUser
portForwarding: true
# Опция доступна только при включенном режиме enableMultiTenancy (версия Enterprise Edition).
allowAccessToSystemNamespaces: false
# Опция доступна только при включенном режиме enableMultiTenancy (версия Enterprise Edition).
namespaceSelector:
labelSelector:
matchExpressions:
- key: stage
operator: In
values:
- test
- review
matchLabels:
team: frontend
Расширение прав доступа для высокоуровневых ролей
Если требуется добавить права для определённой высокоуровневой роли, создайте ClusterRole с аннотацией user-authz.deckhouse.io/access-level: <AccessLevel>
.
Пример:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
annotations:
user-authz.deckhouse.io/access-level: Editor
name: user-editor
rules:
- apiGroups:
- kuma.io
resources:
- trafficroutes
- trafficroutes/finalizers
verbs:
- get
- list
- watch
- create
- update
- patch
- delete
- apiGroups:
- flagger.app
resources:
- canaries
- canaries/status
- metrictemplates
- metrictemplates/status
- alertproviders
- alertproviders/status
verbs:
- get
- list
- watch
- create
- update
- patch
- delete