Модуль 3.4: Безпека ServiceAccount

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

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

Передумови: Модуль 3.3: Управління секретами

---

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

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

• Оцінити конфігурації ServiceAccount на предмет надмірного доступу до API та автоматично змонтованих токенів
• Оцінити ризик використання стандартного ServiceAccount у просторах імен кластера
• Визначити шляхи бічного руху, що стають можливими через неправильно налаштовані дозволи ServiceAccount
• Пояснити проєкцію обмежених токенів та як вона зменшує ризики витоку токенів

---

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

ServiceAccounts - це спосіб автентифікації подів у Kubernetes API. Кожен под працює з ServiceAccount, і за замовчуванням цей обліковий запис може мати більше доступу, ніж потрібно. Розуміння безпеки ServiceAccount критичне для впровадження мінімальних привілеїв для навантажень.

Неправильно налаштовані ServiceAccounts є поширеним вектором атаки для бічного руху в кластерах.

---

Основи ServiceAccount

┌─────────────────────────────────────────────────────────────┐
│              ОГЛЯД SERVICEACCOUNT                            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ЩО ТАКЕ SERVICEACCOUNT?                                   │
│  • Ідентифікація для подів для автентифікації в API server  │
│  • Ресурс простору імен                                    │
│  • Кожен под має один (default якщо не вказано)            │
│                                                             │
│  ЯК ПРАЦЮЄ:                                               │
│  1. Под створюється з serviceAccountName                   │
│  2. Токен проєктується у под                               │
│  3. Под використовує токен для автентифікації запитів API   │
│  4. API server валідує токен, витягує ідентифікацію         │
│  5. RBAC перевіряється для ServiceAccount                  │
│                                                             │
│  DEFAULT SERVICEACCOUNT:                                   │
│  • Кожен простір імен має "default" ServiceAccount         │
│  • Поди використовують його якщо не вказано інший          │
│  • Може мати ненавмисні дозволи                            │
│                                                             │
└─────────────────────────────────────────────────────────────┘

---

Токени ServiceAccount

Еволюція токенів

	Застарілі токени (до 1.24)	Прив’язані токени (1.24+)
Зберігання	У Secrets	Проєктований том
Термін	Ніколи не закінчуються	Обмежені (1 година)
Аудиторія	Будь-яка	Прив’язана до конкретної
Ротація	Ручна	Автоматична
Після видалення поду	Зберігаються	Недійсні

---

Конфігурація ServiceAccount

Базовий ServiceAccount

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app
  namespace: production
automountServiceAccountToken: false  # Не монтувати токен автоматично

Використання у поді

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  serviceAccountName: my-app
  automountServiceAccountToken: false  # Перевизначення на рівні поду
  containers:
  - name: app
    image: myapp:1.0

---

Проблеми Default ServiceAccount

┌─────────────────────────────────────────────────────────────┐
│              РИЗИКИ DEFAULT SERVICEACCOUNT                    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ПРОБЛЕМА:                                                 │
│  • Кожен простір імен має "default" ServiceAccount         │
│  • Поди використовують його автоматично                    │
│  • Токен автоматично монтується                            │
│  • Може мати прив'язані ролі                               │
│                                                             │
│  СЦЕНАРІЙ АТАКИ:                                           │
│  1. Атакуючий компрометує контейнер застосунку             │
│  2. Читає токен з /var/run/secrets/...                     │
│  3. Використовує токен для запитів до API Kubernetes       │
│  4. Виявляє секрети, інші поди, підвищує привілеї          │
│                                                             │
│  ПОМЯКШЕННЯ:                                               │
│  • Вимкнути авто-монтування для default SA                 │
│  • Створити окремі SA для кожного застосунку               │
│  • Не прив'язувати ролі до default SA                      │
│  • automountServiceAccountToken: false                     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

---

Workload Identity

Відображення ServiceAccounts Kubernetes на ідентифікації хмарного провайдера:

┌─────────────────────────────────────────────────────────────┐
│              WORKLOAD IDENTITY                               │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  БЕЗ WORKLOAD IDENTITY:                                   │
│  • Зберігати хмарні облікові дані як K8s Secrets           │
│  • Довготривалі, статичні облікові дані                    │
│  • Однакові для всіх подів                                 │
│  • Ручна ротація                                           │
│                                                             │
│  З WORKLOAD IDENTITY:                                      │
│  • K8s ServiceAccount → Cloud IAM role                     │
│  • Короткотривалі, авто-ротовані токени                    │
│  • Ідентифікація для кожного поду                          │
│  • Без статичних облікових даних                           │
│                                                             │
│  РЕАЛІЗАЦІЇ:                                               │
│  • AWS: IAM Roles for Service Accounts (IRSA)              │
│  • GCP: Workload Identity                                  │
│  • Azure: Workload Identity                                │
│                                                             │
└─────────────────────────────────────────────────────────────┘

---

Чи знали ви?

• Кожен под має ServiceAccount - якщо не вказати, використовується default SA простору імен.

• Прив’язані токени - це JWT - їх можна декодувати (заголовок + тіло), але не підробити без ключа підписання.

• Застарілі токени зберігаються - хоча Kubernetes 1.24+ використовує прив’язані токени за замовчуванням, старі Secret-токени можуть все ще існувати.

• automountServiceAccountToken можна встановити на рівні ServiceAccount та Pod. Рівень Pod перевизначає рівень SA.

---

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

Помилка	Чому це шкодить	Рішення
Використання default SA	Спільний, може мати ролі	Окремі SA
Токен завжди змонтований	Поверхня атаки навіть коли не потрібен	automountServiceAccountToken: false
Статичні хмарні облікові дані	Довготривалі, не аудитовані	Workload identity
Надмірно привілейований SA	Можливий бічний рух	Мінімальний RBAC
Один SA для всіх застосунків	Спільна ідентифікація, спільний радіус	SA для кожного застосунку

---

Тест

1. Що відбувається, якщо не вказати serviceAccountName у поді?

   Відповідь

   Під використовує `default` ServiceAccount свого простору імен. Токен default SA монтується у під, якщо automountServiceAccountToken не false.

2. Яка ключова відмінність між застарілими та прив’язаними токенами ServiceAccount?

   Відповідь

   Застарілі токени ніколи не закінчуються та зберігаються у Secrets. Прив'язані токени обмежені за часом (зазвичай 1 година), прив'язані до аудиторії та проєктуються у поди через томи. Прив'язані токени автоматично ротуються.

3. Чому слід вимикати авто-монтування токенів ServiceAccount?

   Відповідь

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

4. Що таке workload identity?

   Відповідь

   Workload identity відображає ServiceAccounts Kubernetes на IAM-ролі хмарного провайдера. Поди отримують короткотривалі хмарні облікові дані без зберігання статичних секретів. Приклади: AWS IRSA, GCP Workload Identity, Azure Workload Identity.

5. Як дозвіл create pods на ServiceAccount може призвести до підвищення привілеїв?

   Відповідь

   З дозволом create pods можна створити привілейований під, що монтує файлову систему хоста або використовує hostPID/hostNetwork. Це може призвести до втечі з контейнера та компрометації вузла.

---

Підсумок

Аспект	Ризик	Пом’якшення
Default SA	Спільна ідентифікація	Окремі SA
Монтування токена	Поверхня атаки	automountServiceAccountToken: false
RBAC	Надмірні привілеї	Мінімальний, просторовий
Хмарний доступ	Статичні облікові дані	Workload identity
Застарілі токени	Ніколи не закінчуються	Очистити, прив’язані токени

---

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

Модуль 3.5: Мережеві політики - Контроль мережевого трафіку між подами.