Контейнери під замком: наш підхід до безпеки в Docker-середовищі

Docker став невіддільною частиною сучасної розробки з понад 15 мільярдами завантажених контейнерних образів у 2024 році. Однак ця популярність має свою ціну — 75% контейнерних образів містять вразливості високого або критичного рівня. Ми не можемо ігнорувати ці ризики, особливо після інциденту 2021 року, коли через неправильно налаштований Docker API зловмисники змогли встановити шкідливе програмне забезпечення для майнінгу криптовалюти на відкриті контейнери.

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

У цій статті ми розглянемо основні загрози безпеки в Docker-середовищі, базові принципи захисту та стратегії для забезпечення безпеки на всіх етапах життєвого циклу контейнерів. Також ми поділимося практичними порадами щодо впровадження безпеки Docker у корпоративному середовищі для зменшення ризику порушень безпеки.

Безпека контейнерів постійно викликає занепокоєння, особливо з огляду на зростання кількості атак на ланцюжки постачання на 430%. Розглянемо основні загрози, з якими стикаються Docker-середовища.

Вразливості в базових образах та залежностях

Контейнери часто будуються на основі базових образів, які можуть містити вразливості. Згідно з дослідженнями, 87% контейнерних образів мають вразливості високого рівня серйозності. Використання застарілих образів або образів із ненадійних реєстрів може призвести до порушень безпеки. Образи з публічних реєстрів, як-от Docker Hub, можуть містити шкідливе програмне забезпечення або backdoor, якщо вони походять із ненадійних джерел.

Ризики виходу з контейнера (container breakout)

Вихід із контейнера (container breakout) відбувається, коли зловмисник долає ізоляцію контейнера та отримує несанкціонований доступ до системи хоста.

Це можливо через:

• експлуатацію вразливостей ядра;
• неправильно налаштовані привілеї;
• зловживання простором імен;
• маніпуляції із системними викликами.

Наприклад, контейнери з правами root можуть потенційно отримати доступ до ресурсів хоста, що збільшує ризик порушення безпеки.

Неправильна конфігурація мережевих налаштувань

За замовчуванням контейнери можуть взаємодіяти між собою через мережу docker0, що створює потенційні ризики. Міжконтейнерне з'єднання (ICC) увімкнено за замовчуванням, дозволяючи всім контейнерам спілкуватися між собою. Незахищені мережеві налаштування можуть призвести до витоку конфіденційних даних та дозволити зловмисникам перехоплювати трафік між контейнерами.

Як розв'язати цю проблему

1. Відключення ICC

dockerd --icc=false

Або налаштуйте це в конфігураційному файлі /etc/docker/daemon.json:

{

  "icc": false

}

2. Використання мережевих політик

docker network create --driver bridge isolated_network

docker run --network=isolated_network myapp

3. Налаштування iptables

Docker використовує правила iptables для управління трафіком. Переконайтеся, що параметр --iptables увімкнено:

dockerd --iptables=true

4. Використання користувацьких мостів

Створення користувацьких мостів забезпечує кращий контроль над мережевою комунікацією:

docker network create -o "com.docker.network.bridge.enable_icc=false" no_icc_network

Секрети — це будь-які конфіденційні дані, такі як паролі, сертифікати або API-ключі, які не повинні передаватися мережею або зберігатися у незашифрованому вигляді. Зберігання секретів у контейнерах без належного захисту створює серйозні ризики. Введення паролів та API-ключів як змінних середовища ризикує ненавмисним розкриттям інформації, оскільки змінні середовища часто доступні для всіх процесів.

Вразливості ядра та їх вплив на контейнери

Оскільки контейнери використовують ядро хоста, будь-які вразливості в ядрі впливають на всі контейнери. Прикладом є CVE-2022-0492 — вразливість високої серйозності, пов'язана зі слабкістю в обробці release_agent у cgroup, що за певних обставин може дозволити вихід із контейнера. Водночас, експлуатація Dirty COW, навіть усередині добре ізольованого контейнера, може призвести до отримання root-доступу на вразливому хості.

Безпека Docker-середовища починається з базових принципів захисту, які створюють фундамент для безпечної роботи контейнерів. Зрозумівши та впровадивши ці принципи, ми значно зменшуємо поверхню для атак та зміцнюємо наше середовище контейнеризації.

Вибір та налаштування безпечної операційної системи хоста

Захист Docker-середовища неможливий без належного захисту системи хоста. Відповідно до рекомендацій експертів, варто обирати мінімалістичні операційні системи, як-от Kata Containers, Flatcar Container Linux, Bottlerocket або Ubuntu Minimal. Такі системи мають меншу поверхню для атак через відсутність непотрібних компонентів. Також важливо обмежити прямий доступ до хоста, надаючи його лише необхідним адміністраторам, та активувати firewall через налаштування брандмауерів. Безпека контейнерів напряму залежить від захищеності базової системи — нехтування цим аспектом зведе нанівець найсильніші засоби захисту контейнерів.

Регулярне оновлення Docker Engine та компонентів

