Контроль доступу на основі ролей

У Kubernetes надання ролей користувачу або службовому обліковому запису, специфічному для застосунку, є найкращою практикою для забезпечення роботи вашого застосунку в межах, які ви визначили. Дізнайтеся більше про дозволи службових облікових записів в офіційній документації Kubernetes.

З версії Kubernetes 1.6 контроль доступу на основі ролей (RBAC) стандартно увімкнено. RBAC дозволяє вам визначати, які типи дій дозволені залежно від користувача та його ролі у вашій організації.

З RBAC ви можете:

• надавати привілейовані операції (створення ресурсів на рівні кластеру, таких як нові ролі) адміністраторам
• обмежити можливість користувача створювати ресурси (pods, persistent volumes, deployments) до певних просторів імен або в межах кластера (квоти ресурсів, ролі, визначення власних ресурсів)
• обмежити можливість користувача переглядати ресурси або в певних просторах імен, або в межах кластера.

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

Управління обліковими записами користувачів

Усі кластери Kubernetes мають дві категорії користувачів: службові облікові записи, керовані Kubernetes, та звичайні користувачі.

Передбачається, що управління обліковими записами звичайних користувачів здійснюється зовнішньою незалежною службою. Це може бути адміністратор, який розподіляє приватні ключі, сховище користувачів, таке як Keystone або Google Accounts, або навіть файл зі списком імен користувачів та паролів. Стосовно цього, Kubernetes не має обʼєктів, які представляють облікові записи звичайних користувачів. Звичайних користувачів не можна додати до кластера за допомогою виклику API.

На відміну від цього, службові облікові записи є користувачами, керованими API Kubernetes. Вони привʼязані до певних просторів імен і створюються автоматично API сервером або вручну через API-запити. Службові облікові записи привʼязані до набору облікових даних, які зберігаються як Secrets і монтуються в podʼи, що дозволяє процесам всередині кластера спілкуватися з API Kubernetes.

Запити API привʼязані або до звичайного користувача, або до службового облікового запису, або розглядаються як анонімні запити. Це означає, що кожен процес усередині або поза кластером, від користувача, який вводить kubectl на робочій станції, до kubelets на вузлах, до членів панелі управління, повинен пройти автентифікацію під час надсилання запитів до сервера API, або розглядатися як анонімний користувач.

Roles, ClusterRoles, RoleBindings та ClusterRoleBindings

У Kubernetes облікові записи користувачів і службові облікові записи можуть переглядати та редагувати лише ресурси, до яких їм надано доступ. Цей доступ надається за допомогою Roles і RoleBindings. Ролі та RoleBindings привʼязані до певного простору імен, надаючи користувачам можливість переглядати та/або редагувати ресурси в цьому просторі імен, до яких надає доступ Role.

На рівні кластера вони називаються ClusterRoles і ClusterRoleBindings. Надання користувачеві ClusterRole надає йому доступ до перегляду та/або редагування ресурсів у всьому кластері. Це також необхідно для перегляду та/або редагування ресурсів на рівні кластера (простори імен, квоти ресурсів, вузли).

ClusterRoles можна привʼязати до певного простору імен через посилання в RoleBinding. admin, edit та view стандартні ClusterRoles часто використовуються таким чином.

Ось кілька ClusterRoles, стандартно доступних у Kubernetes. Вони призначені для користувачів. До них відносяться суперкористувацькі ролі (cluster-admin) та ролі з більш детальним доступом (admin, edit, view).

Стандартна ClusterRole	Стандартна ClusterRoleBinding	Опис
cluster-admin	Група system:masters.	Дозволяє суперкористувачеві виконувати будь-які дії з будь-яким ресурсом. При використанні в ClusterRoleBinding надає повний контроль над усіма ресурсами в кластері та в усіх просторах імен. При використанні в RoleBinding надає повний контроль над усіма ресурсами в просторі імен rolebinding, включаючи сам простір імен.
admin	Немає	Дозволяє доступ адміністратора, який має бути наданий в межах простору імен за допомогою RoleBinding. Якщо використовується в RoleBinding, дозволяє доступ для читання/запису до більшості ресурсів в просторі імен, включаючи можливість створювати ролі та rolebindings в просторі імен. Не дозволяє доступ для запису до квоти ресурсів або до самого простору імен.
edit	Немає	Дозволяє читати/записувати більшість обʼєктів в просторі імен. Не дозволяє переглядати або змінювати ролі чи привʼязки ролей.
view	Немає	Дозволяє доступ тільки для читання, щоб бачити більшість обʼєктів в просторі імен. Не дозволяє переглядати ролі або привʼязки ролей. Не дозволяє переглядати секрети, оскільки останні мають підвищений рівень доступу.

Обмеження доступу облікових записів користувачів за допомогою RBAC

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

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

Щоб обмежити доступ користувача до певного простору імен, можна використовувати роль edit або admin. Якщо ваші чарти створюють або взаємодіють з Roles і RoleBindings, ви захочете використовувати ClusterRole admin.

Крім того, ви також можете створити RoleBinding з доступом cluster-admin. Надаючи користувачу доступ cluster-admin на рівні простору імен, ви надаєте повний контроль над кожним ресурсом у просторі імен, включаючи сам простір імен.

Для цього прикладу ми створимо користувача з роллю edit. Спочатку створіть простір імен:

$ kubectl create namespace foo

Тепер створіть RoleBinding у цьому просторі імен, надаючи користувачу роль edit.

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

Приклад: Надання користувачу доступу для читання/запису на рівні кластера

Якщо користувач хоче встановити чарт, який встановлює ресурси на рівні кластера (простори імен, ролі, визначення власних ресурсів тощо), їм знадобиться доступ для запису на рівні кластера.

Для цього надайте користувачу доступ 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

Приклад: Надання користувачу доступу лише для читання до певного простору імен

Ви, мабуть, помітили, що для перегляду секретів немає ClusterRole. ClusterRole view не надає користувачеві права доступу до Secrets через ризик підвищення привілеїв. Helm стандартно зберігає метадані релізів як Secrets.

Щоб користувач міг виконати команду helm list, їм потрібно мати можливість читати ці секрети. Для цього ми створимо спеціальний 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​

Як тільки це буде зроблено, ми можемо надати користувачу доступ для читання до більшості ресурсів, а потім надати їм доступ до секретів:

$ 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

Додатково

Вищезазначені приклади використовують стандартні ClusterRoles, надані Kubernetes. Для більш детального контролю за ресурсами, до яких користувачі мають доступ, ознайомтеся з документацією Kubernetes по створенню власних Roles і ClusterRoles.