Модуль user-authz

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

Новая ролевая модель

В отличие от устаревшей ролевой модели DKP, новая ролевая модель не использует ресурсы ClusterAuthorizationRule и AuthorizationRule. Вся настройка прав доступа выполняется стандартным для RBAC Kubernetes способом: с помощью создания ресурсов RoleBinding или ClusterRoleBinding, с указанием в них одной из подготовленных модулем user-authz ролей.

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

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

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

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

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

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

• Use-роли — для назначения прав пользователям (например, разработчикам приложений) в конкретном пространстве имён.
• Manage-роли — для назначения прав администраторам.

Use-роли

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

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

Модуль создаёт следующие use-роли для каждого уровня доступа:

• d8:use:role:viewer — позволяет в конкретном пространстве имён просматривать стандартные ресурсы Kubernetes, кроме секретов и ресурсов RBAC, а также выполнять аутентификацию в кластере;
• d8:use:role:user — дополнительно к роли d8:use:role:viewer позволяет в конкретном пространстве имён просматривать секреты и ресурсы RBAC, подключаться к подам, удалять поды (но не создавать или изменять их), выполнять kubectl port-forward и kubectl proxy, изменять количество реплик контроллеров;
• d8:use:role:manager — дополнительно к роли d8:use:role:user позволяет в конкретном пространстве имён управлять ресурсами модулей (например, Certificate, PodLoggingConfig и т. п.) и стандартными namespaced-ресурсами Kubernetes (Pod, ConfigMap, CronJob и т. п.);
• d8:use:role:admin — дополнительно к роли d8:use:role:manager позволяет в конкретном пространстве имён управлять ресурсами ResourceQuota, ServiceAccount, Role, RoleBinding, NetworkPolicy.

Manage-роли

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

Manage-роль определяет права на доступ:

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

Формат названия manage-роли — d8:manage:<SCOPE>:<ACCESS_LEVEL>, где:

• SCOPE — область роли. Может быть либо одной из областей списка, либо all для доступа в рамках всех областей;

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

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

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

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

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

• viewer — позволяет просматривать стандартные ресурсы Kubernetes (кроме секретов и ресурсов RBAC). В manage-ролях позволяет просматривать конфигурацию модулей (ресурсы moduleConfig), cluster-wide-ресурсы модулей и namespaced-ресурсы модулей;
• user — дополнительно к роли viewer позволяет просматривать секреты, подключаться к подам, удалять поды, выполнять kubectl port-forward и kubectl proxy, изменять количество реплик контроллеров;
• manager — дополнительно к роли user позволяет управлять ресурсами модулей (например, Certificate, PodLoggingConfig и т. п.). В manage-ролях позволяет управлять конфигурацией модулей (ресурсы moduleConfig), cluster-wide-ресурсами модулей и namespaced-ресурсами модулей;
• admin — дополнительно к роли manager позволяет в зависимости от области роли управлять такими ресурсами, как CustomResourceDefinition, Namespace, Node, ClusterRole, ClusterRoleBinding, PersistentVolume, MutatingWebhookConfiguration, ValidatingAdmissionPolicy и т. п.

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

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

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

• d8:manage:networking:viewer
• d8:manage:networking:user
• d8:manage:networking:manager
• d8:manage:networking:admin

Область роли ограничивает её действие всеми системными (начинающимися с d8- или kube-) пространствами имён кластера (область all) или теми пространствами имён, в которых работают модули области (см. таблицу состава областей).

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

Устаревшая ролевая модель

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

• Реализует 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 не учитываются.

Если вебхук, который реализовывает систему авторизации, по какой-то причине будет недоступен, в это время опции allowAccessToSystemNamespaces, namespaceSelector и limitNamespaces в custom resource перестанут применяться и пользователи будут иметь доступ во все пространства имён. После восстановления доступности вебхука опции продолжат работать.

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

Сокращения для 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
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