Модуль 3.2: Основи RBAC

Складність: [СЕРЕДНЯ] — основні знання. Час на проходження: 40–50 хвилин. Передумови: Модуль 3.1: Безпека Pod’ів. Цей урок передбачає, що ви вже знаєте Pod Security Standards із попереднього модуля і готові пов’язати посилення захисту робочих навантажень із рішеннями про авторизацію в API.

Результати навчання

Після завершення цього модуля ви зможете ухвалювати й обґрунтовувати практичні рішення про авторизацію в кластерах Kubernetes 1.35+. Кожен результат нижче перевіряється сценарним тестом або практичною вправою з проєктування, тож сприймайте цей перелік як робочий чек-лист, а не пасивний путівник для читання.

1. Оцінювати політики RBAC щодо ролей із надмірними правами, доступу за шаблоном-зірочкою та ризиків ескалації привілеїв.
2. Проєктувати стратегії RoleBinding у межах простору імен і ClusterRoleBinding, які зберігають принцип найменших привілеїв у кластерах Kubernetes 1.35+.
3. Діагностувати, чому користувач, група або сервісний акаунт може чи не може виконати дію, простежуючи суб’єктів, ролі, прив’язки, групи API, ресурси та дієслова.
4. Порівнювати вбудовані ролі, власні ролі, агреговані ClusterRole та права сервісного акаунта для реалістичних платформних і прикладних команд.
5. Впроваджувати придатну для аудиту модель RBAC для розробників, тимлідів та автоматизації розгортання без надання широкого доступу cluster-admin.

Чому цей модуль важливий

Гіпотетичний сценарій: Розгляньмо платформу фінансових послуг, яка надає акаунту автоматизації розгортання широкі права на запис під час вікендового заморожування релізів. Зміна мала бути тимчасовою, але вона залишається в кластері після того, як реліз пройшов успішно. Коли зловмисники пізніше отримують токен автоматизації зі скомпрометованого складального завдання, їм не потрібен ані експлойт ядра, ані новий вихід із контейнера. Вони використовують права, уже надані сервісному акаунту: створюють привілейовані робочі навантаження, монтують чутливі томи й перетворюють компрометацію CI на загальнокластерну операцію з відновлення, що вимагає термінової ротації облікових даних, перегляду навантажень та очищення прив’язок.

RBAC — це запобіжник, який вирішує, чи дозволено автентифікований запит до Kubernetes після того, як API-сервер дізнався, хто його зробив. Автентифікація відповідає на запитання «хто ви?», авторизація — «чи може цей суб’єкт виконати це дієслово над цим ресурсом у цій області?», а допуск (admission), який спрацьовує після авторизації, — «чи прийнятний цей об’єкт?». Якщо рішення про авторизацію надто щедре, кожному іншому засобу контролю доводиться працювати важче. Якщо ж воно надто вузьке або заплутане, оператори починають обходити модель за допомогою аварійних прив’язок, які стають постійним ризиком.

Цей модуль розглядає RBAC як інженерну задачу проєктування, а не як перелік назв об’єктів для запам’ятовування. Ви дізнаєтеся, як Role, ClusterRole, RoleBinding, ClusterRoleBinding, користувачі, групи та сервісні акаунти поєднуються у фактичні права; чому на перший погляд безневинні дієслова на кшталт create можуть стати шляхами ескалації; і як міркувати про доступ ще до застосування маніфесту. Коли в цьому модулі згадуються перевірки в командному рядку, використовується короткий псевдонім alias k=kubectl, тож команда на кшталт k auth can-i get pods -n production означає стандартну клієнтську команду Kubernetes із коротшою назвою.

Концепції RBAC: суб’єкти, правила та прив’язки

RBAC розшифровується як Role-Based Access Control (рольовий контроль доступу), але назва приховує найважливішу деталь: Kubernetes надає права, з’єднуючи суб’єкта з набором правил через прив’язку. Суб’єкт — це автентифікована особа, наприклад людина-користувач, зовнішня група ідентичності або сервісний акаунт, змонтований у Pod. Правило описує дії над ресурсами, наприклад get pods у головній групі API або update deployments у групі API apps. Прив’язка — це фактичне надання прав, і без прив’язки означення ролі є лише невикористаним шаблоном дозволів.

Уявіть RBAC як систему безпеки корпоративного офісу. Перепустку можна запрограмувати так, щоб вона відчиняла лише комору, лише третій поверх або кожні двері в будівлі, але перепустка має значення тільки після того, як хтось її отримав. Стійка доступу також має знати, ким є людина — працівником, підрядником чи сервісним технічним фахівцем, — бо та сама політика перепусток може бути доречною для однієї особи й небезпечною для іншої. Kubernetes дотримується того самого взірця із суб’єктами, ролями та прив’язками, тільки двері тут — це ресурси API, а дії над дверима — це дієслова на кшталт get, list, create, patch та delete.

┌─────────────────────────────────────────────────────────────┐
│              RBAC BUILDING BLOCKS                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  WHO                           WHAT                        │
│  (Subjects)                    (Rules)                     │
│  ┌─────────────┐              ┌─────────────┐              │
│  │ Users       │              │ Verbs       │              │
│  │ Groups      │              │ Resources   │              │
│  │ ServiceAccts│              │ API Groups  │              │
│  └──────┬──────┘              └──────┬──────┘              │
│         │                            │                      │
│         │         BINDING            │                      │
│         │      (Connection)          │                      │
│         │     ┌───────────┐          │                      │
│         └────→│ Role      │←─────────┘                      │
│               │ Binding   │                                 │
│               └───────────┘                                 │
│                                                             │
│  Role = Collection of permissions (verbs on resources)     │
│  Binding = Connects subjects to roles                      │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Діаграма навмисно проста, бо кожен перегляд RBAC починається з тих самих трьох запитань. Хто є суб’єктом? Які саме правила надано? Де область дії прив’язки? Дивовижно велика кількість інцидентів виникає через відповідь лише на одне з цих запитань. Команда переглядає Role і бачить скромні дієслова, але не помічає, що ClusterRoleBinding надає її скрізь. Інша команда переглядає RoleBinding і бачить лише один сервісний акаунт, але не помічає, що токен цього сервісного акаунта змонтовано в навантаження, контрольоване ширшою системою CI.

RBAC є адитивним, тобто Kubernetes не підтримує правил заборони всередині самого RBAC. Якщо одна прив’язка надає view, а інша надає get secrets, суб’єкт має обидва права. Це здається природним, коли ви додаєте доступ для команди, але стає небезпечним, коли адміністратори припускають, що безпечніша роль може скасувати ризиковану. Вона не може. Фактичний набір прав — це об’єднання кожного відповідного надання для цього користувача, групи та сервісного акаунта.

Отже, перегляд RBAC — це радше задача про граф, ніж перегляд файлу. Ризиковане надання може бути не в маніфесті, який ви зараз редагуєте; воно може бути в старішому ClusterRoleBinding, у групі провайдера ідентичності або в сервісному акаунті, який використовує контролер. Коли рецензент запитує «чи може це навантаження читати продакшн-Secret’и?», відповідь криється в поєднанні суб’єктів, прив’язок, посилань на ролі, області простору імен та успадкованого членства в групах. Читати лише нову Role — це як перевіряти одні двері в будівлі, ігноруючи майстер-перепустку, уже видану тій самій людині.

