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

В Kubernetes назначение ролей пользователям или сервисным учётным записям приложений является лучшей практикой, позволяющей ограничить права приложения заданной областью. Подробнее о правах сервисных учётных записей читайте в официальной документации Kubernetes.

Начиная с Kubernetes 1.6, управление доступом на основе ролей (RBAC) включено по умолчанию. RBAC позволяет определять, какие типы действий разрешены в зависимости от пользователя и его роли в организации.

С помощью RBAC вы можете:

• предоставлять администраторам привилегированные операции (создание ресурсов на уровне кластера, таких как новые роли)
• ограничивать возможности пользователя по созданию ресурсов (Pod, PersistentVolume, Deployment) в определённых namespace или на уровне всего кластера (квоты ресурсов, роли, CustomResourceDefinition)
• ограничивать возможности пользователя по просмотру ресурсов в определённых namespace или на уровне всего кластера

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

Управление учётными записями пользователей

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

Предполагается, что обычные пользователи управляются внешним независимым сервисом — администратор распределяет приватные ключи, используется хранилище пользователей вроде Keystone или Google Accounts, либо файл со списком имён пользователей и паролей. Поэтому в Kubernetes нет объектов, представляющих обычные учётные записи пользователей. Обычных пользователей нельзя добавить в кластер через вызов API.

Сервисные учётные записи, напротив, управляются через API Kubernetes. Они привязаны к определённым namespace и создаются автоматически сервером API или вручную через вызовы API. Сервисные учётные записи связаны с набором учётных данных, хранящихся как Secret, которые монтируются в Pod, позволяя процессам внутри кластера взаимодействовать с API Kubernetes.

Запросы к API связаны либо с обычным пользователем, либо с сервисной учётной записью, либо обрабатываются как анонимные. Это означает, что каждый процесс — как внутри, так и вне кластера — от пользователя, выполняющего kubectl на рабочей станции, до kubelet на узлах и компонентов плоскости управления, должен аутентифицироваться при обращении к серверу API или будет рассматриваться как анонимный пользователь.

Role, ClusterRole, RoleBinding и ClusterRoleBinding

В Kubernetes учётные записи пользователей и сервисные учётные записи могут просматривать и редактировать только те ресурсы, к которым им предоставлен доступ. Этот доступ предоставляется с помощью Role и RoleBinding. Role и RoleBinding привязаны к определённому namespace и предоставляют пользователям возможность просматривать и/или редактировать ресурсы в этом namespace в соответствии с назначенной Role.

На уровне кластера используются ClusterRole и ClusterRoleBinding. Предоставление пользователю ClusterRole даёт ему доступ к просмотру и/или редактированию ресурсов во всём кластере. Это также необходимо для просмотра и/или редактирования ресурсов на уровне кластера (namespace, квоты ресурсов, узлы).

ClusterRole можно привязать к определённому namespace через RoleBinding. Стандартные ClusterRole admin, edit и view часто используются таким образом.

В Kubernetes по умолчанию доступно несколько ClusterRole. Они предназначены для пользователей и включают роли суперпользователя (cluster-admin) и роли с более детальным контролем доступа (admin, edit, view).

Стандартная ClusterRole	Стандартный ClusterRoleBinding	Описание
cluster-admin	группа system:masters	Предоставляет доступ суперпользователя для выполнения любого действия над любым ресурсом. При использовании в ClusterRoleBinding даёт полный контроль над всеми ресурсами в кластере и во всех namespace. При использовании в RoleBinding даёт полный контроль над всеми ресурсами в namespace привязки роли, включая сам namespace.
admin	Нет	Предоставляет административный доступ, предназначенный для назначения в рамках namespace через RoleBinding. При использовании в RoleBinding разрешает чтение/запись большинства ресурсов в namespace, включая возможность создания Role и RoleBinding в этом namespace. Не разрешает запись в квоты ресурсов или сам namespace.
edit	Нет	Разрешает чтение/запись большинства объектов в namespace. Не разрешает просмотр или изменение Role или RoleBinding.
view	Нет	Разрешает просмотр большинства объектов в namespace (только чтение). Не разрешает просмотр Role, RoleBinding или Secret из соображений безопасности.

