Ви можете запускати Docker у виробництві місяцями без видимих проблем. Контейнери запускаються, додатки відповідають, нічого не ламається. Тоді один відкритий порт або один неправильно налаштований дозвіл створює точку опори, яку зловмиснику не потрібно було заробляти. Більшість помилок безпеки Docker не виглядають як помилки, доки щось не піде не так.
Ця стаття охоплює конкретні конфігурації, які загрожують контейнерним середовищам, що кожна з них дозволяє зловмиснику, і закінчується контрольним списком, який можна застосувати для власних налаштувань вже сьогодні.
Чому захист Docker складніше, ніж здається
Контейнери відчувають себе ізольованими. Ви починаєте один, він запускає власний простір процесів, і всередині нього наступного контейнера не існує. Ви отримуєте ізоляцію, але лише часткову. Контейнери спільно використовують ядро хоста, що означає, що процес всередині контейнера може, за певних умов, повністю досягти хост-системи.
Кораблі докерів налаштовані для зручності розробників, а не для підвищення продуктивності. Root доступ увімкнено. Усі порти можна прив’язати до всіх інтерфейсів. Немає моніторингу часу виконання. Більшість розробників приймають ці налаштування, відправляють контейнер і йдуть далі. Це розумний підхід для початку; це не завершена поза безпеки.
Відповідно до Звіт Red Hat про стан безпеки Kubernetes за 2024 рік67% організацій відклали або уповільнили розгортання додатків через проблеми з безпекою контейнера або Kubernetes. Це тертя зазвичай не від нападів. Команди виявили, що їхні налаштування контейнерів потребують посилення, яке вони не вбудували.
Ми часто бачимо, як контейнери працюють у виробництві з тією ж конфігурацією, що й на локальній машині розробника. Ось де помилки безпеки Docker, як правило, поєднуються тихо, без видимих симптомів, доки щось не буде перевірено або не вийде.
Помилки, які створюють ці прогалини, є специфічними, передбачуваними та здебільшого їх можна уникнути, починаючи з рівня конфігурації.
Поширені помилки конфігурації Docker
Більшість злому контейнерів не починаються з експлойту нульового дня. Вони починають із конфігурації, встановленої в перший день, не замислюючись про доступ до мережі чи обсяг привілеїв.
Налаштування Docker за замовчуванням створені для роботи. Розрив між функціональністю та безпекою є місцем, де накопичуються ризики для безпеки контейнера Docker, особливо в налаштуваннях, які розміщуються самостійно, і ніколи не повертаються до них.
Ми часто бачимо цей шаблон: контейнери на загальнодоступних IP-серверах із прив’язками до портів, налаштуваннями користувача та конфігураціями мережі точно такими, якими вони були під час початкового розгортання.
Запуск контейнерів від імені root
Коли ви запускаєте контейнер Docker без вказівки користувача, він запускається як root. Це означає, що будь-який процес усередині контейнера, включаючи вашу програму, має привілеї кореневого рівня в просторі імен контейнера.
Корінь всередині контейнера — це не те саме, що корень на хості, але розділення не є абсолютним. Експлойти підвищення привілеїв, націлені на середовище виконання, як-от добре задокументований runc CVE-2019-5736 і подібні недоліки середовища виконання, часто потребують кореневого контейнерного процесу для успішного виконання.
Некореневі контейнери усувають вимоги кореневого процесу, від яких залежать ці експлойти, значно звужуючи поверхню атаки для цього класу вразливості, хоча вони не усувають повністю ризик виходу контейнера.
Це вирішує додавання директиви USER до вашого Dockerfile. Деякі офіційні зображення постачаються з непривілейованим користувачем, якого можна активувати за допомогою директиви USER, але багато хто все ще за замовчуванням має root-права без будь-якого користувача готової програми. У таких випадках ви створюєте користувача у Dockerfile перед тим, як перейти до нього. Для більшості налаштувань, розміщених самостійно, ця єдина зміна усуває цілу категорію ризику ескалації.
Відкриття занадто багатьох портів для публічного Інтернету
Коли ви публікуєте порт за допомогою Docker, Docker безпосередньо записує власні правила iptables. Ці правила виконуються перед правилами брандмауера на рівні хоста. Це а добре відома поведінка, про яку повідомляє спільнота і задокументовано в посібнику з фільтрації пакетів Docker, а не неправильна конфігурація, і це означає, що UFW та подібні інструменти не блокують те, що вже відкрито Docker.
Docker записує безпосередньо в iptables, минаючи стандартні налаштування UFW і firewalld на багатьох хостах Linux. Це означає, що порт, прив’язаний до 0.0.0.0, може бути загальнодоступним, навіть якщо ваш брандмауер виглядає налаштованим. Хмарні групи безпеки та правила ланцюжка DOCKER-USER усе ще можуть блокувати цей трафік, тому фактичний ризик залежить від ваших конкретних налаштувань мережі.
Прив’язуйте служби до 127.0.0.1, де це можливо, направляйте загальнодоступний трафік через зворотний проксі та публікуйте лише те, що справді потребує зовнішнього доступу. Зворотний проксі — це найнадійніший спосіб контролювати те, що відкривається ззовні хосту.
Ігнорування ізоляції мережі між контейнерами
Будь-який контейнер у цій мережі може зв’язуватися з будь-яким іншим контейнером без обмежень. Міст за замовчуванням не застосовує фільтрації трафіку між контейнерами, які його спільно використовують, і більшість налаштувань ніколи не змінюють цю конфігурацію.
Якщо один контейнер скомпрометовано, цей відкритий зв’язок стає бічним шляхом руху. Інтерфейсний контейнер може отримати доступ до бази даних, внутрішнього API або будь-чого іншого в тій самій мережі мосту за замовчуванням, навіть якщо такий доступ не був призначений.
Мережі, визначені користувачем, дають вам чіткий контроль над тим, які контейнери можуть обмінюватися даними, але єдина спеціальна мережа, спільна для всіх ваших служб, усе ще дозволяє вільний трафік між контейнерами. Справжня ізоляція вимагає розміщення служб, які не повинні спілкуватися одна з одною, в окремих мережах. Вимкнення стандартного мосту є початковою точкою, а не фінішною лінією.
З видом на Docker Socket
Сокет Docker за адресою /var/run/docker.sock — це інтерфейс керування всім механізмом Docker. Встановлення його в контейнер надає цьому контейнеру прямий API-доступ до демона, що працює на хості.
З таким доступом контейнер може запускати нові контейнери, монтувати каталоги хостів, перевіряти та змінювати запущені контейнери та ефективно контролювати хост-машину. Поверхня атаки еквівалентна root на хості, тому будь-який інструмент, який потребує доступу до сокета, заслуговує на ретельну оцінку.
Для більшості випадків використання існують безпечніші альтернативи: API з областю дії або Інструменти керування Docker які не потребують доступу до сокета. Docker-in-Docker має власні компроміси щодо безпеки та роботи, і не є простою заміною.
Помилки конфігурації створюють початкову експозицію. Вибір зображення та залежностей визначає, як цей вплив поєднується з часом.
Зображення та секрети помилок, які пережили контейнер
Коли ви зупиняєте контейнер, помилки конфігурації всередині нього припиняються разом з ним. Під час перебудови з образу, який містить уразливість або жорстко закодовані облікові дані, проблема перезапускається з контейнером. Помилки на рівні зображення не скидаються між розгортаннями.
Вони переміщаються з образом у кожне середовище, яке його завантажує, кожен реєстр, який його зберігає, і кожного члена команди, який його запускає. Ця наполегливість робить керування зображеннями та секретами окремою категорією ризику, яку варто перевіряти окремо від конфігурації.
Ми часто бачимо таку модель: образ, ретельно вибраний на початку проекту і з тих пір ніколи не перебудовувався, повільно віддаляючись від початкового базового рівня безпеки.
Використання ненадійних або застарілих зображень
Публічні реєстри відкриті для всіх. Шкідливі образи поширювалися через Docker Hub із криптомайнерами та бекдорами, вбудованими в історію шарів, які зберігаються під час перезапуску контейнера. Перевірка перед видаленням має значення, особливо для зображень від неофіційних або невідомих видавців.
Окрема проблема – несвіжість. Офіційний образ, який ви створили шість місяців тому і з тих пір ніколи не відновлювали, накопичував невиправлені вразливості Docker з кожним розкритим CVE для його пакетів. Зображення не зіпсоване. Це вже не актуально.
Звіт Sonatype про стан ланцюга постачання програмного забезпечення за 2024 рік було виявлено, що в 95% випадків використовується вразливий компонент, виправлена версія вже доступна, а 80% залежностей програми не оновлюються більше року. Цей шаблон також стосується базових зображень Docker, оскільки вони покладаються на ті самі пакети з відкритим кодом.
Використовуйте офіційні зображення від перевірених видавців і закріплюйте конкретні теги версії, а не покладайтеся на «останні». Створіть регулярну частоту відновлення, щоб ваші зображення були актуальними.
Секрети жорсткого кодування в Dockerfiles і Compose Files
Облікові дані, записані в інструкції Dockerfile ENV або ARG, жорстко закодовані в блоці середовища Compose, передані як аргументи збірки або збережені у файлі .env, призначеному для контролю версій, не зникають, коли ви зупиняєте контейнер. Вони зберігаються в історії шару зображення або в системі керування джерелами, доступні кожному, хто може отримати доступ до них.
Це одна з найбільш забутих помилок безпеки Docker, оскільки вона не викликає видимих проблем під час розробки. Ключ API в інструкції ENV працює правильно. Він також знаходиться у вашому сховищі, запікається у ваше зображення та розповсюджується всюди, куди це зображення подорожує.
Modern Docker Compose підтримує власний механізм секретів, який монтує облікові дані під час виконання, не запікаючи їх у образ. API секретів Docker і менеджери зовнішніх секретів дотримуються того самого принципу. Це параметри, які повністю зберігають облікові дані від артефактів збірки та зафіксованих файлів.
Змінні середовища виконання є покращенням порівняно з жорстко закодованими обліковими даними, але вони все ще доступні через вихідні дані перевірки Docker, журнали та аварійні дампи. Вони є кроком уперед від запальних секретів, а не готовим рішенням.
Зображення контейнерів не оновлюються регулярно
Виконувати одне й те саме зображення місяцями – поширена звичка. Кожен день після виявлення нової вразливості, але до того, як ви перебудуєте, ваші контейнери містять вікно експозиції, яке зростає без видимих змін.
Створіть послідовний графік відновлення. Автоматизуйте цей процес, де це можливо, і періодично запускайте сканер уразливостей для ваших поточних зображень. Мета – не досконалість. Це скорочує час між випуском патча та його розгортанням.
У швидкому розгортанні контроль доступу та моніторинг можуть втратити пріоритетність. Це також категорії, у яких інциденти залишаються непоміченими найдовше.
Прогалини контролю доступу та видимості
Після того, як контейнер працює з надійною конфігурацією та поточними зображеннями, залишаються дві категорії помилок. Обидва невидимі за своєю природою: ви не помітите слабку проблему контролю доступу, доки хтось нею не скористається, і ви не помітите прогалину моніторингу, доки вам не знадобиться дослідити дії, які ніколи не реєструвалися.
Те саме Дослідження Red Hat 2024 виявили, що 42% команд не мають достатніх можливостей для вирішення проблем безпеки контейнерів і пов’язаних із цим загроз.
Ми виявили, що прогалини в моніторингу зазвичай виявляються під час розслідування інцидентів, а не раніше. До того часу, коли видимість стає пріоритетом, вона часто реагує на щось, а не запобігає цьому.
Слабка автентифікація та відкриті інформаційні панелі керування
Інформаційна панель керування контейнером на загальнодоступній IP-адресі без автентифікації не потребує досвідченого зловмисника. Це вимагає від них знати адресу. Це нижча планка, ніж усвідомлює більшість команд.
Власні інструменти моніторингу та керування зазвичай постачаються з веб-інтерфейсом, доступним на всіх мережевих інтерфейсах. Залишити тих, хто знаходиться на загальнодоступній IP-адресі, без автентифікації перед ними, це те ж саме, що залишати панель адміністратора розблокованою.
Автентифікація, зворотний проксі та розміщення в приватній мережі є базовими. Контроль доступу – це крок конфігурації, який ви додаєте до будь-якого інтерфейсу керування, а не те, що поставляється ввімкненим.
Той самий принцип застосовується до Управління Docker CLI та GUI; доступ на рівні адміністратора до демона несе однаковий ризик незалежно від інтерфейсу.
Не слідкувати за тим, що роблять ваші контейнери
Якщо контейнер скомпрометовано, дія зловмисника створює слід: зміни в поведінці процесу, незвичайні мережеві підключення та неочікувані модифікації файлів. Без збору журналів цей шлях не існує в тому вигляді, у якому ви можете діяти.
Централізований збір журналів, ведення журналів аудиту контейнерів і інструменти моніторингу під час виконання дають вам дані для виявлення аномальної активності до того, як вона з’явиться. Мета полягає не в аналізі кожного рядка. Це наявність даних, коли вам потрібно провести розслідування.
Налаштування контейнерів, які безшумно працюють у виробництві без конвеєра журналів і сповіщень, не вимагають малообслуговування. Вони неперевірені. Це два різних робочих стани.
Чому інфраструктурне середовище також має значення
Безпека контейнера починається з конфігурації, але конфігурація працює поверх інфраструктури. Хост із неправильно налаштованою мережею, спільними ресурсами або відсутністю фільтрації на рівні мережі створює умови, які впливають на кожен контейнер над ним. Правильне налаштування контейнера та правильна конфігурація сервера — це два окремі завдання.
Багато прогалин у безпеці Docker посилюються умовами, які успадковують самі контейнери:
- Спільний сервер оренди без апаратної ізоляції між орендарями
- Ядро хоста працює без виправлень
- Хост без вбудованої фільтрації на рівні мережі
Це не скасовує потреби у наведених вище кроках конфігурації, оскільки належне зміцнення контейнера має значення незалежно від рівня інфраструктури. Початок роботи на ізольованій інфраструктурі усуває з рівняння один рівень занепокоєння.
У Cloudzy ми пропонуємо два шляхи залежно від ваших налаштувань:
- Linux VPS: чисте середовище для самостійного розгортання Docker і застосування кроків захисту, наведених у цій статті
- Portainer VPS: опція в один клік із попередньо встановленим Portainer; сервер завантажується, і ви вже на інформаційній панелі
Обидва варіанти працюють на одній інфраструктурі: віртуалізація KVM, процесори AMD Ryzen 9 із тактовою частотою до 5,7 ГГц, пам’ять DDR5, сховище NVMe SSD, мережа зі швидкістю до 40 Гбіт/с і безкоштовний захист від DDoS за допомогою фільтрації BuyVM у 12 глобальних місцях із гарантією безвідмовної роботи 99,95% за угодою про рівень обслуговування.
Щоб глибше ознайомитись із запуском Portainer на VPS, ми розглянемо це у спеціальній статті.
Практичний контрольний список безпеки для розгортання Docker
Наведені вище помилки безпеки Docker здебільшого походять від одноразових конфігураційних рішень, прийнятих один раз і ніколи не повертаються. Виконання цього контрольного списку з наявними налаштуваннями виявляє ці прогалини. Він працює як перевірка, а не як посібник із розгортання.
Ці найкращі методи безпеки Docker описують, як захистити контейнери Docker від найпоширеніших помилок конфігурації, описаних вище.
Короткий довідник: усі 9 помилок
| помилка | Категорія | One-Line Fix |
| Запуск від імені root | Конфігурація | додати КОРИСТУВАЧ у ваш Dockerfile |
| Порти прив’язані до 0.0.0.0 | Конфігурація | Прив’яжіть до 127.0.0.1 і проведіть через зворотний проксі |
| Відсутність ізоляції мережі | Конфігурація | Розділіть послуги між окремими визначеними користувачами мережами на основі потреб доступу. |
| Розетка докера встановлена | Конфігурація | Зняти кріплення; використовувати API або альтернативи |
| Ненадійні або застарілі зображення | Зображення | Використовуйте офіційні зображення із закріпленими тегами версії |
| Жорстко закодовані секрети | Зображення | Перемістіть облікові дані до змінних середовища виконання або диспетчера секретів |
| Немає графіка відновлення зображення | Зображення | Встановіть щомісячну частоту відновлення; автоматизувати, де це можливо |
| Неавтентифіковані інформаційні панелі | Доступ | Додайте автентифікацію та перемістіть інтерфейси керування в приватні мережі |
| Немає збору журналів контейнерів | Доступ | Налаштуйте централізоване ведення журналів і моніторинг виконання |
Ми рекомендуємо спочатку запустити його проти існуючих налаштувань, оскільки саме там, швидше за все, уже присутні прогалини.
Контейнери, що працюють як некореневі: Перевірте свої файли Docker на наявність директиви USER. Якщо такого не існує, контейнер працює як root.
Прив’язки до портів обмежено локальним хостом або проксі: Запустіть docker ps і перегляньте прив’язки портів. Запис 0.0.0.0:PORT може бути загальнодоступним на хостах, де його не блокує жодна група безпеки, зовнішній брандмауер або правило ланцюжка DOCKER-USER.
Користувацькі мостові мережі, що використовуються: Контейнери на типовому мосту Docker можуть вільно досягати один одного. Контейнери на тому самому визначеному користувачем мосту все ще можуть спілкуватися один з одним, тому розділіть служби між окремими мережами за кордоном довіри для фактичної ізоляції.
Розетка докера не встановлена в контейнерах: Позначте «Створювати файли та запускати аргументи». Якщо /var/run/docker.sock відображається як том, підтвердьте, що це обов’язково та навмисно.
Базові зображення від перевірених видавців із закріпленими версіями: FROM ubuntu:latest отримує невизначену, потенційно застарілу версію. Закріпити на певному випуску.
Жодних секретів у Dockerfiles, Compose files або build arguments: Історія шару зображення зберігає облікові дані після видалення контейнера. Використовуйте секрети Compose, Secrets Swarm, створюйте секретні монтування або зовнішній менеджер секретів. Змінні середовища виконання кращі, ніж жорстко закодовані значення, але все одно відображаються в результатах перевірки та журналах.
Визначено графік відновлення зображення: Старі зображення накопичують вразливі місця. Щомісячна частота відновлення дає змогу керувати вікном експозиції для більшості налаштувань.
Інтерфейси керування за автентифікацією: Будь-яка інформаційна панель на загальнодоступній IP-адресі без авторизації є відкритою точкою входу. Приватне розміщення мережі є кращим, якщо це можливо.
Збір контейнерних журналів: Без конвеєра журналу виявлення інцидентів залежить від видимого впливу на систему. Це пізній сигнал, на який потрібно діяти.
Висновок
Конфігурація Docker за умовчанням створена для зручності, а не для безпеки. Більшість помилок, розглянутих у цій статті, походять від налаштувань, які ніколи не змінювалися після початкового розгортання, а не від складних атак.
Виправлення — це здебільшого одноразові конфігураційні рішення: директива USER, зміна прив’язки порту, спеціальна мережа, розклад перебудови. Жоден із них не вимагає нових інструментів для більшості налаштувань.
Першим завданням є правильна конфігурація контейнера. Інфраструктура, на якій він працює, є другою. Обидва мають значення, і жоден не замінює іншого.