Ця адитивна модель також змінює спосіб виправлення помилок. Видалення підозрілого RoleBinding може не прибрати право, якщо інша прив’язка надає те саме правило через групу. Звуження Role може не допомогти, якщо ClusterRoleBinding надає ширшу ClusterRole тому самому суб’єкту. Хороші оператори виробляють звичку доводити обидві сторони: дозволену дію, потрібну для робочого процесу, та заборонену дію, яка вказувала б на перевищення прав.

Зупиніться й передбачте: Якщо RBAC дозволяє лише адитивні права, що станеться, коли група має безпечну прив’язку лише для читання, а один користувач у цій групі також отримує пряму прив’язку, яка надає доступ до секретів? Перш ніж читати далі, визначте, яка прив’язка переможе і як ви довели б це за допомогою k auth can-i.

Пряма відповідь: застосовуються обидві прив’язки, тож пряме право на секрети дозволено. Авторизація Kubernetes не обирає одну прив’язку замість іншої й не ставить надання групі нижче за надання користувачеві з метою скасування. Саме тому перегляди фактичного доступу мають збирати всіх суб’єктів, пов’язаних із запитом: ім’я користувача, групи, надані автентифікацією, та ідентичність сервісного акаунта, коли запит надходить від Pod.

Role, ClusterRole та область дії

Область дії RBAC — це перше проєктне рішення, бо саме воно визначає радіус ураження (blast radius) помилки. Role належить простору імен, тож її правила діють лише всередині одного простору імен і лише для ресурсів цього простору. ClusterRole має кластерну область, тобто вона може описувати права на кластерні ресурси, як-от вузли, постійні томи та простори імен. ClusterRole також можна повторно використати всередині простору імен, коли на неї вказує RoleBinding, — це корисний взірець, коли багатьом просторам імен потрібна однакова форма прав без надання доступу до кожного простору імен.

┌─────────────────────────────────────────────────────────────┐
│              ROLE SCOPE                                     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ROLE (Namespace-scoped)                                   │
│  ├── Defines permissions within a single namespace         │
│  ├── Can only reference namespace-scoped resources         │
│  └── Bound with RoleBinding                                │
│                                                             │
│  CLUSTERROLE (Cluster-scoped)                              │
│  ├── Defines permissions cluster-wide                      │
│  ├── Can reference any resource (including cluster-wide)   │
│  ├── Can be bound with:                                    │
│  │   ├── ClusterRoleBinding (cluster-wide access)          │
│  │   └── RoleBinding (namespace-scoped access)             │
│  └── Used for cluster-wide resources or reusable roles     │
│                                                             │
│  WHEN TO USE WHAT:                                         │
│  • Single namespace permissions → Role + RoleBinding       │
│  • Same role in multiple namespaces → ClusterRole +        │
│    RoleBinding per namespace                               │
│  • Cluster-wide permissions → ClusterRole +                │
│    ClusterRoleBinding                                      │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Поширена помилка початківця — вважати ClusterRole синонімом кластерного надання прав. Це не так. ClusterRole — це багаторазове означення, тоді як прив’язка визначає, де це означення надано. Якщо ви прив’язуєте ClusterRole за допомогою RoleBinding у просторі імен dev, суб’єкт отримує ці правила лише в dev для ресурсів простору імен. Якщо ж ви прив’язуєте ту саму ClusterRole за допомогою ClusterRoleBinding, суб’єкт отримує правила в усьому кластері, зокрема в майбутніх просторах імен, про які ніхто не думав під час початкового запиту на зміну.

Ця різниця корисна в реальних платформних командах. Припустімо, п’ятьом продуктовим просторам імен потрібен однаковий доступ лише для читання до Deployment’ів та Service’ів. Створення п’яти однакових Role спрацює, але означення з часом розходяться, коли один простір імен пропатчили, а про інший забули. Кращий підхід — це часто одна ClusterRole, що визначає спільний набір прав, плюс одна RoleBinding на простір імен, яка на неї посилається. Ви зберігаєте одне центральне означення, водночас роблячи надання прав у просторах імен явними та придатними для перегляду.

Протилежна ситуація — це контролер кластерного рівня, який має спостерігати за просторами імен чи вузлами. Role не може описати ці ресурси, бо вони не живуть усередині простору імен. У такому разі потрібна ClusterRole, а ClusterRoleBinding може бути виправданою, якщо контролеру справді потрібно працювати в усьому кластері. Питання безпеки не «чи завжди ClusterRole погана?»; питання — «чи відповідає область дії прив’язки операційній потребі?».

# Namespace-scoped Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
- apiGroups: [""]           # "" = core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Ця Role надає лише три дієслова читання над Pod’ами у просторі імен production. Порожній рядок у apiGroups вказує на головну групу API Kubernetes, яка містить Pod’и, Service’и, ConfigMap’и, Secret’и та кілька інших фундаментальних ресурсів. Role не надає доступу до Deployment’ів, бо Deployment’и є в групі API apps, і вона не надає доступу до Pod’ів в іншому просторі імен, бо область дії Role зупиняється на межі простору імен.

# Cluster-scoped ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-reader
rules:
- apiGroups: [""]
  resources: ["nodes"]      # Cluster-scoped resource
  verbs: ["get", "watch", "list"]

Ця ClusterRole може описувати доступ до Node’ів, бо Node’и є ресурсами кластерної області. Якщо системі моніторингу потрібно читати об’єкти вузлів для інвентаризації, сигналів планування чи звітів про ємність, ClusterRole такого вигляду може бути доречною. Якщо ж розробнику потрібно лише оглядати Pod’и в одному просторі імен, ця форма буде хибною, бо вона сягає кластерної інфраструктури, а не ресурсів, якими володіє застосунок.

Складники правила

Складник	Опис	Приклади
apiGroups	Група API, що містить ресурс	"" (core), "apps", "networking.k8s.io"
resources	Типи ресурсів	"pods", "deployments", "secrets"
verbs	Дозволені дії	"get", "list", "create", "delete"
resourceNames	Конкретні назви ресурсів (необов’язково)	["my-configmap"]

Кожне правило — це кортеж із групи API, ресурсу, необов’язкової назви ресурсу та дієслова. Можна сприймати його як речення: «дозволити цьому суб’єкту виконувати ці дії над цими типами ресурсів у цій групі API, за бажанням лише для цих іменованих об’єктів». Точне формулювання має значення, бо схожі назви ресурсів можуть жити в різних групах API, а субресурси на кшталт pods/log та pods/exec є окремими цілями авторизації, відмінними від самого pods.

Поширені дієслова

