Модуль 5.3: Безпека часу виконання

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

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

Передумови: Модуль 5.2: Спостережуваність безпеки

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

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

Оцінити засоби безпеки часу виконання: профілі seccomp, AppArmor, SELinux та правила Falco
Оцінити які загрози часу виконання кожен механізм примусового виконання призначений виявляти або запобігати
Порівняти примусове виконання на рівні ядра (seccomp, AppArmor) з поведінковим виявленням (Falco)
Визначити прогалини безпеки часу виконання, де зловмисник може діяти непоміченим

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

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

KCSA перевіряє ваше розуміння концепцій безпеки часу виконання, включно з seccomp, AppArmor, SELinux та інструментами примусового виконання.

Рівні безпеки часу виконання

┌─────────────────────────────────────────────────────────────┐
│              СТЕК БЕЗПЕКИ ЧАСУ ВИКОНАННЯ                    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  РІВЕНЬ 4: ADMISSION KUBERNETES                            │
│  ├── Перевіряє поди перед плануванням                      │
│  ├── Pod Security Standards                                │
│  └── Движки політик (OPA, Kyverno)                        │
│                                                             │
│  РІВЕНЬ 3: СЕРЕДОВИЩЕ ВИКОНАННЯ КОНТЕЙНЕРІВ                │
│  ├── OCI runtime (runc, crun)                             │
│  ├── Ізольовані середовища (gVisor, Kata)                 │
│  └── Конфігурація безпеки часу виконання                   │
│                                                             │
│  РІВЕНЬ 2: МОДУЛІ БЕЗПЕКИ LINUX                            │
│  ├── seccomp (фільтрація системних викликів)              │
│  ├── AppArmor (обмеження файлів/мережі)                   │
│  ├── SELinux (обов'язковий контроль доступу)               │
│  └── Capabilities (обмеження привілеїв)                    │
│                                                             │
│  РІВЕНЬ 1: ЯДРО                                            │
│  ├── Простори імен (ізоляція)                              │
│  ├── cgroups (обмеження ресурсів)                          │
│  └── Основні функції безпеки                               │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Профілі Seccomp

Що таке Seccomp?

┌─────────────────────────────────────────────────────────────┐
│              SECCOMP (SECURE COMPUTING MODE)                │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ПРИЗНАЧЕННЯ:                                              │
│  • Фільтрація системних викликів процесу                  │
│  • Блокування небезпечних syscalls (mount, ptrace тощо)    │
│  • Зменшення поверхні атаки ядра                           │
│                                                             │
│  ЯК ПРАЦЮЄ:                                               │
│  Застосунок → Syscall → Фільтр Seccomp → Дозвіл/Блок/Лог │
│                                                             │
│  ТИПИ ПРОФІЛІВ:                                            │
│  ├── RuntimeDefault — стандартний профіль середовища       │
│  │   виконання контейнерів                                 │
│  ├── Unconfined — без фільтрації (небезпечно)             │
│  └── Localhost — спеціалізований профіль з вузла           │
│                                                             │
│  KUBERNETES 1.27+:                                         │
│  RuntimeDefault є стандартним для нових кластерів          │
│                                                             │
│  БЛОКУЄТЬСЯ ЗА ЗАМОВЧУВАННЯМ (RuntimeDefault):             │
│  • mount, umount                                          │
│  • ptrace                                                 │
│  • reboot                                                 │
│  • Більшість операцій з модулями ядра                     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Seccomp у подах

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault  # Стандартний профіль середовища виконання
  containers:
  - name: app
    image: myapp:1.0

Профілі AppArmor

┌─────────────────────────────────────────────────────────────┐
│              APPARMOR                                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ПРИЗНАЧЕННЯ:                                              │
│  • Обов'язковий контроль доступу (MAC)                     │
│  • Обмеження доступу до файлів, мережі, capabilities      │
│  • Специфічні для програм політики безпеки                 │
│                                                             │
│  ДОСТУПНИЙ НА:                                             │
│  • Ubuntu, Debian, SUSE                                   │
│  • НЕ на RHEL/CentOS (використовуйте SELinux)             │
│                                                             │
│  РЕЖИМИ ПРОФІЛЮ:                                           │
│  ├── Enforce — блокувати порушення                         │
│  ├── Complain — журналювати, але дозволяти (навчання)      │
│  └── Unconfined — без обмежень                             │
│                                                             │
└─────────────────────────────────────────────────────────────┘

SELinux

┌─────────────────────────────────────────────────────────────┐
│              SELINUX                                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ПРИЗНАЧЕННЯ:                                              │
│  • Обов'язковий контроль доступу (MAC)                     │
│  • Безпека на основі міток                                 │
│  • Кожен файл, процес має контекст безпеки                │
│                                                             │
│  ДОСТУПНИЙ НА:                                             │
│  • RHEL, CentOS, Fedora                                   │
│  • НЕ на Ubuntu/Debian (використовуйте AppArmor)          │
│                                                             │
│  РЕЖИМИ:                                                   │
│  ├── Enforcing — блокувати порушення                       │
│  ├── Permissive — журналювати, але дозволяти               │
│  └── Disabled — без SELinux                                │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Можливості Linux (Capabilities)

apiVersion: v1
kind: Pod
metadata:
  name: minimal-caps
spec:
  containers:
  - name: app
    image: myapp:1.0
    securityContext:
      capabilities:
        drop:
          - ALL         # Скинути всі можливості
        add:
          - NET_BIND_SERVICE  # Додати лише необхідне

Інструменти примусового виконання під час виконання

OPA Gatekeeper проти Kyverno

┌─────────────────────────────────────────────────────────────┐
│              ПОРІВНЯННЯ ДВИЖКІВ ПОЛІТИК                     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  OPA GATEKEEPER                                            │
│  ├── Мова політик: Rego                                   │
│  ├── Крива навчання: Крутіша                              │
│  ├── Гнучкість: Дуже висока                               │
│  ├── За межами K8s: Так (OPA є загального призначення)    │
│  └── Підходить для: Складних політик, існуючих             │
│      користувачів OPA                                      │
│                                                             │
│  KYVERNO                                                   │
│  ├── Мова політик: YAML (рідна для Kubernetes)            │
│  ├── Крива навчання: Полегшена                            │
│  ├── Гнучкість: Висока                                    │
│  ├── За межами K8s: Ні (специфічний для Kubernetes)       │
│  ├── Функції: Перевірка, мутація, генерація, верифікація  │
│  └── Підходить для: Лише K8s, команди знайомі з YAML     │
│                                                             │
│  ОБИДВА МОЖУТЬ:                                            │
│  • Блокувати погані конфігурації при admission             │
│  • Забезпечувати організаційні політики                    │
│  • Аудитувати існуючі ресурси                             │
│  • Звітувати про порушення                                 │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Ізольовані середовища виконання

┌─────────────────────────────────────────────────────────────┐
│              ПОРІВНЯННЯ ІЗОЛЬОВАНИХ СЕРЕДОВИЩ ВИКОНАННЯ     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  СТАНДАРТНЕ СЕРЕДОВИЩЕ (runc)                               │
│  ├── Прямі системні виклики до ядра хоста                  │
│  ├── Найшвидша продуктивність                              │
│  ├── Вразливість ядра = втеча з контейнера                 │
│  └── Використовувати для: Довірених навантажень            │
│                                                             │
│  gVisor (runsc)                                            │
│  ├── Ядро в просторі користувача (Sentry)                 │
│  ├── Перехоплює та емулює системні виклики                 │
│  ├── ~70% покриття syscalls                                │
│  ├── Накладні витрати продуктивності (залежно від          │
│  │   навантаження)                                         │
│  └── Використовувати для: Недовірених навантажень,         │
│      мультитенант                                          │
│                                                             │
│  Kata Containers                                           │
│  ├── Легка ВМ на контейнер                                │
│  ├── Окреме ядро (не спільне)                              │
│  ├── Апаратна віртуалізація (KVM)                         │
│  ├── Більші накладні витрати, ніж gVisor                   │
│  └── Використовувати для: Максимальної ізоляції,           │
│      відповідності                                         │
│                                                             │
│  ВИБІР СЕРЕДОВИЩА:                                         │
│  Довірені внутрішні навантаження → runc                    │
│  Недовірені/мультитенант → gVisor                         │
│  Максимальна ізоляція → Kata                              │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

# Визначення RuntimeClass
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc  # Назва обробника, налаштованого на вузлах
---
# Використання в поді
apiVersion: v1
kind: Pod
metadata:
  name: sandboxed-pod
spec:
  runtimeClassName: gvisor  # Використовувати gVisor
  containers:
  - name: app
    image: myapp:1.0

Чи знали ви?

Seccomp може заблокувати понад 300 syscalls. Більшість застосунків потребують лише 50-100. Блокування решти значно зменшує поверхню атаки.
gVisor реалізує власний мережевий стек (netstack). Це означає, що мережеві експлойти ядра не впливають на контейнери gVisor.
AppArmor та SELinux є взаємовиключними — система використовує один або інший, залежно від дистрибутиву.
RuntimeDefault seccomp став стандартним у Kubernetes 1.27, автоматично покращуючи безпеку для всіх нових кластерів.

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

Помилка	Чому це шкодить	Рішення
seccomp: Unconfined	Без фільтрації syscalls	Використовувати RuntimeDefault
Не скидати capabilities	Надмірні привілеї	Скинути ВСІ, додати мінімум
Без AppArmor/SELinux	Відсутній рівень MAC	Увімкнути та застосувати профілі
Єдине середовище для всіх	Зайва/недостатня ізоляція	Використовувати RuntimeClasses
Не тестувати профілі	Ламає застосунки	Спочатку тестувати у staging

Перевірка знань

Що робить seccomp?

Відповідь
Seccomp (Secure Computing Mode) фільтрує, які системні виклики може здійснювати процес. Він дозволяє визначити білий або чорний список syscalls, блокуючи небезпечні, такі як mount, ptrace та reboot, які можуть бути використані для втечі з контейнера або підвищення привілеїв.
Яка різниця між AppArmor та SELinux?

Відповідь
Обидва забезпечують обов'язковий контроль доступу (MAC). AppArmor використовує правила на основі шляхів та профілі для програм (поширений на Ubuntu/Debian). SELinux використовує правила на основі міток, де кожен файл та процес має контекст безпеки (поширений на RHEL/CentOS). Вони є взаємовиключними — система використовує один або інший.
Чому потрібно скидати всі capabilities та додавати лише необхідні?

Відповідь
Capabilities розбивають привілеї root на дискретні одиниці. Скидаючи всі та додаючи лише потрібні, ви мінімізуєте те, що може зробити зловмисник при компрометації контейнера. Наприклад, веб-серверу може знадобитися лише NET_BIND_SERVICE для прив'язки до порту 80.
Коли б ви використали gVisor проти Kata Containers?

Відповідь
gVisor підходить для недовірених навантажень з помірними потребами в ізоляції — він має менші накладні витрати, але не покриває всі syscalls. Kata Containers забезпечує максимальну ізоляцію за допомогою ВМ з окремими ядрами — краще для вимог відповідності або високочутливих навантажень, але з більшими накладними витратами.
Яка роль RuntimeClass?

Відповідь
RuntimeClass дозволяє вибирати різні середовища виконання контейнерів (наприклад, runc, runsc для gVisor або kata для Kata Containers) для різних подів. Це дозволяє запускати довірені навантаження на швидкому runc, а недовірені навантаження — на ізольованих середовищах виконання.

Підсумок

Безпека часу виконання забезпечує кілька рівнів захисту:

Рівень	Технологія	Призначення
Фільтр syscalls	Seccomp	Блокувати небезпечні системні виклики
MAC	AppArmor/SELinux	Обмеження файлів, мережі, capabilities
Capabilities	Linux	Гранулярний контроль привілеїв
Ізоляція	gVisor/Kata	Ізоляція ядра
Політика	Kyverno/OPA	Примусове виконання при admission

Ключові принципи:

Увімкніть seccomp RuntimeDefault як мінімум
Використовуйте AppArmor/SELinux, де доступно
Скиньте всі capabilities, додайте мінімум
Розгляньте ізольовані середовища для недовірених навантажень
Застосовуйте політики при admission

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

Модуль 5.4: Інструменти безпеки — Огляд інструментів безпеки в екосистемі Kubernetes.