Ограничение доступа учётной записи пользователя с помощью RBAC

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

Пример: предоставление пользователю доступа на чтение/запись в определённом namespace

Чтобы ограничить доступ пользователя определённым namespace, можно использовать роль edit или admin. Если ваши чарты создают или взаимодействуют с Role и RoleBinding, следует использовать ClusterRole admin.

Кроме того, можно создать RoleBinding с доступом cluster-admin. Предоставление пользователю доступа cluster-admin на уровне namespace даёт полный контроль над всеми ресурсами в этом namespace, включая сам namespace.

В этом примере мы создадим пользователя с ролью edit. Сначала создайте namespace:

$ kubectl create namespace foo

Теперь создайте RoleBinding в этом namespace, назначив пользователю роль edit.

$ kubectl create rolebinding sam-edit
    --clusterrole edit \​
    --user sam \​
    --namespace foo

Пример: предоставление пользователю доступа на чтение/запись на уровне кластера

Если пользователю нужно устанавливать чарты, создающие ресурсы на уровне кластера (namespace, роли, CustomResourceDefinition и т.д.), ему потребуется доступ на запись на уровне кластера.

Для этого предоставьте пользователю доступ admin или cluster-admin.

Предоставление пользователю доступа cluster-admin даёт доступ абсолютно ко всем ресурсам в Kubernetes, включая доступ к узлам через kubectl drain и другие административные операции. Настоятельно рекомендуется предоставлять пользователю доступ admin или создать пользовательскую ClusterRole, соответствующую его потребностям.

$ kubectl create clusterrolebinding sam-view
    --clusterrole view \​
    --user sam

$ kubectl create clusterrolebinding sam-secret-reader
    --clusterrole secret-reader \​
    --user sam

Пример: предоставление пользователю доступа только на чтение в определённом namespace

Вы могли заметить, что стандартной ClusterRole для просмотра Secret не существует. ClusterRole view не предоставляет доступ на чтение Secret из соображений безопасности. По умолчанию Helm хранит метаданные релиза как Secret.

Чтобы пользователь мог выполнить helm list, ему нужен доступ на чтение Secret. Для этого мы создадим специальную ClusterRole secret-reader.

Создайте файл cluster-role-secret-reader.yaml и добавьте в него следующее содержимое:

apiVersion: rbac.authorization.k8s.io/v1​
kind: ClusterRole​
metadata:​
  name: secret-reader​
rules:​
- apiGroups: [""]​
  resources: ["secrets"]​
  verbs: ["get", "watch", "list"]

Затем создайте ClusterRole с помощью команды:

$ kubectl create -f clusterrole-secret-reader.yaml​

После этого мы можем предоставить пользователю доступ на чтение большинства ресурсов, а затем добавить доступ на чтение Secret:

$ kubectl create namespace foo

$ kubectl create rolebinding sam-view
    --clusterrole view \​
    --user sam \​
    --namespace foo

$ kubectl create rolebinding sam-secret-reader
    --clusterrole secret-reader \​
    --user sam \​
    --namespace foo

Пример: предоставление пользователю доступа только на чтение на уровне кластера

В некоторых сценариях может быть полезно предоставить пользователю доступ на уровне кластера. Например, если пользователь хочет выполнить команду helm list --all-namespaces, API требует, чтобы у пользователя был доступ на чтение на уровне кластера.

Для этого предоставьте пользователю доступ view и secret-reader, как описано выше, но с использованием ClusterRoleBinding.

$ kubectl create clusterrolebinding sam-view
    --clusterrole view \​
    --user sam

$ kubectl create clusterrolebinding sam-secret-reader
    --clusterrole secret-reader \​
    --user sam

Дополнительные соображения

В приведённых выше примерах используются стандартные ClusterRole, поставляемые с Kubernetes. Для более детального контроля над доступом пользователей к ресурсам обратитесь к документации Kubernetes по созданию собственных Role и ClusterRole.