Модуль user-authz

Модуль отвечает за генерацию объектов ролевой модели доступа, основанной на базе стандартного механизма RBAC Kubernetes. Модуль создает набор кластерных ролей (ClusterRole), подходящий для большинства задач по управлению доступом пользователей и групп.

Биндинги, которые выдают пользователям уровни доступа из ClusterAuthorizationRule и AuthorizationRule, поддерживает компонент user-authz-controller: он следит за правилами, синхронизирует их ClusterRoleBinding и RoleBinding и записывает результат в status каждого правила (d8 k get clusterauthorizationrules показывает колонки READY и BINDINGS). Правило с неподдерживаемым accessLevel получает Ready=False с причиной InvalidSpec, а не ломает модуль. Контроллер отдаёт метрики: сколько правил он видит, какие биндинги для них нужны, какие есть на самом деле и где между этим расхождение, а модуль поставляет алерты о недоступности контроллера, устойчивом расхождении и правилах, биндинги которых не применяются (подробнее — в FAQ).

Гранулярная ролевая модель

В отличие от упрощённой ролевой модели DP, гранулярная ролевая модель не использует ресурсы ClusterAuthorizationRule и AuthorizationRule. Права доступа настраиваются стандартным для RBAC Kubernetes способом: с помощью создания ресурсов RoleBinding или ClusterRoleBinding, с указанием в них одной из подготовленных модулем user-authz ролей. Для доступа сразу ко всем неймспейсам проекта дополнительно используются ресурсы ProjectRoleBinding и ClusterProjectRoleBinding модуля multitenancy-manager.

Модуль создаёт специальные агрегированные кластерные роли (ClusterRole). Используя эти роли в RoleBinding или ClusterRoleBinding можно решать следующие задачи:

• Управлять доступом к модулям определённой подсистемы применения.

  Например, чтобы дать возможность пользователю, выполняющему функции сетевого администратора, настраивать сетевые модули (например, cni-cilium, ingress-nginx, istio и т. д.), можно использовать в ClusterRoleBinding роль d8:subsystem:networking:manager.

• Управлять доступом к пользовательским ресурсам модулей в рамках неймспейсов.

  Например, использование роли d8:namespace:manager в RoleBinding, позволит удалять/создавать/редактировать ресурс PodLoggingConfig в неймспейсе, но не даст доступа к cluster-wide-ресурсам ClusterLoggingConfig и ClusterLogDestination модуля log-shipper, а также не даст возможность настраивать сам модуль log-shipper.

Области действия ролей

Каждая роль действует в одной из четырёх областей. Область определяет, где работают выданные права и каким ресурсом роль назначается:

Роли, создаваемые модулем, делятся на следующие классы:

• Namespace-роли — для назначения прав пользователям (например, разработчикам приложений) в конкретном неймспейсе.
• Проектные роли — для назначения прав сразу во всех неймспейсах проекта.
• Системные и подсистемные роли — для назначения прав администраторам платформы и администраторам части платформы.

Уровни доступа

В каждой области действия для ролей предусмотрено несколько уровней доступа:

• Для областей «неймспейс» и «проект» уровней пять: viewer → user → manager → admin → superadmin.
• Для областей «подсистема» и «вся платформа» уровней три: viewer → manager → superadmin. Уровней user и admin здесь нет: на системном уровне нет «пользовательских» ресурсов, которыми можно было бы пользоваться, не администрируя их.

Уровни доступа образуют иерархию с кумулятивным принципом: каждый последующий уровень наследует все права предыдущего и расширяет их. Например, уровень manager в области действия «неймспейс» включает набор прав уровня user, который, в свою очередь, включает набор прав уровня viewer.

Совместное использование ClusterAuthorizationRule, AuthorizationRule и RBAC

Если в кластере включён режим мультитенантности (параметр enableMultiTenancy: true), итоговые права пользователя представляют собой объединение прав, полученных из всех следующих источников:

• права из ClusterAuthorizationRule — применяются только внутри неймспейсов, разрешённых параметрами limitNamespaces или namespaceSelector;
• права из AuthorizationRule — применяются внутри неймспейса, в котором создан ресурс AuthorizationRule;
• права из обычных RoleBinding — применяются внутри неймспейса, в котором создан ресурс RoleBinding;
• права из обычных ClusterRoleBinding, не созданных модулем user-authz — применяются во всём кластере.

Ограничения по неймспейсам, заданные в ClusterAuthorizationRule, распространяются только на права, выданные этим ClusterAuthorizationRule. Они не отменяют права, выданные через RoleBinding, ClusterRoleBinding или AuthorizationRule в других неймспейсах. При этом права, предоставляемые ClusterAuthorizationRule, на эти неймспейсы не распространяются.

Например, если у пользователя есть ClusterAuthorizationRule с уровнем доступа accessLevel: Editor, ограниченный неймспейсом ns-a, а также RoleBinding с ролью view в неймспейсе ns-b, то он получит права уровня Editor в неймспейсе ns-a и права только на чтение в неймспейсе ns-b. Права, предоставленные через RoleBinding, не ограничиваются ClusterAuthorizationRule, а уровень доступа Editor, заданный ClusterAuthorizationRule, не распространяется на неймспейс ns-b.

Начиная с DP 1.76.5, RoleBinding и ClusterAuthorizationRule можно использовать совместно для одного пользователя. В более ранних версиях DP вебхук модуля user-authz отклонял все запросы в неймспейсы, не указанные в ClusterAuthorizationRule пользователя, даже при наличии соответствующих ресурсов RoleBinding.

Namespace-роли

Namespace-роли предназначены для назначения прав пользователю в конкретном неймспейсе. Под пользователями понимаются, например, разработчики, которые используют настроенный администратором кластер для развёртывания своих приложений. Таким пользователям не нужно управлять модулями DP или кластером, но им нужно иметь возможность, например, создавать свои Ingress-ресурсы, настраивать аутентификацию приложений и сбор логов с приложений.

