Docker Security
Last updated
Вивчайте та практикуйте взлом AWS: Навчання HackTricks AWS Red Team Expert (ARTE) Вивчайте та практикуйте взлом GCP: Навчання HackTricks GCP Red Team Expert (GRTE)
Використовуйте Trickest для легкої побудови та автоматизації робочих процесів за допомогою найбільш продвинутих інструментів спільноти. Отримайте доступ сьогодні:
Двигун Docker використовує Простори імен та Cgroups ядра Linux для ізоляції контейнерів, що надає базовий рівень безпеки. Додатковий захист забезпечується за допомогою відмови в можливостях, Seccomp та SELinux/AppArmor, покращуючи ізоляцію контейнерів. Автентичний плагін може додатково обмежити дії користувача.
До двигуна Docker можна отримати доступ або локально через Unix-сокет, або віддалено за допомогою HTTP. Для віддаленого доступу важливо використовувати HTTPS та TLS для забезпечення конфіденційності, цілісності та аутентифікації.
Двигун Docker за замовчуванням прослуховує Unix-сокет за адресою unix:///var/run/docker.sock
. На системах Ubuntu параметри запуску Docker визначаються в /etc/default/docker
. Щоб дозволити віддалений доступ до API та клієнта Docker, викладіть демона Docker через HTTP-сокет, додавши наступні налаштування:
Однак, викладання демона Docker через HTTP не рекомендується через проблеми з безпекою. Рекомендується застосовувати захист з використанням HTTPS. Існують два основні підходи до захисту з'єднання:
Клієнт перевіряє ідентичність сервера.
Як клієнт, так і сервер взаємно перевіряють ідентичність одне одного.
Для підтвердження ідентичності сервера використовуються сертифікати. Для докладних прикладів обох методів див. цей посібник.
Зображення контейнерів можуть зберігатися як у приватних, так і у публічних репозиторіях. Docker пропонує кілька варіантів зберігання зображень контейнерів:
Docker Hub: Публічний реєстр сервіс від Docker.
Docker Registry: Проект з відкритим кодом, який дозволяє користувачам розміщувати свій власний реєстр.
Docker Trusted Registry: Комерційний реєстр Docker, який пропонує аутентифікацію користувачів на основі ролей та інтеграцію з каталоговими службами LDAP.
Контейнери можуть мати вразливості безпеки через базове зображення або через програмне забезпечення, встановлене поверх базового зображення. Docker працює над проектом під назвою Nautilus, який сканує контейнери на предмет безпеки та перелічує вразливості. Nautilus працює шляхом порівняння кожного шару зображення контейнера з репозиторієм вразливостей для ідентифікації дірок в безпеці.
Для отримання більш докладної інформації прочитайте це.
docker scan
Команда docker scan
дозволяє сканувати існуючі зображення Docker за допомогою назви або ID зображення. Наприклад, виконайте наступну команду для сканування зображення hello-world:
Підпис Docker image забезпечує безпеку та цілісність зображень, що використовуються в контейнерах. Ось стисле пояснення:
Щоб активувати довіру вмісту Docker, встановіть export DOCKER_CONTENT_TRUST=1
. Ця функція за замовчуванням вимкнена в Docker версії 1.10 та пізніших.
З цією функцією активованою, можна завантажувати лише підписані зображення. Перший пуш зображення вимагає встановлення паролів для кореневого та тегового ключів, причому Docker також підтримує Yubikey для підвищеної безпеки. Додаткові деталі можна знайти тут.
Спроба витягнути непідписане зображення з активованою довірою вмісту призводить до помилки "No trust data for latest".
Під час пушу зображення після першого, Docker запитує пароль для ключа репозиторію для підпису зображення.
Для резервного копіювання ваших приватних ключів використовуйте команду:
При переході до нових хостів Docker необхідно перемістити кореневі та ключі репозиторіїв для забезпечення нормальної роботи.
Використовуйте Trickest, щоб легко створювати та автоматизувати робочі процеси за допомогою найбільш продвинутих інструментів спільноти. Отримайте доступ сьогодні:
Простори імен - це функція ядра Linux, яка розділяє ресурси ядра так, що один набір процесів бачить один набір ресурсів, тоді як інший набір процесів бачить інший набір ресурсів. Ця функція працює за допомогою одного і того ж простору імен для набору ресурсів та процесів, але ці простори імен посилаються на різні ресурси. Ресурси можуть існувати в кількох просторах.
Docker використовує наступні простори імен ядра Linux для досягнення ізоляції контейнерів:
pid namespace
mount namespace
network namespace
ipc namespace
UTS namespace
Для додаткової інформації про простори імен перевірте наступну сторінку:
NamespacesФункція ядра Linux cgroups надає можливість обмежувати ресурси, такі як центральний процесор, пам'ять, введення/виведення, мережева пропускна здатність серед набору процесів. Docker дозволяє створювати контейнери з використанням функції cgroup, яка дозволяє контролювати ресурси для конкретного контейнера. Нижче наведено контейнер, створений з обмеженням пам'яті користувача на рівні 500 мб, обмеження пам'яті ядра на рівні 50 мб, частка центрального процесора на рівні 512, blkioweight на рівні 400. Частка центрального процесора - це відношення, яке контролює використання центрального процесора контейнером. Вона має значення за замовчуванням 1024 та діапазон від 0 до 1024. Якщо у трьох контейнерів однакова частка центрального процесора 1024, кожен контейнер може використовувати до 33% центрального процесора в разі конфлікту ресурсів центрального процесора. blkio-weight - це відношення, яке контролює введення/виведення контейнера. Вона має значення за замовчуванням 500 та діапазон від 10 до 1000.
Для отримання cgroup контейнера можна виконати:
Для отримання додаткової інформації перевірте:
CGroupsПрава дозволяють досягти більш точного контролю над правами, які можуть бути дозволені користувачеві root. Docker використовує функцію можливостей ядра Linux для обмеження операцій, які можуть бути виконані всередині контейнера незалежно від типу користувача.
Під час запуску контейнера Docker процес відмовляється від чутливих можливостей, які процес міг би використовувати для виходу з ізоляції. Це спроба забезпечити, що процес не зможе виконувати чутливі дії та виходити:
Linux CapabilitiesЦя функція безпеки дозволяє Docker обмежувати системні виклики, які можуть бути використані всередині контейнера:
SeccompAppArmor - це покращення ядра для обмеження контейнерів до обмеженого набору ресурсів з профілями для кожної програми:
AppArmorСистема міток: SELinux присвоює унікальну мітку кожному процесу та об'єкту файлової системи.
Застосування політики: Вона застосовує політику безпеки, яка визначає, які дії може виконувати мітка процесу щодо інших міток у системі.
Мітки процесів контейнера: Коли контейнерні двигуни запускають процеси контейнера, їм зазвичай призначається обмежена мітка SELinux, зазвичай container_t
.
Мітки файлів у контейнерах: Файли всередині контейнера зазвичай мають мітку container_file_t
.
Правила політики: Політика SELinux в основному забезпечує, що процеси з міткою container_t
можуть взаємодіяти (читати, записувати, виконувати) лише з файлами, які мають мітку container_file_t
.
Цей механізм забезпечує, що навіть якщо процес всередині контейнера скомпрометований, він обмежений взаємодією лише з об'єктами, які мають відповідні мітки, значно обмежуючи можливість завдання шкоди від таких компрометацій.
SELinuxУ Docker авторизаційний плагін відіграє важливу роль у забезпеченні безпеки, вирішуючи, чи слід дозволяти чи блокувати запити до демона Docker. Це рішення приймається шляхом аналізу двох ключових контекстів:
Контекст аутентифікації: Це включає вичерпну інформацію про користувача, таку як хто вони і як вони аутентифікували себе.
Контекст команди: Це включає всі відповідні дані, пов'язані з запитом, який робиться.
Ці контексти допомагають забезпечити, що обробляються лише законні запити від аутентифікованих користувачів, підвищуючи безпеку операцій Docker.
AuthZ& AuthN - Docker Access Authorization PluginЯкщо ви не обмежуєте ресурси, які може використовувати контейнер, скомпрометований контейнер може запустити DoS на хості, де він працює.
CPU DoS
Витрата пропускної здатності
На наступній сторінці ви можете дізнатися, що означає прапорець --privileged
:
Якщо ви запускаєте контейнер, де зловмисник здобуває доступ як користувач з низькими привілеями. Якщо у вас є неправильно налаштований suid бінарний файл, зловмисник може зловживати ним і підвищувати привілеї всередині контейнера. Це може дозволити йому втекти з нього.
Запуск контейнера з увімкненою опцією no-new-privileges
запобігатиме цьому виду підвищення привілеїв.
Для отримання додаткових параметрів --security-opt
перевірте: https://docs.docker.com/engine/reference/run/#security-configuration
Важливо уникати вбудовування секретів безпосередньо в образи Docker або використання змінних середовища, оскільки ці методи викладають вашу чутливу інформацію будь-кому, хто має доступ до контейнера через команди, такі як docker inspect
або exec
.
Томи Docker є безпечнішою альтернативою, рекомендованою для доступу до чутливої інформації. Їх можна використовувати як тимчасову файлову систему в пам'яті, що зменшує ризики, пов'язані з docker inspect
та журналюванням. Однак користувачі з правами root та ті, у яких є доступ до exec
в контейнері, все ще можуть отримати доступ до секретів.
Секрети Docker пропонують ще більш безпечний метод обробки чутливої інформації. Для випадків, коли секрети потрібні під час фази побудови образу, BuildKit пропонує ефективне рішення з підтримкою секретів на етапі побудови, покращуючи швидкість побудови та надаючи додаткові функції.
Для використання BuildKit його можна активувати трьома способами:
Через змінну середовища: export DOCKER_BUILDKIT=1
Шляхом префіксування команд: DOCKER_BUILDKIT=1 docker build .
Активація за замовчуванням у конфігурації Docker: { "features": { "buildkit": true } }
, за якою слідує перезапуск Docker.
BuildKit дозволяє використовувати секрети на етапі побудови за допомогою параметра --secret
, забезпечуючи, що ці секрети не включаються в кеш побудови образу або в кінцевий образ, використовуючи команду:
Для секретів, необхідних у запущеному контейнері, Docker Compose та Kubernetes пропонують надійні рішення. Docker Compose використовує ключ secrets
у визначенні сервісу для вказання секретних файлів, як показано у прикладі docker-compose.yml
:
Ця конфігурація дозволяє використовувати секрети при запуску служб за допомогою Docker Compose.
У середовищах Kubernetes секрети підтримуються на рівні ядра і можуть бути додатково керовані інструментами, такими як Helm-Secrets. Контроль доступу на основі ролей (RBAC) Kubernetes підвищує безпеку управління секретами, подібно до Docker Enterprise.
gVisor - це ядро додатків, написане на мові Go, яке реалізує значну частину поверхні системи Linux. Воно включає рантайм Open Container Initiative (OCI) під назвою runsc
, який забезпечує ізоляційну межу між додатком та ядром хоста. Рантайм runsc
інтегрується з Docker та Kubernetes, що спрощує запуск контейнерів у пісочниці.
Kata Containers - це відкрита спільнота, яка працює над побудовою безпечного рантайму контейнерів з легкими віртуальними машинами, які відчувають себе та працюють як контейнери, але забезпечують сильнішу ізоляцію робочого навантаження за допомогою технології апаратної віртуалізації як другого рівня захисту.
Не використовуйте прапорець --privileged
або монтування сокету Docker всередині контейнера. Сокет Docker дозволяє створювати контейнери, тому це легкий спосіб отримати повний контроль над хостом, наприклад, запустивши інший контейнер з прапорцем --privileged
.
Не запускайте як root всередині контейнера. Використовуйте іншого користувача та простори імен користувачів. Root у контейнері такий самий, як на хості, якщо не перенаправлено за допомогою просторів імен користувачів. Він обмежується, в основному, Linux просторами імен, можливостями та cgroups.
Скиньте всі можливості (--cap-drop=all
) та активуйте лише ті, які потрібні (--cap-add=...
). Багато робочих навантажень не потребують жодних можливостей, а їх додавання збільшує обсяг можливого атаки.
Використовуйте параметр безпеки “no-new-privileges” для запобігання процесам отримання додаткових привілеїв, наприклад через suid-бінарники.
Обмежте ресурси, доступні контейнеру. Обмеження ресурсів може захистити машину від атак на відмову в обслуговуванні.
Використовуйте офіційні образи Docker та вимагайте підписів або створюйте власні на їх основі. Не успадковуйте або не використовуйте заражені образи. Також зберігайте кореневі ключі, пароль на безпековому місці. У Docker є плани керувати ключами за допомогою UCP.
Регулярно перебудовуйте свої образи, щоб застосовувати патчі безпеки до хоста та образів.
Розумно керуйте своїми секретами, щоб важко було зловмиснику отримати до них доступ.
Якщо ви використовуєте демон Docker, використовуйте HTTPS з аутентифікацією клієнта та сервера.
У своєму Dockerfile використовуйте COPY замість ADD. ADD автоматично розпаковує архівні файли та може копіювати файли з URL-адрес. COPY не має цих можливостей. Коли це можливо, уникайте використання ADD, щоб не бути вразливими до атак через віддалені URL-адреси та ZIP-файли.
Маєте окремі контейнери для кожної мікро-служби
Не включайте ssh всередині контейнера, “docker exec” може бути використаний для ssh до контейнера.
Маєте менші образи контейнерів
Якщо ви в контейнері Docker або маєте доступ до користувача в групі docker, ви можете спробувати втечу та підвищення привілеїв:
Docker Breakout / Privilege EscalationЯкщо у вас є доступ до сокету Docker або у вас є доступ до користувача в групі docker, але ваші дії обмежуються плагіном аутентифікації Docker, перевірте, чи можете ви його обійти:
AuthZ& AuthN - Docker Access Authorization PluginІнструмент docker-bench-security - це скрипт, який перевіряє десятки загальних найкращих практик щодо розгортання контейнерів Docker у виробництві. Тести є автоматизованими і базуються на CIS Docker Benchmark v1.3.1. Вам потрібно запустити інструмент з хоста, на якому працює Docker, або з контейнера з достатніми привілеями. Дізнайтеся, як запустити його в README: https://github.com/docker/docker-bench-security.
Використовуйте Trickest, щоб легко створювати та автоматизувати робочі процеси за допомогою найбільш розвинутих інструментів спільноти у світі. Отримайте доступ сьогодні:
Вивчайте та практикуйте взлом AWS: Навчання HackTricks AWS Red Team Expert (ARTE) Вивчайте та практикуйте взлом GCP: Навчання HackTricks GCP Red Team Expert (GRTE)