03.03.2026
1 хв
396
У фінальній частині ми заглядаємо “під капот” самих контейнерів. Мало захистити кластер – треба переконатися, що всередині ваших образів немає “сюрпризів”. Ми розберемося, навіщо викидати shell із контейнерів, як налаштувати автоматичну перевірку правил через Gatekeeper та чому Security Context – це ваш головний інструмент у рантаймі. Це підсумок великого гайду для HackYourMom, який допоможе вибудувати ешелоновану оборону від збирання образу до моніторингу реальних атак.
Коли ми говоримо про безпеку самого додатка, все починається з контейнерного образу. Якщо ваш образ містить вразливості на рівні ОС або бібліотек додатка, то навіть найкраще захищений кластер не врятує його від компрометації. Зловмисник, отримавши контроль над одним таким контейнером, може використовувати його як плацдарм для горизонтального переміщення мережею.
Перший і найважливіший крок – використання мінімальних образів. Забудьте про образи на базі повноцінних Ubuntu чи Debian для запуску простих мікросервісів. Ідеальним вибором є distroless образи, які не містять нічого, крім вашого додатка та його залежностей, навіть командної оболонки (shell) чи пакетного менеджера. Це кардинально зменшує поверхню атаки: зловмиснику просто не буде де закріпитися і чим виконувати команди. Детальніше про філософію distroless образів можна дізнатися в їхньому офіційному репозиторії на GitHub.
Наступний крок – регулярне сканування образів на вразливості (CVE). На щастя, в екосистемі Kubernetes є чудові інструменти, які роблять це автоматично. Сканери, такі як Trivy від Aqua Security або Grype від Anchore, можуть інтегруватися безпосередньо у ваші CI/CD пайплайни. Вони проаналізують образ під час збирання, перевірять його наявність у базах даних вразливостей і заблокують деплоймент, якщо виявлять критичні проблеми.
Також, критично важливо використовувати конкретні версії образів (хеші образів, наприклад my-image:latest@sha256:abcd...), а не просто теги на кшталт latest. Використання хешів гарантує, що ви розгортаєте саме той образ, який пройшов тестування та сканування, і що жоден зловмисник не зміг підмінити його в реєстрі.
Але як гарантувати, що всі ці найкращі практики безпеки дійсно виконуються у вашому кластері? Ви не можете покладатися лише на дисципліну розробників. Саме тут на сцену виходять Admission Controllers. Це внутрішні контролери Kubernetes, які можуть перехоплювати запити до API Server перед тим, як вони будуть записані в базу etcd.
Admission Controllers бувають двох типів: Validating (перевіряють запит і блокують його, якщо він не відповідає правилам) та Mutating (можуть змінити запит, наприклад, автоматично додати певні налаштування безпеки). Вони дозволяють автоматизувати дотримання політик безпеки на рівні всього кластера. Наприклад, ви можете налаштувати Validating Admission Controller, який блокуватиме розгортання подів, чиї образи не пройшли сканування Trivy або були підписані невірним ключем. Детальніше про принцип роботи Admission Controllers можна почитати в офіційній документації Kubernetes.
Найпотужнішим інструментом для впровадження концепції “Політика як код” (Policy-as-Code) в Kubernetes є OPA Gatekeeper. Він використовує мову декларативних політик Rego, що дозволяє створювати надзвичайно гранулярні правила. Ви можете заборонити використання latest тегів, вимагати наявність певних лейблів на подах, обмежувати права доступу до ресурсів і багато іншого.
Використання безпечних образів – це лише половина справи. Ви також повинні контролювати, як ці контейнери запускаються в рантаймі. За замовчуванням контейнери в Kubernetes запускаються з надто широкими правами, що є прямим запрошенням для зловмисників. Для жорсткого обмеження системних викликів та можливостей контейнера використовується Security Context у маніфестах подів.
Найважливіший параметр – це readOnlyRootFilesystem. Налаштуйте ваш контейнер так, щоб його коренева файлова система була доступна лише для читання. Це фундаментальний принцип, який гарантує, що жоден шкідливий процес не зможе змінити конфігураційні файли або встановити шкідливе програмне забезпечення. Якщо вашому додатку потрібно писати тимчасові дані, використовуйте для цього окремі монтовані волюми на кшталт emptyDir.
# Приклад маніфесту пода із Security Context
spec:
containers:
- name: my-secure-app
image: my-secure-app:latest
securityContext:
readOnlyRootFilesystem: true # Коренева файлова система лише для читання
runAsUser: 1001 # Запуск від імені не-root користувача
runAsGroup: 3000
Також критично важливо використовувати allowPrivilegeEscalation=false. Цей параметр запобігає можливості підвищення привілеїв процесу за допомогою механізмів на кшталт suid бітів.
Крім того, ви повинні запускати ваші контейнери від імені не-root користувача, використовуючи параметри runAsUser та runAsGroup. Якщо ви використовуєте Distroless образи, вони вже налаштовані на запуск від не-root користувача за замовчуванням. Також, критично важливим є використання Linux Capabilities. Замість того щоб надавати контейнеру всі права суперкористувача, ви можете точково дозволити лише ті capabilities (наприклад, NET_BIND_SERVICE), які необхідні додатку. Все інше має бути заборонено.
Нарешті, використовуйте профілі безпеки AppArmor або SELinux та Pod Security Standards. Kubernetes надає три рівні стандартів безпеки подів (Privileged, Baseline, Restricted), які дозволяють автоматично перевіряти маніфести подів на відповідність кращим практикам. Детальніше про Pod Security Standards можна почитати в офіційній документації Kubernetes.
Коли ваш контейнер вже працює, настає час задуматися про безпеку рантайму. Контейнери – це не віртуальні машини; вони розділяють одне ядро операційної системи з хостом. Це створює загрозу “втечі з контейнера” (container breakout), коли зловмисник, використовуючи вразливості ядра операційної системи, може отримати доступ до хоста і всього кластера.
Для мінімізації цього ризику використовуйте контейнерні рантайми, що забезпечують жорстку ізоляцію. Чудовим прикладом є gVisor від Google. Це пісочниця для контейнерів, яка створює власне віртуальне ядро ОС для кожного контейнера, кардинально обмежуючи системні виклики. Зловмисник, зламавши такий контейнер, опиниться в ізольованому середовищі без доступу до хоста. gVisor може інтегруватися з Kubernetes як RuntimeClass, дозволяючи вам точково вибирати, які поди запускати в цій захищеній пісочниці.
Фінальний ешелон захисту – це аудит та виявлення загроз у реальному часі. Без належного журналювання аудиту ви не зможете розслідувати інциденти, оскільки в системі просто не залишиться слідів. Kubernetes Auditing дозволяє записувати кожен запит до API Server, включаючи інформацію про користувача, дію та результат. Ввімкніть аудит у вашому кластері та налаштуйте політику аудиту, щоб фіксувати лише ті події, які є важливими для безпеки. Детальніше про K8s Auditing можна почитати в офіційній документації Kubernetes.
Крім того, ви повинні моніторити активність усередині самих контейнерів у реальному часі. Інструменти безпеки, такі як Falco від Sysdig, використовують можливості eBPF ядра Linux, щоб аналізувати системні виклики та виявляти підозрілу активність. Falco поставляється з великим набором готових правил, які дозволяють виявляти запуск неочікуваних процесів, несанкціоновану зміну файлів, спроби мережевого сканування та багато іншого. Він дозволяє реагувати на загрози миттєво, а не через кілька днів чи тижнів після витоку даних. Falco може інтегруватися з вашими системами сповіщень (наприклад, Slack чи PagerDuty) для оперативного реагування на інциденти.
Ось і завершилася наша масштабна епопея із захисту конфігурації кластерів Kubernetes. Ми пройшли довгий шлях від розуміння архітектури та моделювання загроз за STRIDE до практичного посилення конфігурації платформи управління (Control Plane), мережевої ізоляції на принципах Zero Trust та, нарешті, захисту самих контейнерів.
Ми побачили, що безпека Kubernetes – це не один “срібна куля” чи одне налаштування, а комплексна, багаторівнева стратегія (Ешелонована оборона). Ми замкнули головні двері API Server, розмежували права за суворим принципом найменших привілеїв, забезпечили справжнє шифрування та ізоляцію критичних даних etcd, а внутрішню мережу сегментували жорсткими політиками нульової довіри.
Проте захист платформи управління – це лише половина справи. Кластер існує для того, щоб запускати додатки, і саме вони найчастіше стають точкою входу для атак. Ми детально розібрали, як перетворити ваші додатки на неприступну фортецю: від використання мінімалістичних distroless образів без командної оболонки до жорсткого обмеження системних викликів через Security Context контейнерів та використання найсучасніших пісочниць на кшталт gVisor. Ми також налаштували Admission Controllers (OPA Gatekeeper) для автоматичного блокування небезпечних розгортань та забезпечили безперервний аудит і виявлення загроз у реальному часі за допомогою Falco.
Важливо розуміти, що security hardening – це не кінцевий етап, а безперервний процес. Екосистема Kubernetes постійно розвивається, так само як і вектори кібератак. Регулярне оновлення компонентів, аудит конфігурації та моніторинг активності є критично важливими для підтримки високого рівня безпеки. Тільки так ви зможете гарантувати надійний захист ваших додатки та даних. Пам’ятайте: найкращий захист – це обізнаність та проактивний підхід.