Namespace-роль определяет права на доступ к namespaced-ресурсам модулей и стандартным namespaced-ресурсам Kubernetes (Pod, Deployment, Secret, ConfigMap и т. п.).

Модуль создаёт следующие namespace-роли:

• d8:namespace:viewer — позволяет в конкретном неймспейсе просматривать стандартные ресурсы Kubernetes (кроме секретов и ресурсов RBAC), журналы подов и метрики, а также выполнять аутентификацию в кластере;
• d8:namespace:user — дополнительно к роли d8:namespace:viewer позволяет в конкретном неймспейсе просматривать секреты, подключаться к подам (kubectl exec, kubectl attach), удалять поды (но не создавать или изменять их), выполнять kubectl port-forward и kubectl proxy, изменять количество реплик контроллеров;
• d8:namespace:manager — дополнительно к роли d8:namespace:user позволяет в конкретном неймспейсе управлять ресурсами модулей (например, Certificate, PodLoggingConfig и т. п.) и стандартными namespaced-ресурсами Kubernetes (Pod, Deployment, ConfigMap, Secret, Service, Ingress, NetworkPolicy, CronJob и т. п.);
• d8:namespace:admin — дополнительно к роли d8:namespace:manager позволяет в конкретном неймспейсе управлять ресурсами ResourceQuota, LimitRange, ServiceAccount, Role, RoleBinding;
• d8:namespace:superadmin — дополнительно к роли d8:namespace:admin позволяет выполнять опасные с точки зрения безопасности операции: выпускать токены ServiceAccount’ов и выполнять запросы от их имени, а также управлять системными ресурсами, размещёнными в неймспейсе (например, подами Dex или подами/PVC виртуальных машин).

Подробное разделение прав между admin и superadmin описано в разделе «Ограничения уровня admin и права superadmin».

Автоматический доступ к справочным cluster-wide-ресурсам

Работа в неймспейсе требует чтения некоторых cluster-wide-«справочников»: например, чтобы указать в манифесте storageClassName или ingressClassName, нужно видеть список StorageClass’ов и IngressClass’ов. Поэтому каждый субъект, получивший RoleBinding на любую роль d8:namespace:*, автоматически получает и доступ на чтение таких справочных ресурсов (StorageClass, IngressClass, PriorityClass, RuntimeClass, VolumeSnapshotClass, ClusterLogDestination и т. п.).

Технически это выглядит как автоматически создаваемый ClusterRoleBinding на роль d8:dict с лейблом rbac.deckhouse.io/dict: "true". Такие объекты управляются платформой: они появляются при выдаче первой namespace-привязки субъекту и удаляются, когда у субъекта не остаётся ни одной, — редактировать их вручную не нужно.

Проектные роли

Проектные роли (d8:project:<уровень>) предназначены для работы с проектами — изолированными окружениями, которые могут включать несколько неймспейсов. Уровни те же, что у namespace-ролей: viewer, user, manager, admin, superadmin.

Каждая проектная роль включает все права namespace-роли того же уровня и дополнительно даёт права на управление самим проектом:

• d8:project:viewer — права d8:namespace:viewer плюс просмотр ресурсов ProjectNamespace и ProjectRoleBinding проекта;
• d8:project:manager — права d8:namespace:manager плюс управление дополнительными неймспейсами проекта (ресурсы ProjectNamespace);
• d8:project:admin — права d8:namespace:admin плюс управление доступом к проекту (ресурсы ProjectRoleBinding) и право привязывать встроенные роли d8:project:* и d8:namespace:* (кроме уровня superadmin) другим пользователям в рамках проекта;
• d8:project:superadmin — аналогично соотношению d8:namespace:superadmin и d8:namespace:admin.

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

Системные и подсистемные роли

Системные (d8:system:*) и подсистемные (d8:subsystem:*) роли предназначены для назначения прав на управление всей платформой или её частью (подсистемой), но не самими приложениями пользователей. С помощью подсистемной роли можно, например, дать возможность администратору безопасности управлять модулями, ответственными за функции безопасности кластера. Тогда администратор безопасности сможет настраивать аутентификацию, авторизацию, политики безопасности и т. п., но не сможет управлять остальными функциями кластера (например, настройками сети и мониторинга) и изменять настройки в пространстве имён приложений пользователей.

Системная/подсистемная роль определяет права на доступ:

• к cluster-wide-ресурсам Kubernetes;
• к управлению модулями DP (ресурсы ModuleConfig) в рамках подсистемы роли, или всеми модулями DP для роли d8:system:*;
• к управлению cluster-wide-ресурсами модулей DP в рамках подсистемы роли или всеми ресурсами модулей DP для роли d8:system:*;
• к системным неймспейсам (начинающимся с d8- или kube-), в которых работают модули подсистемы роли, или ко всем системным неймспейсам для роли d8:system:*.

Формат названия системной роли — d8:system:<ACCESS_LEVEL>, подсистемной — d8:subsystem:<SUBSYSTEM>:<ACCESS_LEVEL>, где:

• SUBSYSTEM — подсистема роли (список подсистем);

• ACCESS_LEVEL — уровень доступа.

  Примеры ролей:

  • d8:system:viewer — доступ на просмотр конфигурации всех модулей DP (ресурсы ModuleConfig), их cluster-wide-ресурсов, их namespaced-ресурсов и стандартных объектов Kubernetes (кроме секретов и ресурсов RBAC) во всех системных неймспейсах (начинающихся с d8- или kube-);
  • d8:system:manager — аналогично роли d8:system:viewer, только доступ на уровне admin, т. е. просмотр/создание/изменение/удаление конфигурации всех модулей DP (ресурсы ModuleConfig), их cluster-wide-ресурсов, их namespaced-ресурсов и стандартных объектов Kubernetes во всех системных неймспейсах (начинающихся с d8- или kube-);
  • d8:subsystem:observability:viewer — доступ на просмотр конфигурации модулей DP (ресурсы ModuleConfig) из подсистемы observability, их cluster-wide-ресурсов, их namespaced-ресурсов и стандартных объектов Kubernetes (кроме секретов и ресурсов RBAC) в системных неймспейсах d8-log-shipper, d8-monitoring, d8-okmeter, d8-operator-prometheus, d8-upmeter, kube-prometheus-pushgateway.