Оновлення Docker Engine — один із найпростіших способів підтримки безпеки контейнерів. Оновлення зазвичай містять патчі вразливостей, які вже відомі. Наприклад, у версії 28 було виправлено проблему, коли після перезавантаження firewalld опубліковані порти контейнерів ставали доступними з локальної мережі, навіть якщо вони мали бути доступні лише через loopback-адресу.

Процес оновлення Docker включає:

• оновлення індексу пакетів системи;
• видалення старіших версій Docker для уникнення конфліктів.

Запуск контейнерів від імені непривілейованих користувачів

За замовчуванням контейнери запускаються з правами користувача root, що збільшує ризики безпеки. Зміна цієї поведінки можлива трьома способами:

• під час виконання через опцію -u команди docker run;
• під час збірки через додавання інструкції USER у Dockerfile;
• через активацію підтримки простору імен користувачів.

Ще одним варіантом є запуск у режимі rootless, який дозволяє запускати демон Docker та контейнери без привілеїв root. Цей режим не використовує бінарні файли з бітами SETUID або можливостями файлів, окрім newuidmap та newgidmap.

Що таке Distroless образи

Distroless (Google Distroless) — це спеціальні контейнерні образи, в яких немає повноцінної Linux-дистрибутивної бази (як у Debian, Alpine чи Ubuntu).

Вони містять тільки:

• потрібні бібліотеки рантайму (glibc, Java runtime, Python runtime тощо);
• мінімальні системні залежності;
• сам додаток.

Немає package manager (apt, yum, apk), немає shell (bash, sh), немає «зайвих» утиліт.

Тобто, образ максимально «чистий»: тільки те, що потрібно для запуску програми.

Як це працює:

Базовий рівень — невеликий образ з бібліотеками і рантаймом.

Наприклад:

gcr.io/distroless/base

gcr.io/distroless/python3

gcr.io/distroless/java17

Додаток додається поверх через COPY у Dockerfile.

У контейнері немає звичного доступу для дебагу (bash, ls, curl відсутні).

Це підвищує безпеку (менше поверхні атаки) і розмір (мінімальний образ).

Distroless — назва від Google Container Tools. Інколи кажуть minimal images, slim images, але це не зовсім те саме (наприклад, python:3.12-slim все ще має Debian всередині).

Distroless — це саме образ без дистрибутива, тільки з бібліотеками й рантаймом.

Варіанти Distroless образів

Google підтримує кілька варіантів (репозиторій: github.com/GoogleContainerTools/distroless):

base — базовий образ без мови.

cc — для C/C++ програм.

java17, java21, java8 — для Java.

Використання read-only файлових систем

Запуск контейнерів із файловою системою лише для читання — ефективний спосіб запобігання модифікаціям. Такий підхід вважається хорошою практикою та вимогою у багатьох компаніях. Відповідно до досліджень, це запобігає встановленню нових пакетів, зміні дозволів, створенню облікових записів або впровадженню виконуваних файлів зловмисниками. Для активації цього режиму використовуйте прапорець --read-only:

docker run --read-only alpine

Якщо додатку потрібно тимчасово зберігати дані, можна комбінувати прапорець --read-only з --tmpfs.

Захист Docker-інфраструктури вимагає комплексного підходу на всіх етапах життєвого циклу контейнерів. Впровадження безпеки від початку розробки до виконання допомагає виявляти та усувати вразливості на ранніх стадіях, коли їх виправлення коштує значно дешевше.

Безпека на етапі розробки: статичний аналіз коду

Статичний аналіз коду виявляє вразливості у вихідному коді до їх потрапляння у виробництво. Інтеграція інструментів SAST (Static Application Security Testing), Trivy (Aqua Security) — простий у використанні, знаходить CVE, проблеми з ліцензіями, IaC misconfig. Grype (Anchore) — CLI для сканування образів на вразливості. Clair (CoreOS/Red Hat Quay) — інтегрується з приватними реєстрами.

Безпосередньо у CI/CD-конвеєр дозволяє ідентифікувати проблеми безпеки під час розробки.

Використання спеціалізованих інструментів для аналізу Dockerfile допомагає знаходити типові помилки конфігурації:

• відсутність директиви USER;
• використання непінованих версій базових образів;
• небезпечні практики, як-от curl-bashing у RUN-директивах;
• некоректне використання ADD замість COPY.

Безпека на етапі збірки: перевірка залежностей

Образи контейнерів містять численні залежності, які можуть мати вразливості. Інтеграція сканування образів у процес збірки дозволяє виявляти проблеми ще до розгортання. Основою безпеки на цьому етапі є підтримка програми управління вразливостями для швидкого усунення виявлених проблем безпеки.

Безпека на етапі розгортання: підписання образів

Docker Content Trust (DCT) забезпечує, що розгортаються лише підписані та перевірені образи. Цифрові підписи підтверджують автентичність та цілісність контейнерних образів. Для активації DCT достатньо встановити змінну середовища DOCKER_CONTENT_TRUST=1. Підписання образів створює «відбиток», який згодом можна криптографічно перевірити для підтвердження довіри.