┌─────────────────────────────────────────────────────────────┐
│              RBAC VERBS                                     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  READ OPERATIONS                                           │
│  ├── get      - Read a single resource                     │
│  ├── list     - List all resources                         │
│  └── watch    - Watch for changes                          │
│                                                             │
│  WRITE OPERATIONS                                          │
│  ├── create   - Create new resources                       │
│  ├── update   - Update existing resources                  │
│  ├── patch    - Partially update resources                 │
│  └── delete   - Delete resources                           │
│                                                             │
│  SPECIAL VERBS                                             │
│  ├── deletecollection - Delete multiple resources          │
│  ├── bind     - Bind roles (for RoleBindings)              │
│  ├── escalate - Grant role permissions beyond your own     │
│  ├── impersonate - Act as another user                     │
│  └── * (wildcard) - All verbs (DANGEROUS)                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Дієслова читання не є автоматично безневинними. Перелік Pod’ів може розкрити назви образів, назви змінних середовища, розміщення на вузлах, мітки та операційну структуру. Отримання Secret’ів очевидно чутливе, але отримання ConfigMap’ів теж може розкрити внутрішні точки доступу, прапорці функцій (feature flags) та деталі інтеграцій, які допомагають зловмиснику рухатися горизонтально. Спостереження за ресурсами дає довготривалий потік змін у кластері, що може розкривати нові навантаження або щойно створені об’єкти, щойно вони з’являються.

Дієслова запису заслуговують на ще пильнішу увагу, бо об’єкти Kubernetes часто містять інші об’єкти. Створення Deployment’а також створює Pod’и через контролер. Патчинг Deployment’а може змінити шаблон Pod’а, змонтувати Secret, замінити сервісний акаунт або додати образ із ворожого реєстру, якщо засоби контролю допуску цьому не завадять. Пряме створення Pod’а може дозволити суб’єкту запросити host-шляхи, привілейовані налаштування чи монтування Secret’ів, що перетворює просте на вигляд дієслово на можливий шлях ескалації.

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

Прив’язування особистостей до прав

Role чи ClusterRole нічого не робить, доки прив’язка не з’єднає її із суб’єктом. RoleBinding’и — це об’єкти простору імен, і вони можуть посилатися або на Role в тому самому просторі імен, або на ClusterRole як багаторазове означення. ClusterRoleBinding’и — це об’єкти кластерної області, і вони можуть посилатися лише на ClusterRole, бо Role простору імен не можна надати в усьому кластері. Це дає три поширені взірці надання прав: Role плюс RoleBinding для одного простору імен, ClusterRole плюс RoleBinding для багаторазового доступу в межах простору імен, та ClusterRole плюс ClusterRoleBinding для справжнього кластерного доступу.

# Binds Role to users/groups in a namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: production
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: developers
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
  name: my-app
  namespace: production
roleRef:
  kind: Role                    # or ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Цей RoleBinding надає згадану Role pod-reader усередині production трьом формам суб’єктів. Люди-користувачі та зовнішні групи зазвичай надходять із рівня автентифікації кластера, як-от клієнтські сертифікати, OpenID Connect чи інтеграція з хмарним провайдером. Сервісні акаунти — це рідні особистості Kubernetes, і їхній простір імен є частиною ідентичності. Сервісний акаунт my-app у production — це не той самий суб’єкт, що сервісний акаунт my-app у staging.

# Cluster-wide binding
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-nodes-everywhere
subjects:
- kind: Group
  name: operations
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: node-reader
  apiGroup: rbac.authorization.k8s.io

Цей ClusterRoleBinding надає групі operations ClusterRole node-reader в усьому кластері. Для центральної операційної команди, яка обслуговує стан вузлів, це може бути виправдано. Для прикладної команди, якій потрібно лише усувати несправності навантажень в одному просторі імен, це було б надто широко. Різниця не синтаксична; різниця в тому, чи відображає область дії прив’язки бізнесову та операційну межу.

Посилання на ролі (roleRef) у Kubernetes незмінні. Якщо ви створили RoleBinding, що вказує на хибну Role, ви не можете пропатчити лише roleRef, щоб це виправити; ви видаляєте та повторно створюєте прив’язку. Така поведінка навмисна, бо зміна roleRef в наявній прив’язці могла б непомітно перетворити безневинне надання прав на потужне, зберігши ту саму назву прив’язки. У робочих процесах GitOps це також робить перегляди чіткішими, бо заміна прив’язки має очевидніший diff, ніж зміна сенсу наявного надання.

Перед запуском будь-якого маніфесту RBAC перевірте свою уявну модель за допомогою k auth can-i. Якщо ви плануєте дати розробнику доступ на читання Pod’ів, але не Secret’ів, спитайте API-сервер саме про це: k auth can-i get pods -n production --as alice та k auth can-i get secrets -n production --as alice. Для сервісних акаунтів використовуйте канонічну форму імені користувача system:serviceaccount:namespace:name і пам’ятайте, що членство в групах для сервісних акаунтів також існує через групи сервісних акаунтів.

Перш ніж це запустити, який результат ви очікуєте? Уявіть, що RoleBinding у dev посилається на ClusterRole view, тоді як ClusterRoleBinding надає тій самій групі get secrets скрізь. Передбачте результат k auth can-i get secrets -n dev --as alice --as-group developers, а потім поясніть, яка прив’язка спричинила цей результат.

Очікуваний результат — «yes», якщо наданий користувач і група відповідають широкому наданню секретів. RoleBinding до view не охоплює Secret’и, але й не забороняє Secret’и. Окремий ClusterRoleBinding додає ще одне дозволене правило, і остаточне рішення про авторизацію бачить об’єднання. Саме тому перевірки в командному рядку найцінніші, коли ви тестуєте і бажаний доступ, і доступ, якого ви явно не хочете.

Аудит фактичного доступу

Аудит RBAC починається із запиту, а не з маніфесту. Перевірка авторизації Kubernetes містить користувача, нуль або більше груп, дієслово, групу API, ресурс або субресурс, простір імен (коли застосовно) та іноді назву ресурсу. Якщо будь-яке правило, досяжне через будь-яку прив’язку, відповідає цим атрибутам запиту, запит дозволено. Саме тому найнадійніше запитання аудиту є конкретним: «Чи може system:serviceaccount:cicd:cicd-deployer патчити Deployment’и в staging і чи може він читати Secret’и в production?»

Корисний робочий процес аудиту має три проходи. Перший прохід інвентаризує суб’єктів і прив’язки, щоб ви знали, які особистості мають прямий чи груповий доступ. Другий прохід класифікує ролі за ризиком, виокремлюючи шаблони-зірочки, спеціальні дієслова, Secret’и, створення навантажень, керування ролями та кластерні надання прав. Третій прохід виконує репрезентативні позитивні та негативні перевірки авторизації проти API-сервера. Перші два проходи кажуть вам, що YAML начебто говорить, тоді як третій прохід підтверджує, як API-сервер насправді оцінює суб’єкт.

Сервісні акаунти заслуговують на окремий прохід, бо вони часто менш помітні за людей-користувачів. Людську ідентичність можна переглянути через провайдера ідентичності, робочий процес заявок чи реєстр команди, але сервісний акаунт можна створити всередині простору імен, а потім змонтувати в Pod. Якщо цей Pod контролюється системою розгортання, оператором чи скомпрометованим навантаженням, права сервісного акаунта стають правами навантаження. Тому аудит має пов’язувати кожну прив’язку сервісного акаунта з навантаженнями, які можуть його використати.

Субресурси — це ще одна поширена сліпа зона аудиту. Доступ до pods — це не те саме, що доступ до pods/log, pods/exec чи pods/portforward. Розробнику можуть бути потрібні логи для усування несправностей без потреби в інтерактивному доступі до оболонки контейнерів. Інструменту підтримки може знадобитися спостерігати за Pod’ами без потреби їх створювати. Точні правила субресурсів дозволяють підтримувати реальні операції, не надаючи ширшого права на ресурс, ніж вимагає робочий процес.