Модуль предоставляет три уровня доступа для системных и подсистемных ролей:

• viewer — позволяет просматривать стандартные ресурсы Kubernetes, конфигурацию модулей (ресурсы ModuleConfig), cluster-wide-ресурсы модулей и namespaced-ресурсы модулей в неймспейсе модуля;
• manager — дополнительно к уровню viewer позволяет управлять стандартными ресурсами Kubernetes, конфигурацией модулей (ресурсы ModuleConfig), cluster-wide-ресурсами модулей и namespaced-ресурсами модулей в неймспейсе модуля;
• superadmin — дополнительно к уровню manager позволяет управлять системными ресурсами модулей подсистемы;

Глобальные справочники ресурсов

Помимо ролей и capability гранулярной модели, модуль создаёт специальную ClusterRole d8:dict. Она даёт доступ для чтения кластерных «справочных» ресурсов, которые пользователям часто нужно просматривать при создании объектов. Например, пользователю, создающему PersistentVolumeClaim, нужно видеть доступные StorageClass, а создающему Ingress — IngressClass.

Роль даёт права get, list, watch на следующие ресурсы:

• storageclasses (storage.k8s.io), а также csidrivers, csinodes, volumeattachments;
• volumesnapshotclasses (snapshot.storage.k8s.io);
• ingressclasses (networking.k8s.io);
• priorityclasses (scheduling.k8s.io);
• runtimeclasses (node.k8s.io);
• virtualmachineclasses, clustervirtualimages (virtualization.deckhouse.io);
• clusterlogdestinations (deckhouse.io);
• customresourcedefinitions (apiextensions.k8s.io) — только get, list.

Автоматическая привязка

ClusterRoleBinding для d8:dict создаётся автоматически, когда RoleBinding ссылается на роль d8:namespace:* или d8:project:* (гранулярная модель) или на роль user-authz:* (упрощённая модель). RoleBinding, которые multitenancy-manager создаёт из ProjectRoleBinding и ClusterProjectRoleBinding, тоже учитываются, поэтому привязку получают и держатели проектных ролей. Пользователи system:multitenancy-manager:*, от имени которых действует multitenancy-manager, привязку не получают. Это означает, что пользователи проекта могут просматривать справочные ресурсы без какой-либо ручной настройки. Привязка появляется вместе с RoleBinding и удаляется при его удалении. Привязку создаёт и управляет ею исключительно компонент user-authz-controller модуля. Самостоятельно её создавать не нужно.

Подсистемы ролевой модели

Каждый модуль DP принадлежит определённой подсистеме. Для каждой подсистемы существует набор ролей с разными уровнями доступа. Роли обновляются автоматически при включении или отключении модуля.

Например, для подсистемы networking существуют следующие подсистемные роли, которые можно использовать в ClusterRoleBinding:

• d8:subsystem:networking:viewer;
• d8:subsystem:networking:manager;
• d8:subsystem:networking:superadmin.

Область действия роли зависит от того, к какой подсистеме она принадлежит:

• Область действия ролей d8:system:* — все системные (начинающиеся с d8- или kube-) неймспейсы кластера.
• Область действия ролей подсистем — неймспейсы, в которых работают модули подсистемы (подробнее — в таблице состава подсистем), а также все cluster-wide объекты модулей подсистемы.

Таблица состава подсистем ролевой модели.

Как устроены роли: агрегация и capabilities

Ни одна встроенная роль не содержит списка прав напрямую. Права описываются в отдельных небольших кластерных ролях — capabilities. Каждая capability отвечает за один вид действий (например, «просмотр логов», «управление квотами», «подключение к подам») и содержит конкретные RBAC-правила. Роль (d8:namespace:admin, d8:system:viewer и т. д.) — это пустая ClusterRole с правилом агрегации (aggregationRule): Kubernetes автоматически собирает в неё правила из всех capabilities с подходящими лейблами.

