Код 2026-05-20 1 хв читання Джерело: Dev 2

Kubernetes RBAC: як забезпечити безпеку доступу до кластера

Управління доступом до кластера Kubernetes є критично важливим аспекстом безпеки. Більшість команд не потребують повних прав `cluster-admin`; замість цього їм потрібні ролі, що відповідають принципу найменших привілеїв (`least-privilege`) та фактичним функціям роботи.

Kubernetes RBAC: як забезпечити безпеку доступу до кластера

Kubernetes RBAC (Role-Based Access Control) — це механізм контролю доступу, який забезпечує, щоб користувачі чи сервіси мали лише ті права, які необхідні для виконання їхніх завдань. Цей контроль реалізується на рівні API-сервера кластера за допомогою атрибутивної оцінки запитів.

Основні концепції RBAC

Кожен виклик `kubectl` або прямий виклик API розбирається на чотири ключові атрибути: користувач (`user`), дієслово (`verb`), ресурс (`resource`) та простір імен (`namespace`). Авторизаційний рівень перевіряє, чи надає будь-який `RoleBinding` або `ClusterRoleBinding` запитуваний доступ. Важливо розуміти, що API-сервер оцінює кожен запит незалежно — жоден стан сесії не зберігається.

Застосування принципу найменших привілеїв

Правильна політика RBAC надає лише достатній обсяг доступу, анічого більше. Щоб створити ефективну політику, необхідно ідентифікувати: які ресурси потрібні (наприклад, `deployments`, `pods`), які дієслова необхідні (`get`, `create`, `patch`) та в яких просторах імен це має відбуватися. Розробники повинні уникати використання загальних символів (``) у дієсловах або ресурсах; натомість слід явно перелічувати потрібні операції.

Приклад робочого процесу

Процес авторизації виглядає так: 1. Аутентифікація через клієнтський сертифікат, bearer token або OIDC. 2. Авторизація через механізм RBAC. 3. Пошук `RoleBinding` (або `ClusterRoleBinding`) у цільовому просторі імен, який пов'язує користувача з `Role`, що дозволяє операцію `get` для `pods`. Таким чином, RBAC відокремлює визначення політики (`Role`) від її призначення (`RoleBinding`).

ClusterRoles та обмеження

Ролі за замовчуванням є прив'язаними до просторів імен. Якщо потрібен доступ на рівні всього кластера, слід використовувати `ClusterRoles`. Наприклад, для надання лише читацького доступу до Pods та Services у просторі імен `production` можна визначити відповідний `Role` і потім зв'язати його з користувачем за допомогою `RoleBinding`. Якщо доступ спробувати отримати поза цим простором імен (наприклад, у `staging`), API-сервер відхилить запит із помилкою.

Telegram Logo Читайте нас у Telegram: @procodeandevenmore