Назви ресурсів можуть звузити деякі права, але вони не є універсальною відповіддю. Role може обмежити get чи update до іменованого ConfigMap’а, що корисно для навантаження, яке читає один відомий об’єкт конфігурації. Та сама техніка стає незручною для ресурсів, створюваних динамічно, і вона не усуває потреби переглядати дієслова та область дії прив’язки. Використовуйте resourceNames, коли ідентичність об’єкта стабільна, але не покладайтеся на них, щоб виправити інакше широку роль.

Висновки аудиту слід формулювати мовою, на яку можуть зреагувати і платформні, і прикладні команди. «Шаблон-зірочка для дієслова на головних ресурсах» технічно точно, але «цей токен розгортання може видалити кожен ConfigMap і Secret у staging» створює кращу нагальність. Так само «ClusterRoleBinding до edit» менш корисно, ніж «учасники цієї групи можуть змінювати більшість ресурсів простору імен у кожному просторі імен, зокрема у просторах, створених пізніше». Переклад синтаксису RBAC в операційні наслідки — це частина роботи з безпеки.

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

Вбудовані ролі та агрегація

Kubernetes постачається із типовими ClusterRole, які охоплюють поширені адміністративні та орієнтовані на користувача взірці. Ці ролі зручні, але зручність не повинна замінювати перегляд. Вбудована роль cluster-admin — це по суті повна влада. Роль admin потужна всередині простору імен і може керувати там ролями й прив’язками. Роль edit може змінювати багато ресурсів простору імен, тоді як view доступна лише для читання для багатьох ресурсів і навмисно виключає Secret’и. Це відправні точки, а не заміна розумінню межі вашого навантаження.

┌─────────────────────────────────────────────────────────────┐
│              BUILT-IN CLUSTERROLES                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  USER-FACING ROLES                                         │
│                                                             │
│  cluster-admin                                             │
│  ├── Full access to everything                             │
│  ├── Can do anything in any namespace                      │
│  └── DANGEROUS - use sparingly                             │
│                                                             │
│  admin                                                     │
│  ├── Full access within a namespace                        │
│  ├── Can create roles/bindings in namespace                │
│  └── Use for namespace administrators                      │
│                                                             │
│  edit                                                      │
│  ├── Read/write to most namespace resources                │
│  ├── Cannot view or modify roles/bindings                  │
│  └── Use for developers                                    │
│                                                             │
│  view                                                      │
│  ├── Read-only access to most namespace resources          │
│  ├── Cannot see secrets                                    │
│  └── Use for auditors, observers                           │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Виключення Secret’ів роллю view — це гарний приклад того, як безпекове проєктування Kubernetes зустрічається з операційною реальністю. Багатьом командам потрібно бачити Pod’и, Service’и, Deployment’и, Event’и та ConfigMap’и під час усування несправностей, але читання Secret’ів розкрило б облікові дані та сервісні токени. Тому прив’язка view безпечніша за створення широкої власної ролі для читання з resources: ["*"], але вона не є повною межею політики. Друга прив’язка все одно може додати доступ до секретів, а суб’єкт із доступом на запис до навантажень усе одно може спричинити монтування Secret’ів у Pod’и, якщо це дозволяють інші засоби контролю.

Системні ролі

┌─────────────────────────────────────────────────────────────┐
│              SYSTEM CLUSTERROLES                            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  system:* roles are for Kubernetes components              │
│                                                             │
│  system:kube-scheduler                                     │
│  └── Permissions for the scheduler                         │
│                                                             │
│  system:kube-controller-manager                            │
│  └── Permissions for controller manager                    │
│                                                             │
│  system:node                                               │
│  └── Permissions for kubelets (with Node authorization)    │
│                                                             │
│  system:masters group                                      │
│  └── Bound to cluster-admin (full access)                  │
│  └── Certificate O=system:masters = cluster-admin          │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Системні ролі підтримують основні компоненти Kubernetes, і адміністратори мають сприймати їх як деталі реалізації, доки не оперують самою площиною управління. Редагування системних ролей може зламати контролери, kubelet’и чи поведінку планувальника так, що це матиме вигляд непов’язаної нестабільності кластера. Група system:masters особливо чутлива, бо сертифікати з цією організацією зазвичай прив’язані до cluster-admin. Якщо організація використовує клієнтські сертифікати, видача та зберігання сертифікатів стають частиною моделі загроз RBAC.

Агрегація ClusterRole додає ще один шар. Деякі ClusterRole автоматично складаються з інших ClusterRole, чиї мітки відповідають правилу агрегації. Вбудовані ролі admin, edit та view використовують цей взірець, щоб розширювальні API могли долучатися до орієнтованих на користувача ролей. Це корисно для CustomResourceDefinition’ів, бо платформа може помітити ClusterRole і зробити так, щоб ці права CRD з’явилися в стандартній ролі, але той самий механізм стає ризикованим, якщо ненадійні користувачі можуть створювати помічені ClusterRole.

# ClusterRole with aggregation rule
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-endpoints
  labels:
    rbac.example.com/aggregate-to-monitoring: "true"
rules:
- apiGroups: [""]
  resources: ["pods", "services", "endpoints"]
  verbs: ["get", "list", "watch"]
---
# Aggregating ClusterRole (combines all matching)
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/aggregate-to-monitoring: "true"
# Rules are automatically combined from aggregated roles
rules: []  # Populated by controller

Контролер агрегації наповнює правила агрегувальної ClusterRole, тож порожнє поле rules: [] не є помилкою. Операційний ризик — це контроль над мітками. Якщо суб’єкт може створити ClusterRole з міткою, обраною важливою агрегатною роллю, цей суб’єкт може отримати змогу додати права всім, прив’язаним до агрегату. Тому політика допуску та правила перегляду мають сприймати мітки агрегації як привілейовану конфігурацію, а не як безневинні метадані.

Для міркувань рівня KCSA агрегація менше стосується запам’ятовування механіки контролера й більше — розпізнавання непрямих змін прав. Diff, що додає мітку до ClusterRole, може бути таким самим важливим, як diff, що редагує перелік правил. Якщо мітку обрано агрегатною роллю, прив’язаною до багатьох користувачів, ця маленька зміна метаданих може розширити доступ для великої групи. Це той самий урок, що й адитивний RBAC у іншій формі: права можуть надходити через зв’язки, не очевидні з об’єкта, який переглядають.

Найменші привілеї та небезпечні права

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