Принадлежность объектов к ролевой модели задаётся лейблами rbac.deckhouse.io/* — например, лейбл rbac.deckhouse.io/aggregate-to-namespace-as: admin включает capability в роль d8:namespace:admin (и, за счёт иерархии уровней, — во все уровни выше). Полный перечень лейблов и аннотаций — в «Справочнике лейблов и аннотаций ролей».

Такое устройство даёт два практических следствия:

• Модули DP расширяют роли автоматически: при включении модуля его capabilities добавляются в соответствующие встроенные роли, при выключении — удаляются. Список прав роли всегда соответствует набору включённых модулей.
• Вы можете собирать собственные роли из готовых capabilities, не описывая RBAC-правила вручную. Как это сделать описано в FAQ.

Имена встроенных ролей и capabilities начинаются с префикса d8:. Это пространство имён зарезервировано: создать собственную ClusterRole с именем d8:* нельзя — исключение составляет только префикс d8:custom:*, выделенный для пользовательских ролей и capabilities. Лейблы rbac.deckhouse.io/kind: role и rbac.deckhouse.io/kind: capability также зарезервированы за встроенными объектами — для собственных используйте custom-role и custom-capability.

Справочник лейблов и аннотаций ролей

Лейблы, которые ролевая модель использует на объектах ClusterRole:

Аннотации на объектах ClusterRole:

Ограничения уровня admin и права superadmin

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

• admin — повседневный администратор. Управляет ресурсами, квотами и доступом в своей области, но не может выполнять операции, которые позволяют выйти за её пределы или нарушить работу компонентов платформы.
• superadmin — «аварийный» администратор. Обладает всеми правами admin и дополнительно может выполнять опасные операции. Выдавайте этот уровень осознанно и только тем, кому он действительно необходим.

Что запрещено уровню admin и разрешено только уровню superadmin:

• Выпуск токенов ServiceAccount’ов (kubectl create token) и выполнение запросов от имени ServiceAccount (kubectl --as system:serviceaccount:...). Токен ServiceAccount’а — это готовая учётная запись: завладев токеном служебного аккаунта платформенного компонента, можно получить его права далеко за пределами неймспейса. Поэтому admin управляет самими объектами ServiceAccount (создание, удаление), но не может выпускать для них токены и действовать от их имени.
• Изменение и удаление системных ресурсов в пользовательских неймспейсах. Некоторые компоненты платформы размещают свои объекты (например, поды Dex-аутентификатора или поды и диски виртуальных машин) прямо в неймспейсах приложений. Такие объекты помечены лейблом deckhouse.io/system-resource: "true". Изменять и удалять их может только superadmin. Для остальных пользователей эти операции отклоняются на уровне API-сервера с пояснением.
• Подключение к системным подам — kubectl exec, kubectl attach и kubectl port-forward в под с лейблом deckhouse.io/system-resource: "true" доступны только superadmin. Это защищает от чтения чужих секретов и вмешательства в работу платформенных компонентов изнутри их подов.

Авторам модулей: маркер — это лейбл deckhouse.io/system-resource: "true" на самом объекте, а не аннотация. Для изменения и удаления объекты для защиты отбираются на стороне API-сервера, в matchConditions admission-конфигурации, а они читают лейблы; для exec, attach и port-forward объектом admission является сам запрос подключения, а не под, поэтому вебхук читает под — и снова его лейблы. В обоих случаях объект, помеченный аннотацией, не будет замечен и останется открыт — без какого-либо сообщения об этом. Поставьте лейбл на каждый объект, который ваш модуль размещает в пользовательских неймспейсах (поды, сервисы, PVC, секреты, кастомные ресурсы), — и менять его смогут только superadmin и администраторы кластера, а exec, attach и port-forward в его поды будут доступны только им.

Перечисленные выше ограничения не действуют на администраторов кластера. Администратором кластера считается тот, кому выдана стандартная роль Kubernetes cluster-admin или роль user-authz:super-admin из прежней ролевой модели (её получают субъекты ClusterAuthorizationRule с уровнем доступа SuperAdmin), а также участники групп system:masters, kubeadm:cluster-admins, superadmins и system:sudousers. Способ выдачи роли значения не имеет: для этого можно использовать и ClusterRoleBinding, и RoleBinding в нужном неймспейсе. У таких пользователей и так есть полные права на кластер, поэтому за ними сохраняется аварийный доступ.

Для superadmin также есть некоторые ограничения:

• Ресурсы, созданные из шаблона проекта (лейбл heritage: multitenancy-manager), не может изменить никто, включая superadmin и администратора кластера, — они управляются исключительно контроллером проектов. Чтобы изменить такой ресурс, измените шаблон проекта или сам проект.
• Роль назначается через RoleBinding и действует только в том неймспейсе, где выдана: superadmin одного неймспейса не получает никаких особых прав в другом.

Встроенные механизмы защиты ролевой модели

Ролевая модель защищена набором проверок на уровне API-сервера. Они не требуют настройки и предотвращают типовые ошибки и попытки повышения привилегий:

• Нельзя выдать ограниченную по области роль на весь кластер. ClusterRoleBinding на роли d8:namespace:*, d8:project:* (и их d8:custom:*-варианты) отклоняется — иначе роль, рассчитанная на один неймспейс или проект, действовала бы во всех неймспейсах сразу. Используйте RoleBinding в нужном неймспейсе либо ProjectRoleBinding/ClusterProjectRoleBinding для проекта. ClusterRoleBinding допустим только для системных и подсистемных ролей, так как они кластерные.
• Нельзя выдать capability на весь кластер. ClusterRoleBinding на любую capability (d8:*-capability:*, включая пользовательские) отклоняется: capability — «строительный блок» для ролей, а не самостоятельная роль. В отдельном неймспейсе привязать capability через RoleBinding можно.
• Нельзя получить управление проектами через собственную роль. Создание Role или ClusterRole, дающей права на изменение ресурсов управления проектами (projects, projecttemplates, projectrolebindings, clusterprojectrolebindings, projectnamespaces), отклоняется. Эти права дают только встроенные роли d8:project:*. Без этой защиты администратор неймспейса мог бы создать роль с правом создавать ProjectRoleBinding и выдать себе доступ ко всему проекту. Роли только на чтение этих ресурсов разрешены.
• Нельзя смешивать пользовательскую и административную области в одной роли. Собственная роль не может одновременно агрегировать capabilities областей namespace/project и областей system/subsystem — это исключает создание «супер-роли», объединяющей доступ к приложениям и к платформе.
• Собственные роли не могут содержать прямых RBAC-правил — только агрегировать capabilities. Права описываются в отдельных пользовательских capabilities, что делает состав любой роли прозрачным. Подробнее — в FAQ.

Отображаемые названия ролей

Каждая встроенная роль и capability имеет локализованные название и описание в аннотациях:

• ru.meta.deckhouse.io/title, ru.meta.deckhouse.io/description — на русском;
• en.meta.deckhouse.io/title, en.meta.deckhouse.io/description — на английском.

Эти аннотации использует, например, веб-интерфейс Deckhouse Console при отображении списка ролей.

Если стандартное название не подходит (например, вы хотите называть роли в терминах, принятых в компании), добавьте на роль аннотации custom.meta.deckhouse.io/title и custom.meta.deckhouse.io/description — интерфейс покажет их вместо стандартных. Пример:

d8 k annotate clusterrole d8:namespace:admin \
  custom.meta.deckhouse.io/title='Администратор команды'

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

Устаревшие имена ролей

Прежние имена ролей гранулярной модели (d8:manage:<подсистема>:<уровень>, d8:manage:all:<уровень> и d8:use:role:<уровень>) устарели и будут удалены в следующем релизе. Для обратной совместимости они временно сохранены как роли-псевдонимы: привязка к псевдониму агрегирует capabilities новой роли. Это не те же права, что до апгрейда: d8:use:role:admin больше не даёт выпуск токена ServiceAccount и impersonate (это ушло на superadmin); псевдонимы не delegatable, поэтому новые project RoleBinding на старые имена отклоняются; ClusterRoleBinding на d8:manage:* больше не создают автоматические namespace RoleBinding.

Соответствие имён:

Пока в кластере остаются привязки к устаревшим именам, срабатывают алерты D8UserAuthzDeprecatedRBACv2RoleInUse (привязка к роли-псевдониму) и D8UserAuthzDeprecatedRBACv2CapabilityInUse (привязка к устаревшей capability, которая больше не даёт прав). Релиз, который удаляет псевдонимы, несёт требование релиза deprecatedRBACv2BindingsCount: обновление остаётся в ожидании, а список привязок выводится в статусе DeckhouseRelease, пока каждая привязка к роли-псевдониму не пересоздана на новое имя роли. Привязка к устаревшей capability релиз не держит: удаление псевдонимов для неё ничего не меняет.

Модуль, который переименовывает собственную роль, сохраняет старое имя тем же способом: ClusterRole с лейблом rbac.deckhouse.io/deprecated в templates/rbacv2-compat/ модуля, новое имя — в аннотации rbac.deckhouse.io/deprecated-replaced-by. Привязка к такому псевдониму вызывает алерт D8UserAuthzDeprecatedRBACv2ModuleRoleInUse с новым именем роли и релиз Deckhouse не держит: псевдоним удаляет сам модуль в своём релизе. Аннотация обязательна (псевдоним без неё игнорируется), а имя псевдонима может быть любым именем d8:, кроме семейств ролей самой платформы (d8:system:, d8:subsystem:, d8:namespace:, d8:project:, d8:custom:, d8:dict).

Переведите существующие RoleBinding и ClusterRoleBinding на новые имена ролей. Найти привязки, использующие устаревшие имена, можно с помощью команды:

d8 k get clusterrolebindings,rolebindings -A -o json \
  | jq -r '.items[] | select(.roleRef.name | test("^d8:(manage|use):")) | "\(.kind) \(.metadata.namespace // "-") \(.metadata.name) -> \(.roleRef.name)"'

Упрощённая ролевая модель

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

• Модуль реализует role-based-подсистему сквозной авторизации, расширяя функционал стандартного механизма RBAC.
• Настройка прав доступа происходит с помощью ресурсов.
• Управление доступом к инструментам масштабирования (параметр allowScale ресурса ClusterAuthorizationRule или AuthorizationRule).
• Управление доступом к форвардингу портов (параметр portForwarding ресурса ClusterAuthorizationRule или AuthorizationRule).
• Управление списком разрешённых пространств имён в формате labelSelector (параметр namespaceSelector ресурса ClusterAuthorizationRule).

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

• User — позволяет получать информацию обо всех объектах (включая доступ к журналам подов), но не позволяет заходить в контейнеры, читать секреты и выполнять port-forward;
• PrivilegedUser — то же самое, что и User, но позволяет заходить в контейнеры, читать секреты, а также удалять поды (что обеспечивает возможность перезагрузки);
• Editor — то же самое, что и PrivilegedUser, но предоставляет возможность создавать, изменять и удалять все объекты, которые обычно нужны для прикладных задач;
• Admin — то же самое, что и Editor, но позволяет удалять служебные объекты (производные ресурсы, например ReplicaSet, certmanager.k8s.io/challenges и certmanager.k8s.io/orders);
• ClusterEditor — то же самое, что и Editor, но позволяет управлять ограниченным набором cluster-wide-объектов, которые могут понадобиться для прикладных задач (ClusterXXXMetric, KeepalivedInstance, DaemonSet и т. д). Роль для работы оператора кластера;
• ClusterAdmin — то же самое, что и ClusterEditor + Admin, но позволяет управлять служебными cluster-wide-объектами (производные ресурсы, например MachineSets, Machines, OpenstackInstanceClasses и т. п., а также ClusterAuthorizationRule, ClusterRoleBindings и ClusterRole). Роль для работы администратора кластера. Важно, что ClusterAdmin, поскольку он уполномочен редактировать ClusterRoleBindings, может сам себе расширить полномочия;
• SuperAdmin — разрешены любые действия с любыми объектами, при этом ограничения namespaceSelector и limitNamespaces продолжат работать.

В случае, если в ClusterAuthorizationRule-ресурсе используется namespaceSelector, параметры limitNamespaces и allowAccessToSystemNamespace не учитываются.

Если вебхук авторизации станет недоступен, запросы будут запрещаться, а не разрешаться: вебхук стоит перед RBAC и настроен с failurePolicy: Deny, поэтому запрос, на который он не смог ответить, до RBAC не доходит. Исключение — идентичности, перечисленные в matchConditions ресурса AuthorizationConfiguration: компоненты control plane, kubelet’ы и сервисные аккаунты неймспейсов kube-system и d8-* webhook не проходят, поэтому кластер продолжает работать, а Deckhouse может восстановить вебхук.

Список доступа для каждой роли модуля по умолчанию

Каждая следующая роль наследует права предыдущих ролей. В блоке роли показаны только права, которые она добавляет.

Список ниже включает:

• стандартные права упрощённой ролевой модели (права k8s);
• права, создаваемые встроенными модулями Deckhouse.

В нем отсутствуют права модулей из источника.

Модули из источника при включении в кластере создают права на предоставляемые ими ресурсы. При выключении модуля из источника созданные им права удаляются.

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

Сокращения для verbs:

• read - get, list, watch
• read-write - get, list, watch, create, delete, deletecollection, patch, update
• write - create, delete, deletecollection, patch, update

Роль User:

read:
    - acme.cert-manager.io/challenges
    - acme.cert-manager.io/orders
    - apiextensions.k8s.io/customresourcedefinitions
    - apps/daemonsets
    - apps/deployments
    - apps/replicasets
    - apps/statefulsets
    - autoscaling.k8s.io/verticalpodautoscalercheckpoints
    - autoscaling.k8s.io/verticalpodautoscalers
    - autoscaling/horizontalpodautoscalers
    - batch/cronjobs
    - batch/jobs
    - cert-manager.io/certificaterequests
    - cert-manager.io/certificates
    - cert-manager.io/clusterissuers
    - cert-manager.io/issuers
    - cilium.io/ciliumclusterwidenetworkpolicies
    - cilium.io/ciliumnetworkpolicies
    - config.gatekeeper.sh/configs
    - configmaps
    - connection.gatekeeper.sh/connections
    - constraints.gatekeeper.sh/*
    - deckhouse.io/applicationpackages
    - deckhouse.io/applicationpackageversions
    - deckhouse.io/applications
    - deckhouse.io/awsinstanceclasses
    - deckhouse.io/azureinstanceclasses
    - deckhouse.io/clusterprojectrolebindings
    - deckhouse.io/deschedulers
    - deckhouse.io/dexauthenticators
    - deckhouse.io/dexclients
    - deckhouse.io/dvpinstanceclasses
    - deckhouse.io/dynamixinstanceclasses
    - deckhouse.io/gcpinstanceclasses
    - deckhouse.io/huaweicloudinstanceclasses
    - deckhouse.io/hubblemonitoringconfigs
    - deckhouse.io/instances
    - deckhouse.io/keepalivedinstances
    - deckhouse.io/localpathprovisioners
    - deckhouse.io/nodegroups
    - deckhouse.io/nodeoperations
    - deckhouse.io/openstackinstanceclasses
    - deckhouse.io/operationpolicies
    - deckhouse.io/projectnamespaces
    - deckhouse.io/projectrolebindings
    - deckhouse.io/projecttemplates
    - deckhouse.io/securitypolicies
    - deckhouse.io/securitypolicyexceptions
    - deckhouse.io/vcdaffinityrules
    - deckhouse.io/vcdinstanceclasses
    - deckhouse.io/vsphereinstanceclasses
    - deckhouse.io/yandexinstanceclasses
    - deckhouse.io/zvirtinstanceclasses
    - discovery.k8s.io/endpointslices
    - endpoints
    - events
    - events.k8s.io/events
    - expansion.gatekeeper.sh/expansiontemplate
    - extensions.istio.io/wasmplugins
    - extensions/daemonsets
    - extensions/deployments
    - extensions/ingresses
    - extensions/replicasets
    - extensions/replicationcontrollers
    - externaldata.gatekeeper.sh/providers
    - gateway.networking.k8s.io/backendtlspolicies
    - gateway.networking.k8s.io/gatewayclasses
    - gateway.networking.k8s.io/gateways
    - gateway.networking.k8s.io/grpcroutes
    - gateway.networking.k8s.io/httproutes
    - gateway.networking.k8s.io/listenersets
    - gateway.networking.k8s.io/referencegrants
    - gateway.networking.k8s.io/tcproutes
    - gateway.networking.k8s.io/tlsroutes
    - gateway.networking.k8s.io/udproutes
    - infrastructure.cluster.x-k8s.io/deckhouseclusters
    - infrastructure.cluster.x-k8s.io/deckhousemachines
    - infrastructure.cluster.x-k8s.io/deckhousemachinetemplates
    - infrastructure.cluster.x-k8s.io/dynamixclusters
    - infrastructure.cluster.x-k8s.io/dynamixmachines
    - infrastructure.cluster.x-k8s.io/dynamixmachinetemplates
    - infrastructure.cluster.x-k8s.io/huaweicloudclusters
    - infrastructure.cluster.x-k8s.io/huaweicloudmachines
    - infrastructure.cluster.x-k8s.io/huaweicloudmachinetemplates
    - infrastructure.cluster.x-k8s.io/vcdclusters
    - infrastructure.cluster.x-k8s.io/vcdclustertemplates
    - infrastructure.cluster.x-k8s.io/vcdmachines
    - infrastructure.cluster.x-k8s.io/vcdmachinetemplates
    - infrastructure.cluster.x-k8s.io/zvirtclusters
    - infrastructure.cluster.x-k8s.io/zvirtmachines
    - infrastructure.cluster.x-k8s.io/zvirtmachinetemplates
    - limitranges
    - metrics.k8s.io/nodes
    - metrics.k8s.io/pods
    - multitenancy.deckhouse.io/availableclusterresources
    - mutations.gatekeeper.sh/assign
    - mutations.gatekeeper.sh/assignimage
    - mutations.gatekeeper.sh/assignmetadata
    - mutations.gatekeeper.sh/modifyset
    - namespaces
    - network.deckhouse.io/egressgatewaypolicies
    - network.deckhouse.io/egressgateways
    - network.deckhouse.io/metalloadbalancerbgppeers
    - network.deckhouse.io/metalloadbalancerclasses
    - network.deckhouse.io/metalloadbalancerconfigurations
    - network.deckhouse.io/metalloadbalancerpools
    - network.deckhouse.io/servicewithhealthchecks
    - networking.istio.io/destinationrules
    - networking.istio.io/gateways
    - networking.istio.io/serviceentries
    - networking.istio.io/sidecars
    - networking.istio.io/virtualservices
    - networking.istio.io/workloadentries
    - networking.istio.io/workloadgroups
    - 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
    - security.istio.io/authorizationpolicies
    - security.istio.io/peerauthentications
    - security.istio.io/requestauthentications
    - serviceaccounts
    - services
    - status.gatekeeper.sh/configpodstatuses
    - status.gatekeeper.sh/connectionpodstatuses
    - status.gatekeeper.sh/constraintpodstatuses
    - status.gatekeeper.sh/constrainttemplatepodstatuses
    - status.gatekeeper.sh/expansiontemplatepodstatuses
    - status.gatekeeper.sh/mutatorpodstatuses
    - status.gatekeeper.sh/providerpodstatuses
    - storage.k8s.io/storageclasses
    - syncset.gatekeeper.sh/syncsets
    - telemetry.istio.io/telemetries
    - templates.gatekeeper.sh/constrainttemplates

Роль PrivilegedUser (включает все правила из роли User):

create:
    - pods/eviction
create,get:
    - pods/attach
    - pods/exec
delete,deletecollection:
    - pods
read:
    - secrets

Роль Editor (включает все правила из роли User, PrivilegedUser):

get,patch:
    - pods/resize
write:
    - apps/deployments
    - apps/statefulsets
    - autoscaling.k8s.io/verticalpodautoscalers
    - autoscaling/horizontalpodautoscalers
    - batch/cronjobs
    - batch/jobs
    - cert-manager.io/certificates
    - configmaps
    - deckhouse.io/dexauthenticators
    - deckhouse.io/dexclients
    - discovery.k8s.io/endpointslices
    - endpoints
    - extensions/deployments
    - extensions/ingresses
    - gateway.networking.k8s.io/backendtlspolicies
    - gateway.networking.k8s.io/gateways
    - gateway.networking.k8s.io/grpcroutes
    - gateway.networking.k8s.io/httproutes
    - gateway.networking.k8s.io/listenersets
    - gateway.networking.k8s.io/referencegrants
    - gateway.networking.k8s.io/tcproutes
    - gateway.networking.k8s.io/tlsroutes
    - gateway.networking.k8s.io/udproutes
    - network.deckhouse.io/servicewithhealthchecks
    - networking.istio.io/destinationrules
    - networking.istio.io/gateways
    - networking.istio.io/serviceentries
    - networking.istio.io/sidecars
    - networking.istio.io/virtualservices
    - networking.istio.io/workloadentries
    - networking.istio.io/workloadgroups
    - networking.k8s.io/ingresses
    - networking.k8s.io/networkpolicies
    - persistentvolumeclaims
    - policy/poddisruptionbudgets
    - secrets
    - security.istio.io/authorizationpolicies
    - security.istio.io/peerauthentications
    - security.istio.io/requestauthentications
    - serviceaccounts
    - services

Роль Admin (включает все правила из роли User, PrivilegedUser, Editor):

create:
    - serviceaccounts/token
create,patch,update:
    - pods
delete,deletecollection:
    - acme.cert-manager.io/challenges
    - acme.cert-manager.io/orders
    - apps/replicasets
    - cert-manager.io/certificaterequests
    - extensions/replicasets
read-write:
    - deckhouse.io/authorizationrules
write:
    - autoscaling.k8s.io/verticalpodautoscalercheckpoints
    - cert-manager.io/issuers
    - deckhouse.io/applications
    - extensions.istio.io/wasmplugins
    - rbac.authorization.k8s.io/rolebindings
    - rbac.authorization.k8s.io/roles
    - telemetry.istio.io/telemetries

Роль ClusterEditor (включает все правила из роли User, PrivilegedUser, Editor):

create,delete:
    - deckhouse.io/nodeoperations
delete,deletecollection:
    - acme.cert-manager.io/challenges
    - acme.cert-manager.io/orders
    - cert-manager.io/certificaterequests
get,list:
    - templates.internal.deckhouse.io/nodeconfigtemplates
patch,update:
    - nodes
read:
    - deckhouse.io/containerdintegritypolicies
    - deckhouse.io/ingressistiocontrollers
    - deckhouse.io/istiofederations
    - deckhouse.io/istiomulticlusters
    - install.istio.io/istiooperators
    - multitenancy.deckhouse.io/grantableclusterresourcedefinitions
    - multitenancy.deckhouse.io/grantableclusterresourcereferences
    - rbac.authorization.k8s.io/clusterrolebindings
    - rbac.authorization.k8s.io/clusterroles
    - sailoperator.io/istiocnis
    - sailoperator.io/istiorevisions
    - sailoperator.io/istiorevisiontags
    - sailoperator.io/istios
    - sailoperator.io/ztunnels
read-write:
    - deckhouse.io/nodegroupconfigurations
    - deckhouse.io/staticinstances
    - multitenancy.deckhouse.io/clusterresourcegrantpolicies
write:
    - apiextensions.k8s.io/customresourcedefinitions
    - apps/daemonsets
    - autoscaling.k8s.io/verticalpodautoscalercheckpoints
    - cert-manager.io/clusterissuers
    - cert-manager.io/issuers
    - deckhouse.io/applications
    - deckhouse.io/hubblemonitoringconfigs
    - deckhouse.io/instances
    - deckhouse.io/keepalivedinstances
    - deckhouse.io/nodegroups
    - extensions.istio.io/wasmplugins
    - extensions/daemonsets
    - gateway.networking.k8s.io/gatewayclasses
    - network.deckhouse.io/egressgatewaypolicies
    - network.deckhouse.io/egressgateways
    - storage.k8s.io/storageclasses
    - telemetry.istio.io/telemetries

Роль ClusterAdmin (включает все правила из роли User, PrivilegedUser, Editor, Admin, ClusterEditor):

create:
    - authorization.deckhouse.io/bulksubjectaccessreviews
    - authorization.deckhouse.io/roleaccessreports
    - authorization.deckhouse.io/subjectaccessreports
    - deckhouse.io/dexauthenticators/allow-access-to-kubernetes
    - deckhouse.io/dexclients/allow-access-to-kubernetes
get,list,patch,update,watch:
    - control-plane.deckhouse.io/controlplanenodes
patch,update:
    - deckhouse.io/vcdaffinityrules
    - infrastructure.cluster.x-k8s.io/deckhouseclusters
    - infrastructure.cluster.x-k8s.io/deckhousemachines
    - infrastructure.cluster.x-k8s.io/deckhousemachinetemplates
    - infrastructure.cluster.x-k8s.io/dynamixclusters
    - infrastructure.cluster.x-k8s.io/dynamixmachines
    - infrastructure.cluster.x-k8s.io/dynamixmachinetemplates
    - infrastructure.cluster.x-k8s.io/huaweicloudclusters
    - infrastructure.cluster.x-k8s.io/huaweicloudmachines
    - infrastructure.cluster.x-k8s.io/huaweicloudmachinetemplates
    - infrastructure.cluster.x-k8s.io/vcdclusters
    - infrastructure.cluster.x-k8s.io/vcdclustertemplates
    - infrastructure.cluster.x-k8s.io/vcdmachines
    - infrastructure.cluster.x-k8s.io/vcdmachinetemplates
    - infrastructure.cluster.x-k8s.io/zvirtclusters
    - infrastructure.cluster.x-k8s.io/zvirtmachines
    - infrastructure.cluster.x-k8s.io/zvirtmachinetemplates
proxy:
    - nodes
read:
    - control-plane.deckhouse.io/controlplaneoperations
    - nfd.k8s-sigs.io/nodefeaturegroups
    - nfd.k8s-sigs.io/nodefeaturerules
    - nfd.k8s-sigs.io/nodefeatures
read-write:
    - deckhouse.io/clusterauthorizationrules
    - deckhouse.io/deckhousereleases
    - deckhouse.io/dexproviderchecks
    - deckhouse.io/dexproviders
    - deckhouse.io/groups
    - deckhouse.io/moduleconfigs
    - deckhouse.io/moduledocumentations
    - deckhouse.io/modulepulloverrides
    - deckhouse.io/modulereleases
    - deckhouse.io/modules
    - deckhouse.io/modulesources
    - deckhouse.io/moduleupdatepolicies
    - deckhouse.io/nodeusers
    - deckhouse.io/packagerepositories
    - deckhouse.io/packagerepositoryoperations
    - deckhouse.io/sshcredentials
    - deckhouse.io/useraccounts
    - deckhouse.io/useroperations
    - deckhouse.io/users
    - nodes/configz
    - nodes/healthz
    - nodes/log
    - nodes/metrics
    - nodes/pods
    - nodes/proxy
    - nodes/stats
update:
    - namespaces/finalize
write:
    - cilium.io/ciliumclusterwidenetworkpolicies
    - cilium.io/ciliumnetworkpolicies
    - config.gatekeeper.sh/configs
    - connection.gatekeeper.sh/connections
    - constraints.gatekeeper.sh/*
    - deckhouse.io/applicationpackages
    - deckhouse.io/applicationpackageversions
    - deckhouse.io/awsinstanceclasses
    - deckhouse.io/azureinstanceclasses
    - deckhouse.io/clusterprojectrolebindings
    - deckhouse.io/containerdintegritypolicies
    - deckhouse.io/deschedulers
    - deckhouse.io/dvpinstanceclasses
    - deckhouse.io/dynamixinstanceclasses
    - deckhouse.io/gcpinstanceclasses
    - deckhouse.io/huaweicloudinstanceclasses
    - deckhouse.io/ingressistiocontrollers
    - deckhouse.io/istiofederations
    - deckhouse.io/istiomulticlusters
    - deckhouse.io/localpathprovisioners
    - deckhouse.io/openstackinstanceclasses
    - deckhouse.io/operationpolicies
    - deckhouse.io/projectnamespaces
    - deckhouse.io/projectrolebindings
    - deckhouse.io/projects
    - deckhouse.io/projecttemplates
    - deckhouse.io/securitypolicies
    - deckhouse.io/securitypolicyexceptions
    - deckhouse.io/vcdinstanceclasses
    - deckhouse.io/vsphereinstanceclasses
    - deckhouse.io/yandexinstanceclasses
    - deckhouse.io/zvirtinstanceclasses
    - expansion.gatekeeper.sh/expansiontemplate
    - externaldata.gatekeeper.sh/providers
    - install.istio.io/istiooperators
    - limitranges
    - mutations.gatekeeper.sh/assign
    - mutations.gatekeeper.sh/assignimage
    - mutations.gatekeeper.sh/assignmetadata
    - mutations.gatekeeper.sh/modifyset
    - namespaces
    - network.deckhouse.io/metalloadbalancerbgppeers
    - network.deckhouse.io/metalloadbalancerclasses
    - network.deckhouse.io/metalloadbalancerconfigurations
    - network.deckhouse.io/metalloadbalancerpools
    - rbac.authorization.k8s.io/clusterrolebindings
    - rbac.authorization.k8s.io/clusterroles
    - resourcequotas
    - sailoperator.io/istiocnis
    - sailoperator.io/istiorevisions
    - sailoperator.io/istiorevisiontags
    - sailoperator.io/istios
    - sailoperator.io/ztunnels
    - status.gatekeeper.sh/configpodstatuses
    - status.gatekeeper.sh/connectionpodstatuses
    - status.gatekeeper.sh/constraintpodstatuses
    - status.gatekeeper.sh/constrainttemplatepodstatuses
    - status.gatekeeper.sh/expansiontemplatepodstatuses
    - status.gatekeeper.sh/mutatorpodstatuses
    - status.gatekeeper.sh/providerpodstatuses
    - syncset.gatekeeper.sh/syncsets
    - templates.gatekeeper.sh/constrainttemplates

Вы можете получить дополнительный список правил доступа для роли модуля из кластера (существующие пользовательские правила и нестандартные правила из других модулей Deckhouse):

D8_ROLE_NAME=Editor
kubectl get clusterrole -A -o jsonpath="{range .items[?(@.metadata.annotations.user-authz\.deckhouse\.io/access-level=='$D8_ROLE_NAME')]}{.rules}{'\n'}{end}" | jq -s add