Модуль 4.2: Профілі AppArmor

Безпека Linux | Складність: [MEDIUM] | Час: 30–35 хв

Передумови

Перед початком цього модуля:

Обов’язково: Модуль 2.3: Capabilities та LSM
Обов’язково: Модуль 1.4: Користувачі та дозволи
Бажано: Розуміння основних концепцій безпеки.

Що ви зможете робити після цього модуля

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

Написати профілі AppArmor, що обмежують доступ контейнера до файлової системи та мережі
Дебажити відмови AppArmor, читаючи аудит-логи та визначаючи заблоковану операцію
Застосувати профілі AppArmor до подів Kubernetes через анотації або security context
Порівняти підхід AppArmor (на основі шляхів) з SELinux (на основі міток) та обрати відповідний

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

AppArmor забезпечує обов’язковий контроль доступу (MAC) — політики безпеки, які додатки не можуть обійти, навіть працюючи від імені root. Якщо звичайні права (DAC) може змінити власник файлу, то політики AppArmor контролюються ядром і є незмінними для процесів.

Розуміння AppArmor допоможе вам:

Захищати поди Kubernetes — застосовувати специфічні профілі для контейнерів.
Обмежувати шкоду від зламу — зламаний додаток зможе отримати доступ тільки до дозволених ресурсів.
Скласти іспит CKS — AppArmor є однією з ключових тем.
Діагностувати помилки доступу — чому виникає «permission denied», коли права на файли в нормі?

Коли ваш контейнер не може записати файл попри правильні UID/GID — причиною часто є AppArmor.

Режими роботи профілів

Режим	Поведінка	Використання
Enforce (Примусовий)	Блокує дії та пише в лог	Продакшн
Complain (Скарги)	Дозволяє дії, але пише в лог	Тестування та розробка
Unconfined (Необмежений)	Жодних обмежень	Вимкнено

Робота з профілями

Перевірка статусу

# Перевірити, чи увімкнено AppArmor та які профілі завантажені
sudo aa-status

Керування профілями

# Перевести профіль у режим скарг (тільки логування)
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

# Повернути в примусовий режим
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx

# Завантажити новий профіль у ядро
sudo apparmor_parser -r /etc/apparmor.d/my-profile

AppArmor в Kubernetes

Kubernetes дозволяє призначати профілі AppArmor окремим контейнерам через анотації в описі Пода.

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
  annotations:
    # Формат: container.apparmor.security.beta.kubernetes.io/<назва-контейнера>: <профіль>
    container.apparmor.security.beta.kubernetes.io/nginx: localhost/k8s-apparmor-example-deny-write
spec:
  containers:
  - name: nginx
    image: nginx

Важливо: Профіль має бути заздалегідь завантажений на КОЖНОМУ вузлі кластера, де може бути запущений цей под.

Тест

Яка головна різниця між AppArmor та звичайними правами доступу (rwx)?

Відповідь
AppArmor — це MAC (Mandatory Access Control). На відміну від звичайних прав (DAC), які власник файлу може змінити, політики AppArmor нав'язуються ядром і діють навіть на користувача root.
Що станеться в режимі “Complain”, якщо додаток спробує відкрити заборонений файл?

Відповідь
Додаток зможе відкрити файл, але в системному журналі (dmesg або audit.log) з'явиться запис про порушення політики. Це корисно для налагодження профілів перед деплоєм.
Де в Ubuntu зазвичай лежать файли профілів AppArmor?

Відповідь
У директорії `/etc/apparmor.d/`.
Чи може один под у Kubernetes мати різні профілі AppArmor для різних контейнерів?

Відповідь
Так. Анотація вказує назву конкретного контейнера, тому ви можете налаштувати безпеку для кожного компонента поду окремо.

Практична вправа

Завдання: Подивитися статус AppArmor та знайти заблоковані дії.

Перевірте статус AppArmor на вашій системі:
Terminal window
```
sudo aa-status
```
Подивіться в логи на предмет заблокованих дій (якщо вони були):
Terminal window
```
sudo dmesg | grep -i apparmor
```
Список завантажених профілів, що діють прямо зараз:
Terminal window
```
ls /etc/apparmor.d/
```

Критерії успіху: Ви вмієте визначати, чи працює AppArmor і які профілі зараз активні в системі.

Підсумок

AppArmor обмежує можливості програм, навіть якщо вони працюють від root.
Enforce для захисту, Complain для розробки.
Kubernetes використовує анотації для зв’язку контейнера з профілем.
Профілі мають бути на всіх вузлах кластера.

Далі: Модуль 4.3: SELinux — альтернативна система безпеки, що використовується в дистрибутивах RHEL та CentOS.