┌─────────────────────────────────────────────────────────────┐
│              LEAST PRIVILEGE RBAC                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  BAD: Overly permissive                                    │
│  rules:                                                    │
│  - apiGroups: ["*"]        # All API groups                │
│    resources: ["*"]        # All resources                 │
│    verbs: ["*"]            # All actions                   │
│                                                             │
│  GOOD: Precisely scoped                                    │
│  rules:                                                    │
│  - apiGroups: [""]                                         │
│    resources: ["pods"]                                     │
│    verbs: ["get", "list"]                                  │
│  - apiGroups: [""]                                         │
│    resources: ["pods/log"]                                 │
│    verbs: ["get"]                                          │
│                                                             │
│  GUIDELINES:                                               │
│  • Use namespace-scoped roles when possible                │
│  • Avoid wildcards (*)                                     │
│  • Grant specific verbs, not ["*"]                         │
│  • Prefer RoleBinding over ClusterRoleBinding              │
│  • Review and audit regularly                              │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Шаблони-зірочки заслуговують на особливу увагу, бо вони охоплюють ресурси та дієслова, яких може не існувати на момент написання ролі. Зірочка для ресурсів може охопити майбутні CustomResourceDefinition’и, а зірочка для дієслів може охопити операційні дії, яких автор не передбачив. Це особливо ризиковано в платформних кластерах, де команди з часом додають оператори. Роль, що в січні мала вигляд широкого зручного надання прав, може непомітно стати доступом до нового продакшн-CRD бази даних пізніше того ж року.

┌─────────────────────────────────────────────────────────────┐
│              DANGEROUS RBAC PERMISSIONS                     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  PRIVILEGE ESCALATION RISKS:                               │
│                                                             │
│  CREATE pods                                               │
│  └── Can create privileged pods, escape to host            │
│                                                             │
│  CREATE/UPDATE roles/rolebindings                          │
│  └── Can grant themselves more permissions                 │
│                                                             │
│  GET secrets                                               │
│  └── Can read all secrets (tokens, passwords)              │
│                                                             │
│  IMPERSONATE users/groups                                  │
│  └── Can act as any user                                   │
│                                                             │
│  EXEC into pods                                            │
│  └── Can run commands in any container                     │
│                                                             │
│  CREATE serviceaccounts + secrets                          │
│  └── Can create tokens for any service account             │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Небезпечні права на діаграмі небезпечні, бо вони з’єднують RBAC з іншими площинами управління. Створення Pod’ів — це не лише про створення Pod’ів; це про вибір сервісного акаунта, монтування томів, запит host-доступу, вибір образів та запуск політики допуску. Отримання Secret’ів — це не лише про читання одного об’єкта; воно може розкрити паролі баз даних, облікові дані реєстру та застарілі токени сервісних акаунтів. Уособлення (impersonation) — це не лише про налагодження; воно може перетворити одну особистість на багато, якщо область уособлення широка.

Зупиніться й передбачте: Сервісний акаунт має право create на Pod’и, але не має права get на Secret’и. Чи може він усе одно отримати доступ до Secret’ів у просторі імен? Продумайте, як щойно створений Pod може змонтувати Secret, навіть коли суб’єкт, що його створює, не може прочитати цей Secret напряму.

Відповідь залежить від навколишніх засобів контролю, тому RBAC має оцінюватися разом із політикою допуску та проєктуванням просторів імен. У багатьох конфігураціях суб’єкт, який може створювати Pod’и, може створити специфікацію Pod’а, що посилається на Secret як на том чи джерело змінних середовища, а потім прочитати дані зсередини контейнера. RBAC Kubernetes блокує прямий API-запит get secrets, але шлях через навантаження все одно може розкрити дані. Pod Security Standards, контролери допуску, ретельний вибір сервісних акаунтів та розділення просторів імен — усе це допомагає закрити цю прогалину.

Проєктування сервісного акаунта — це місце, де все стає практичним. Прикладні Pod’и не мають працювати з типовим сервісним акаунтом, який випадково отримав широкі права, бо хтось хотів швидкого виправлення. Автоматизація розгортання має мати окрему ідентичність, у виокремленому просторі імен, коли це можливо, з правами, обмеженими ресурсами, якими вона насправді керує. Люди-користувачі зазвичай мають отримувати доступ через групи, а не через одноразові прив’язки користувачів, бо групові надання прав легше переглядати й відкликати, коли люди змінюють команди.

# Create a ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app
  namespace: production
---
# Create a Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: configmap-reader
  namespace: production
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list"]
---
# Bind the Role to the ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: my-app-configmap-reader
  namespace: production
subjects:
- kind: ServiceAccount
  name: my-app
  namespace: production
roleRef:
  kind: Role
  name: configmap-reader
  apiGroup: rbac.authorization.k8s.io
---
# Use the ServiceAccount in a Pod
apiVersion: v1
kind: Pod
metadata:
  name: my-app
  namespace: production
spec:
  serviceAccountName: my-app
  # ...

Цей приклад навмисно вузький. Застосунок отримує лише get та list на ConfigMap’и у власному просторі імен, чого достатньо для багатьох читачів конфігурації й недостатньо, щоб змінювати навантаження, читати Secret’и чи оглядати кластерну інфраструктуру. Якщо застосунку пізніше знадобиться інше право, перегляд має запитати, який шлях коду його вимагає, чи можна звузити право до іменованого ресурсу і чи має натомість навантаження отримувати конфігурацію через безпечніший механізм доставки.

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

Є також перевага для людського робочого процесу. Розробники охочіше запитують точний доступ, коли платформна команда відповідає швидко й пояснює модель. Якщо кожен запит доступу стає тижневими перемовинами, команди шукатимуть обхідні шляхи та спільні облікові дані. Хороша програма RBAC поєднує суворі надання прав із чіткими прикладами, багаторазовими шаблонами ролей та швидкими шляхами перегляду для поширених робочих процесів. Найменші привілеї досягають успіху, коли робити правильно простіше, ніж обходити процес.

Взірці та хибні взірці

Хороші проєкти RBAC нудні в експлуатації, бо їхні межі збігаються з межами команд. Продуктова команда може оглядати й розгортати у власному просторі імен, не торкаючись платформних контролерів. Сервіс моніторингу може читати об’єкти, потрібні для телеметрії, не володіючи кластером. Конвеєр релізів може оновлювати Deployment’и в staging, не читаючи продакшн-Secret’и. Робота з проєктування здебільшого полягає в опорі обхідним шляхам, які руйнують ці межі під час першого інциденту чи тиску релізу.

Взірець	Коли застосовувати	Чому працює	Міркування щодо масштабування
Означення ClusterRole плюс RoleBinding’и в просторах імен	Багатьом просторам імен потрібні однакові права в межах простору імен	Одне багаторазове означення прав запобігає дрейфу, тоді як кожне надання прав у просторі імен лишається явним	Автоматизуйте створення RoleBinding через GitOps, щоб нові простори імен не пропускали потрібного доступу непомітно
Доступ людей на основі груп	Доступ належить команді, а не одній особі	Групи провайдера ідентичності роблять онбординг та офбординг придатними для аудиту	Переглядайте відповідності груп до прив’язок під час змін у командах та ретроспектив інцидентів
Виокремлений сервісний акаунт на клас навантаження	Застосунки, контролери та CI-завдання мають різні рівні довіри	Скомпрометований токен розкриває лише фактичні права цього навантаження	Іменуйте сервісні акаунти за навантаженням і уникайте спільного використання між непов’язаними контролерами
Негативні тести k auth can-i	Перегляд нової чи зміненої прив’язки	Тестування заборонених дій ловить адитивні надання прав, які легко пропустити, читаючи один маніфест	Зберігайте репрезентативні перевірки в runbook’ах чи політичних тестах CI для чутливих просторів імен

