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

Складність: [СЕРЕДНЯ] - Основні знання

Час на виконання: 30-35 хвилин

Передумови: Модуль 3.1: Безпека подів

---

Що ви зможете робити

Після завершення цього модуля ви зможете:

• Оцінити RBAC-політики на предмет надмірних дозволів та ризиків підвищення привілеїв
• Оцінити чи дана Role або ClusterRole відповідає принципу мінімальних привілеїв
• Визначити небезпечні RBAC-шаблони: wildcard-дієслова, прив’язки cluster-admin, шляхи підвищення
• Пояснити як взаємодіють Roles, ClusterRoles, RoleBindings та ClusterRoleBindings

---

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

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

---

Концепції RBAC

┌─────────────────────────────────────────────────────────────┐
│              БУДІВЕЛЬНІ БЛОКИ RBAC                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ХТО                           ЩО                          │
│  (Суб'єкти)                    (Правила)                   │
│  ┌─────────────┐              ┌─────────────┐              │
│  │ Users       │              │ Verbs       │              │
│  │ Groups      │              │ Resources   │              │
│  │ ServiceAccts│              │ API Groups  │              │
│  └──────┬──────┘              └──────┬──────┘              │
│         │                            │                      │
│         │       ПРИ'ЯЗКА             │                      │
│         │      (З'єднання)           │                      │
│         │     ┌───────────┐          │                      │
│         └────→│ Role      │←─────────┘                      │
│               │ Binding   │                                 │
│               └───────────┘                                 │
│                                                             │
│  Role = Колекція дозволів (verbs на resources)             │
│  Binding = З'єднує суб'єктів з ролями                      │
│                                                             │
└─────────────────────────────────────────────────────────────┘

---

Roles проти ClusterRoles

	Role	ClusterRole
Обсяг	Простір імен	Кластер
Ресурси	Лише просторові	Будь-які (включаючи кластерні)
Прив’язка	RoleBinding	ClusterRoleBinding або RoleBinding
Коли	Один простір імен	Кластерні ресурси або повторне використання

Визначення ролі

# Роль для простору імен
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"]

Компоненти правил

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

---

Прив’язки ролей

# Прив'язує роль до користувачів/груп у просторі імен
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
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

---

Вбудовані ролі

┌─────────────────────────────────────────────────────────────┐
│              ВБУДОВАНІ CLUSTERROLES                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  cluster-admin                                             │
│  ├── Повний доступ до всього                               │
│  └── НЕБЕЗПЕЧНО - використовуйте обережно                  │
│                                                             │
│  admin                                                     │
│  ├── Повний доступ у просторі імен                         │
│  └── Для: Адміністраторів простору імен                     │
│                                                             │
│  edit                                                      │
│  ├── Читання/запис більшості ресурсів простору імен        │
│  └── Для: Розробників                                      │
│                                                             │
│  view                                                      │
│  ├── Лише читання більшості ресурсів                       │
│  ├── НЕ бачить secrets                                     │
│  └── Для: Аудиторів, спостерігачів                         │
│                                                             │
└─────────────────────────────────────────────────────────────┘

---

Найкращі практики RBAC

Небезпечні дозволи

┌─────────────────────────────────────────────────────────────┐
│              НЕБЕЗПЕЧНІ ДОЗВОЛИ RBAC                         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  CREATE pods                                               │
│  └── Може створити привілейовані поди, вирватися на хост   │
│                                                             │
│  CREATE/UPDATE roles/rolebindings                          │
│  └── Може надати собі більше дозволів                      │
│                                                             │
│  GET secrets                                               │
│  └── Може прочитати всі секрети (токени, паролі)           │
│                                                             │
│  IMPERSONATE users/groups                                  │
│  └── Може діяти як будь-який користувач                    │
│                                                             │
│  EXEC into pods                                            │
│  └── Може виконувати команди у будь-якому контейнері       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

---

Чи знали ви?

• RBAC заборонює за замовчуванням - якщо жодна роль не надає дозвіл, дія заборонена. У RBAC немає правила “deny”.

• Роль view не включає secrets за задумом. Це дозволяє надати широкий доступ на читання без розкриття чутливих даних.

• Wildcards агрегуються - використання resources: ["*"] надає доступ до ресурсів, які ще не існують (майбутні CRD).

---

Поширені помилки

Помилка	Чому це шкодить	Рішення
cluster-admin для застосунків	Надмірний доступ	Створюйте конкретні ролі
Wildcards на продакшн	Надає більше, ніж задумано	Вказуйте точні resources/verbs
ClusterRoleBinding для просторових потреб	Кластерний доступ коли достатньо просторового	RoleBinding
Спільні ролі для різних команд	Не можна відкликати індивідуально	Ролі для кожної команди

---

Тест

1. Яка різниця між Role та ClusterRole?

   Відповідь

   Role обмежений простором імен та надає дозволи лише в одному просторі імен. ClusterRole є кластерним та може надавати дозволи на кластерні ресурси або використовуватися у кількох просторах імен.

2. Чи може RoleBinding посилатися на ClusterRole?

   Відповідь

   Так. RoleBinding може прив'язати ClusterRole до суб'єктів у своєму просторі імен. Це надає дозволи ClusterRole, але лише в просторі імен RoleBinding. Корисно для повторного використання ролей.

3. Які дозволи надає вбудована ClusterRole view?

   Відповідь

   Доступ лише для читання до більшості ресурсів простору імен (get, list, watch). Явно виключає secrets та не включає дозволів на запис.

4. Чому надання create pods небезпечне?

   Відповідь

   Користувач, що може створювати поди, може створити привілейовані поди, монтувати файлові системи хоста або отримати доступ до секретів, монтуючи їх як томи. Це може призвести до втечі з контейнера та компрометації кластера.

5. Як Kubernetes RBAC обробляє правила deny?

   Відповідь

   Kubernetes RBAC не має правил deny. Він адитивний - дозволи надаються, ніколи не відкликаються. Для обмеження доступу видаліть правило надання або не створюйте його. Без правила - доступ заборонений за замовчуванням.

---

Підсумок

RBAC - система авторизації Kubernetes:

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

Найкращі практики: мінімальні привілеї, уникайте wildcards, надавайте перевагу просторовим ролям, обережно з create pods та get secrets.

---

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

Модуль 3.3: Управління секретами - Як безпечно працювати з чутливими даними в Kubernetes.