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

У 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`	Немає	Дозволяє читання/запис доступу до більшості обʼєктів у просторі імен. Не дозволяє переглядати або модифікувати ролі або RoleBindings.
`view`	Немає	Дозволяє доступ лише для читання, щоб побачити більшість обʼєктів у просторі імен. Не дозволяє переглядати ролі або RoleBindings. Не дозволяє переглядати secrets, оскільки це є ескалацією доступу.

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

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

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

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

Крім того, ви також можете створити 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, доступної для перегляду secrets. Роль view не надає користувачу доступ до Secrets через проблеми з ескалацією. Helm стандартно зберігає метадані релізів як Secrets.

Щоб користувач міг виконати команду helm list, їм потрібно мати можливість читати ці секрети. Для цього ми створимо спеціальний secret-reader ClusterRole.

Створіть файл 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.