Хибні взірці зазвичай з’являються, коли команди оптимізують негайний успіх замість майбутньої придатності до аудиту. Найпоширеніша версія — це надання cluster-admin застосунку чи конвеєру, бо розгортання провалилося, а ніхто не мав часу визначити відсутнє дієслово. Інша версія — це запис apiGroups: ["*"], resources: ["*"] та verbs: ["*"] у роль, бо автор хоче уникнути майбутніх заявок до підтримки. Ці рішення виносять складність із YAML у процес реагування на інциденти, де вона значно дорожча.

Хибний взірець	Що йде не так	Краща альтернатива
Прив’язування cluster-admin до прикладних сервісних акаунтів	Будь-яка компрометація навантаження стає повною компрометацією кластера	Створіть власну Role для точних ресурсів, яких торкається застосунок
Використання ClusterRoleBinding для одного простору імен	Доступ слідує за суб’єктом у кожен простір імен, зокрема в майбутні	Використовуйте RoleBinding, що посилається на Role чи багаторазову ClusterRole
Надання шаблонів-зірочок, щоб уникнути усування несправностей	Майбутні ресурси та дієслова стають дозволеними без перегляду	Почніть зі спостережених потрібних дієслів і додавайте вузько після тестування
Дозвіл командам вільно створювати мітки агрегації	Агреговані ролі можуть отримати неочікувані права	Захищайте мітки агрегації політикою допуску та оглядом коду
Спільне використання одного сервісного акаунта розгортання між середовищами	Компрометація staging може сягнути продакшн-прав	Використовуйте окремі особистості та прив’язки на кожне середовище

Помилка	Чому це шкодить	Розв’язання
Використання cluster-admin для застосунків	Надто багато доступу	Створіть конкретні ролі
Шаблони-зірочки у продакшні	Надає більше, ніж задумано	Зазначте точні ресурси/дієслова
ClusterRoleBinding для потреб простору імен	Кластерний доступ, коли достатньо простору імен	Використовуйте RoleBinding
Неперегляд типового SA	Може мати ненавмисні права	Аудит прив’язок типового SA
Спільні ролі для різних команд	Не можна відкликати окремо	Ролі для конкретних команд

Компактна таблиця вище корисна як швидкий чек-лист перегляду, але вона не має бути єдиним артефактом перегляду для серйозної зміни. Продакшн-перегляд RBAC має охоплювати запитуваний робочий процес, ідентичність суб’єкта, точні ресурси та дієслова, область простору імен чи кластера, очікувані негативні перевірки та план відкату. Якщо роль не можна пояснити в цих термінах, вона зазвичай надто широка, надто хитра або належить не тій команді.

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

Інший тривкий взірець — сприймати маніфести RBAC як продакшн-код. Їх слід переглядати, вести під контролем версій, тестувати й відкочувати з такою самою ретельністю, як розгортання застосунків. Однорядкова прив’язка може бути чутливішою за сотню рядків конфігурації застосунку, бо вона змінює те, хто може змінювати кластер. Історія Git також дає тим, хто реагує, контекст під час інцидентів: хто схвалив надання прав, який запит воно обслуговувало і які негативні перевірки мали лишатися забороненими.

Структура прийняття рішень

Використовуйте область дії прив’язки як першу розгалуження. Якщо суб’єкту потрібно працювати в одному просторі імен, почніть із Role та RoleBinding у цьому просторі імен. Якщо кільком просторам імен потрібен однаковий набір прав у межах простору імен, визначте одну ClusterRole і прив’яжіть її окремо в кожному просторі імен за допомогою RoleBinding’ів. Якщо суб’єкту потрібні ресурси кластерної області або справді всі простори імен, використовуйте ClusterRole і розгляньте ClusterRoleBinding, але вимагайте сильнішого обґрунтування, бо радіус ураження більший.

Якщо суб’єкту потрібен лише один простір імен, використовуйте Role плюс RoleBinding. Якщо ті самі правила простору імен потрібні в кількох просторах імен, використовуйте ClusterRole плюс одну RoleBinding на простір імен. Якщо суб’єкту потрібні ресурси кластерної області на кшталт вузлів чи просторів імен, використовуйте ClusterRole плюс ретельно переглянутий ClusterRoleBinding. Якщо запит охоплює керування ролями, уособлення, прив’язування, ескалацію, пряме створення Pod’ів чи широкий доступ до Secret’ів, сприймайте його як робочий процес адміністрування платформи, навіть якщо запитувач описує його як прикладну задачу.

Після вибору області дії оцінюйте дієслова як поверхні ескалації, а не як ярлики. Доступ на читання до Pod’ів та Event’ів може бути нормальним для усування несправностей, але доступ на читання до Secret’ів — це розкриття облікових даних. Доступ на запис до Deployment’ів може бути прийнятним для конвеєра розгортання, але пряме створення Pod’а може обходити засоби контролю вищого рівня. Зміна Role та RoleBinding — це адміністрування, а не розгортання застосунку. Уособлення та ескалація — це платформні повноваження, і вони мають бути достатньо рідкісними, щоб кожне надання прав мало власника й зафіксовану причину.

Вимога	Надайте перевагу цьому	Уникайте цього	Питання для перегляду
Розробники оглядають навантаження в dev	RoleBinding до view чи власна Role для читання	ClusterRoleBinding до view	Чи мають вони бачити кожен простір імен, чи лише свій?
CI оновлює Deployment’и в staging	Виокремлений сервісний акаунт із дієсловами для Deployment у staging	Спільний CI-сервісний акаунт із дієсловами-зірочками	Чи може цей токен торкнутися продакшну, якщо його вкрадуть?
Моніторинг читає Pod’и в усіх просторах імен	ClusterRoleBinding до вузької ClusterRole для читання	cluster-admin чи широка edit	Чи потрібні моніторингу Secret’и, exec чи дієслова запису?
Тимлід керує ConfigMap’ами та Secret’ами	Власна Role у просторі імен команди	Додавання всіх членів команди до admin	Чи обмежене керування секретами межею команди?
Оператор спостерігає за власними ресурсами	ClusterRole для потрібних груп API	resources: ["*"] для майбутніх CRD	Які CRD насправді є частиною цього контролера?

Найкраща звичка перегляду — записувати випадки відмови перед випадками дозволу. Наприклад, якщо запит каже «CI може розгортати в staging», негативними випадками можуть бути «CI не має отримувати продакшн-Secret’и», «CI не має створювати ClusterRoleBinding’и» та «CI не має уособлювати користувачів». Запуск чи документування цих негативних перевірок k auth can-i змушує команду подумати про те, чого успіх не має охоплювати. Це також дає майбутнім рецензентам компактний регресійний набір для моделі доступу.

Ця структура також має враховувати час. Деякий доступ тривкий, бо він відображає постійну відповідальність команди, тоді як інший доступ тимчасовий, бо він підтримує міграцію, інцидент чи одноразове вікно обслуговування. RBAC Kubernetes не прострочує прив’язки самостійно, тож тимчасові надання прав потребують процесної підтримки. Команди часто розв’язують це за допомогою pull-запитів GitOps, що містять дати видалення, запланованих заявок на перегляд чи автоматизації, яка позначає високопривілейовані прив’язки, старші за схвалене вікно.