Безпека на етапі виконання: моніторинг та логування

Моніторинг діяльності контейнерів під час виконання допомагає виявляти та реагувати на інциденти безпеки в режимі реального часу. Впровадження рішень для моніторингу та логування забезпечує видимість дій контейнерів, що критично для виявлення аномальної поведінки — часто першої ознаки інциденту безпеки. Однак безпека не закінчується розгортанням — постійний моніторинг виконання та регулярне оновлення середовища контейнерів є вирішальними для підтримки надійного захисту.

Впровадження безпеки Docker у великих організаціях потребує системного підходу, що охоплює не лише технічні аспекти, але й організаційні процеси. Успішна стратегія безпеки будується на основі кількох ключових елементів.

Розробка політик безпеки для Docker-середовища

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

Організаціям необхідно розробити чіткі політики, що охоплюють:

• використання безпечних конфігурацій контейнерів;
• регулярне сканування образів;
• моніторинг виконання контейнерів;
• впровадження контролю доступу на основі ролей.

Використання приватних реджестрі для базових образів

Для забезпечення безпеки та відповідності регуляторним вимогам:

• дозволяється використовувати лише ті базові образи, які зберігаються у приватному корпоративному реджестрі (Harbor, Artifactory, ECR, GCR, ACR тощо);
• усі базові образи повинні проходити попередню перевірку безпеки (сканування на CVE, валідацію ліцензій, контроль версій);
• забороняється використовувати безпосередньо образи з глобальних публічних реджестрі (наприклад, docker.io/library/*, ghcr.io/*), якщо вони не пройшли внутрішній процес перевірки та реплікації у корпоративний реєстр.

Має бути налаштований policy control у CI/CD:

• блокування використання образів, які не мають джерела у приватному реєстрі;
• аудит усіх нових тегів та їхня перевірка перед публікацією у внутрішньому репозиторії.

Навчання команди розробників принципам безпеки

Згідно з дослідженнями, навчання розробників принципам безпеки контейнерів є критично важливим компонентом.

Програми навчання мають охоплювати:

• методи безпечної побудови образів;
• захист Docker Daemon;
• конфігурації безпеки під час виконання;
• моніторинг за допомогою інструментів Sysdig Falco та Tracee.

Інтеграція з існуючими системами безпеки

Вбудовування Docker у корпоративну інфраструктуру безпеки передбачає інтеграцію з:

• системами моніторингу на основі Wazuh, CrowdStrike;
• рішеннями управління секретами, як-от HashiCorp Vault;
• централізованими системами логування, такими як Elastic Stack або Splunk.

Docker завершив аудит SOC 2 Type 2 за період з листопада 2023 по січень 2024 року. Проходить щорічні перевірки відповідності. У квітні 2024 року Docker отримав сертифікацію ISO 27001. Ці кроки підтверджують, що компанія Docker дотримується міжнародних стандартів безпеки та захисту даних.

Внутрішній аудит та моніторинг у корпоративному середовищі

Для забезпечення постійної відповідності регуляторним вимогам в інфраструктурі компанії необхідно проводити регулярні перевірки:

• активності демона Docker;
• директорій /var/lib/docker та /etc/docker (цілісність, права доступу, зміни);
• сервісів docker.service та docker.socket (стан, конфігурація, логування).

Це внутрішні операційні процеси, що гарантують безперервний контроль за середовищем.

Планування реагування на інциденти безпеки

План реагування на інциденти має включати три основні напрямки: превентивні заходи, збереження даних та процедури розслідування. Під час інциденту критично:

• не знищувати вузол після компрометації;
• визначити необхідні дані для аналізу;
• мати план захоплення цих даних;
• знати, як зробити знімок хоста з volumes.

Отже, безпека Docker-контейнерів стала надзвичайно важливим аспектом розробки сучасних вебдодатків. З огляду на зростання кількості та складності загроз, наша стратегія захисту повинна бути всеосяжною та багаторівневою. Безсумнівно, впровадження принципів «безпеки за замовчуванням» значно зменшує ризики, пов'язані з вразливостями базових образів, виходом із контейнерів та неправильними конфігураціями.

Безпечне Docker-середовище починається з фундаментальних заходів:

• вибір мінімалістичної операційної системи хоста;
• регулярне оновлення Docker Engine та всіх компонентів;
• запуск контейнерів від імені непривілейованих користувачів;
• використання файлових систем лише для читання.

Водночас захист має охоплювати весь життєвий цикл контейнерів – від статичного аналізу коду на етапі розробки до моніторингу під час виконання. Додатково, впровадження безпеки в корпоративному середовищі вимагає розробки чітких політик, навчання команди розробників та інтеграції з існуючими системами захисту.

Насамкінець варто підкреслити, що безпека контейнерів – це безперервний процес, а не одноразовий захід. Тому регулярні аудити, оновлення та адаптація до нових загроз залишаються критично важливими для підтримки надійного захисту наших Docker-середовищ. Лише завдяки комплексному підходу та постійній пильності ми можемо ефективно протистояти викликам безпеки у світі контейнеризації.