Нарешті, вирішіть, як ви спостерігатимете за наданням прав після його застосування. Журнали аудиту можуть показати, чи використовує суб’єкт чутливе право, а оповіщення може виокремити створення ClusterRoleBinding’ів, зміни ролей із шаблонами-зірочками чи нові прив’язки до привілейованих ролей. Спостереження не робить небезпечне надання прав безпечним, але воно допомагає підтвердити припущення та виявити зловживання. Право, яке є водночас широким і ніколи не використовуваним, — сильний кандидат на видалення. Цей доказ дає рецензентам упевненість звужувати доступ, не вгадуючи продакшн-поведінку.

Довідник складників

Складник	Призначення	Область
Role	Визначає права	Простір імен
ClusterRole	Визначає права	Кластер
RoleBinding	Надає роль суб’єктам	Простір імен
ClusterRoleBinding	Надає роль суб’єктам	Кластер

Цей довідник простий, але він фіксує різницю, що запобігає багатьом помилкам RBAC. Role та ClusterRole визначають права; прив’язки їх надають. Role та RoleBinding належать простору імен; ClusterRole та ClusterRoleBinding мають кластерну область. Багаторазовий взірець, що збиває людей з пантелику, — це RoleBinding простору імен, що вказує на ClusterRole, який зберігає надання прав у межах простору імен, навіть попри те, що означення ролі зберігається в кластерній області.

Чи знали ви?

• RBAC за замовчуванням забороняє — якщо жодна роль не надає права, дію заборонено, і не існує правила «deny» в RBAC, яке могло б відняти доступ, наданий іншою прив’язкою.

• Існує захист від ескалації ролей — щоб створити RoleBinding до ролі, суб’єкту потрібне або дієслово bind на цій ролі, або всі права, що містяться в цій ролі.

• Роль view навмисно виключає Secret’и — це проєктне рішення дозволяє командам надавати широкий доступ на читання для усування несправностей без автоматичного розкриття облікових даних, токенів та приватних значень конфігурації.

• Шаблони-зірочки накопичуються з часом — використання resources: ["*"] може надати доступ до майбутніх ресурсів API та CustomResourceDefinition’ів, яких не було встановлено на момент схвалення ролі.

Типові помилки

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

Помилка	Чому вона трапляється	Як її виправити
Прив’язування cluster-admin до сервісного акаунта навантаження	Команда намагається швидко змусити невдале розгортання працювати й не знає, якого дієслова бракує	Використайте k auth can-i та події аудиту API, щоб знайти відсутнє право, а потім створіть вузьку Role чи ClusterRole
Використання resources: ["*"] та verbs: ["*"] у продакшні	Шаблони-зірочки здаються стійкими до майбутнього й зменшують кількість заявок до підтримки під час раннього розроблення	Замініть шаблони-зірочки іменованими групами API, ресурсами та дієсловами; перегляньте знову, коли вводяться нові CRD
Вибір ClusterRoleBinding для робочого процесу одного простору імен	Автор бачить ClusterRole у прикладі й припускає, що прив’язка теж має бути кластерної області	Використайте RoleBinding, навіть коли вона посилається на багаторазову ClusterRole, щоб надання прав лишалося всередині простору імен
Забування простору імен сервісного акаунта у прив’язці	Назви сервісних акаунтів мають вигляд локальних, тож автори прив’язують правильну назву в неправильному просторі імен	Завжди зазначайте namespace для суб’єктів-сервісних акаунтів і тестуйте повну ідентичність system:serviceaccount:namespace:name
Сприйняття create pods як звичайного доступу на запис	Створення Pod’а звучить вужче за володіння Deployment’ом, але Pod’и можуть монтувати Secret’и та запитувати ризиковані налаштування	Надавайте перевагу ресурсам навантажень вищого рівня із засобами контролю допуску й обмежуйте створення Pod’ів у чутливих просторах імен
Надання impersonate, bind чи escalate прикладним командам	Спеціальні дієслова хибно сприймаються як помічники для налагодження, а не як адміністративні повноваження	Резервуйте спеціальні дієслова для платформної автоматизації з оглядом власника, оповіщенням та явним простроченням, де можливо
Перегляд лише однієї Role замість фактичного доступу	Надання прав RBAC є адитивними між користувачами, групами та сервісними акаунтами	Перегляньте всі RoleBinding’и та ClusterRoleBinding’и для суб’єкта, а потім протестуйте і позитивні, і негативні випадки k auth can-i

Тест

Питання 1: Команді розробників потрібен доступ на читання до Deployment'ів та Service'ів рівно у п'яти просторах імен. Чи слід вам створити п'ять окремих Role чи одну ClusterRole, і як її прив'язати?

Створіть одну ClusterRole з get, list та watch на Deployment’и та Service’и, а потім створіть одну RoleBinding у кожному з п’яти просторів імен, що посилається на цю ClusterRole. Це зберігає означення прав багаторазовим, водночас тримаючи кожне надання прав явно прив’язаним до простору імен. ClusterRoleBinding був би надто широким, бо він надав би доступ у кожному просторі імен, зокрема в майбутніх просторах імен, які не були частиною запиту. П’ять окремих Role можуть спрацювати, але вони більш імовірно розійдуться під час пізніших редагувань.

Питання 2: Під час аудиту ви знаходите CI-сервісний акаунт із `create pods` та `get secrets` в одному просторі імен. Команда каже, що обидва права потрібні для розгортань. Який ризик ви пояснюєте першим?

Безпосередній ризик у тому, що CI-токен може читати облікові дані напряму й також може створювати Pod’и, які монтують чутливі дані чи запитують небезпечні налаштування виконання. Навіть якби команда прибрала прямий get secrets, створення Pod’а все одно могло б бути непрямим шляхом до розкриття секретів, якщо політика допуску та проєктування просторів імен цьому не запобігають. Безпечніший проєкт — це виокремлена ідентичність розгортання з вузькими дієсловами на Deployment’и, Service’и та потрібні ConfigMap’и в цільовому просторі імен. Доступ до секретів слід розділити, мінімізувати й протестувати негативними перевірками авторизації.

Питання 3: Сервісний акаунт має вбудовану роль `view` через RoleBinding і також має другу Role, що надає `get secrets`. Який фактичний дозвіл і чому?

Сервісний акаунт може читати Secret’и, бо RBAC Kubernetes є адитивним. Роль view виключає Secret’и, але це виключення не є правилом заборони й не скасовує іншого надання прав. Друга Role додає get secrets до фактичного набору прав, тож остаточне рішення дозволяє запит. Саме тому рецензенти мають оглядати всі прив’язки для суб’єкта, а не судити про доступ за однією знайомою назвою ролі.

Питання 4: Інструменту моніторингу потрібен доступ лише для читання до Pod'ів, Service'ів та Endpoint'ів у всіх просторах імен. Коли ви обрали б ClusterRoleBinding замість багатьох RoleBinding'ів?

Обирайте ClusterRoleBinding, коли інструмент централізовано керований, високо довірений і справді потребує покриття для всіх поточних і майбутніх просторів імен. Його простіше обслуговувати, і він уникає пропущеної телеметрії, коли з’являється новий простір імен. Обирайте RoleBinding’и на кожен простір імен, коли деякі простори імен достатньо чутливі, щоб вимагати явного увімкнення чи окремого схвалення. Компроміс — це операційна простота проти жорсткіших меж найменших привілеїв.

Питання 5: Група підрядників ніколи не має отримувати `cluster-admin`, але RBAC не має правил заборони. Як ви забезпечуєте дотримання цієї політики?

Ви забезпечуєте її дотримання поза простим RBAC, контролюючи, хто може створювати чи оновлювати ClusterRoleBinding’и, і використовуючи політику допуску, щоб відхиляти прив’язки, які приєднують cluster-admin до групи підрядників. Огляд GitOps також може блокувати небезпечні маніфести до того, як вони сягнуть API-сервера. Оповіщення аудиту мають повідомляти платформну команду, якщо високопривілейована прив’язка з’являється попри запобіжні засоби контролю. Ключова думка: адитивний RBAC не може виразити «ніколи не дозволяти цьому суб’єкту», тож заборону має забезпечити інша площина управління.

Питання 6: Команда операторів хоче використати агреговані ClusterRole для нового CustomResourceDefinition. Яка умова безпеки має бути істинною, перш ніж цей проєкт стане безпечним?

Лише довірена автоматизація чи адміністратори мають мати змогу створювати ClusterRole з мітками, обраними агрегатною роллю. Агрегація потужна, бо відповідні мітки змушують правила перетікати в агрегат автоматично, що означає, що контроль над мітками стає контролем над правами. Якщо ненадійні користувачі можуть створювати помічені ClusterRole, вони можуть отримати змогу додати права всім, прив’язаним до агрегатної ролі. Безпечний проєкт захищає мітки агрегації політикою допуску та оглядом коду.

Питання 7: Розробник може успішно виконати `k auth can-i get pods -n dev --as alice`, але доступ до продакшну також неочікувано повертає «yes». Що вам слід перевірити?

Перевірте ClusterRoleBinding’и, що застосовуються до Alice безпосередньо чи до будь-якої групи, наданої з її контекстом автентифікації. RoleBinding простору імен у dev не пояснив би доступ до продакшну, тож імовірно задіяна ширша прив’язка. Також перевірте, чи належить Alice до групи на кшталт developers, яка має кластерне надання прав. Діагностика має простежити суб’єкт, усі відповідні групи, згадану роль та область дії прив’язки.

Практична вправа: проєктування RBAC

У цій вправі ви спроєктуєте й переглянете модель RBAC для невеликої продуктової команди. Мета — не запам’ятати YAML; мета — потренуватися пояснювати, чому кожен суб’єкт отримує кожне дієслово в кожній області. Виконуйте завдання по порядку, і для кожного завдання запишіть одну дію, яку слід дозволити, та одну дію, яку слід заборонити, перш ніж дивитися на розв’язання.

Сценарій: Спроєктуйте RBAC для команди розробників, яка володіє простором імен dev, тимліда, що відповідає за чутливу конфігурацію, та ідентичності CI/CD, яка розгортає лише в staging. Вимоги нижче навмисно змішують доступ людей та автоматизації, щоб ви могли потренуватися розділяти особистості замість того, щоб давати всім ту саму потужну роль.

1. Розробники можуть переглядати всі ресурси у просторі імен dev
2. Розробники можуть створювати/оновлювати/видаляти Deployment’и та Service’и в dev
3. Тимлід може робити все, що й розробники, плюс керувати ConfigMap’ами та Secret’ами
4. Сервісний акаунт CI/CD має розгортати у просторі імен staging

Завдання

• Визначте набір прав розробника для dev і вирішіть, чи належить він до Role чи ClusterRole.
• Визначте набір прав тимліда, зокрема чому керування ConfigMap’ами та Secret’ами не слід надавати кожному розробнику.
• Визначте набір прав розгортання CI/CD для staging, тримаючи сервісний акаунт окремо від людей-користувачів.
• Створіть прив’язки для групи developers, користувача-тимліда та сервісного акаунта CI/CD.
• Напишіть щонайменше три позитивні перевірки k auth can-i та три негативні перевірки, які довели б, що проєкт не надає випадкового кластерного доступу.
• Перегляньте остаточний проєкт щодо ресурсів-зірочок, дієслів-зірочок, прямого створення Pod’ів, розкриття Secret’ів та використання ClusterRoleBinding.

Розв'язання

# Developer Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: developer
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["create", "update", "patch", "delete"]
- apiGroups: [""]
  resources: ["services"]
  verbs: ["create", "update", "patch", "delete"]
---
# Team Lead Role (extends developer)
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: team-lead
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["create", "update", "patch", "delete"]
- apiGroups: [""]
  resources: ["services", "configmaps", "secrets"]
  verbs: ["create", "update", "patch", "delete"]
---
# CI/CD Role for staging
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: staging
  name: deployer
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: [""]
  resources: ["services", "configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
---
# Bindings
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: dev
  name: developers-binding
subjects:
- kind: Group
  name: developers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: dev
  name: team-lead-binding
subjects:
- kind: User
  name: lead@example.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: team-lead
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: staging
  name: cicd-binding
subjects:
- kind: ServiceAccount
  name: cicd-deployer
  namespace: cicd
roleRef:
  kind: Role
  name: deployer
  apiGroup: rbac.authorization.k8s.io

Розв’язання дотримується сценарію, але його все одно варто переглянути критично. Ролі розробника й тимліда використовують шаблони-зірочки для читання ресурсів простору імен, що може бути прийнятним у тренувальній вправі, але має бути звужене в чутливих продакшн-просторах імен. Зауважте: resources: ["*"] для читання охоплює Secret’и — у реальному просторі імен dev це перше надання прав, яке слід звузити, оскільки воно дає кожному розробнику доступ на читання облікових даних. Порівняйте з вбудованою ClusterRole view, яка навмисно виключає Secret’и. Роль CI/CD уникає прямого створення Pod’ів і не використовує ClusterRoleBinding, що тримає межу автоматизації ближче до заявленої потреби розгортання. У суворішому середовищі ви також виокремили б керування секретами в меншу роль і вимагали б додаткового схвалення перед її прив’язуванням.

Критерії успіху

• Права розробника прив’язані до простору імен dev і не використовують ClusterRoleBinding.
• Права тимліда ширші за права розробника, але все ще прив’язані до простору імен dev.
• Права CI/CD прив’язані до сервісного акаунта й обмежені простором імен staging.
• Проєкт охоплює негативні перевірки для Secret’ів, ClusterRoleBinding’ів та доступу до продакшн-простору імен.
• Перегляд виявляє щонайменше одне місце, де тренувальне розв’язання можна було б звузити для реального продакшн-кластера.

Джерела

• Довідник з авторизації RBAC у Kubernetes
• Огляд авторизації Kubernetes
• Адміністрування ServiceAccount у Kubernetes
• Концепції ServiceAccount у Kubernetes
• Pod Security Standards у Kubernetes
• Довідник з контролерів допуску Kubernetes
• Довідник kubectl auth can-i
• Авторизація Node у Kubernetes
• Концепції власних ресурсів Kubernetes
• Довідник API RBAC у Kubernetes

Наступний модуль

Модуль 3.3: Керування секретами — дізнайтеся, як зберігати, надавати, ротувати та аудитувати чутливі дані Kubernetes, не перетворюючи кожне право на читання на розкриття облікових даних.