Як шкідливі образи Docker потрапляють до надійних PipelineНепомічено
Реєстр Docker — це серце будь-якого контейнеризованого робочого процесу. Він зберігає, розповсюджує та версіонує образи. Але якщо залишити його відкритим або слабо контролювати, зловмисники можуть впроваджувати шкідливі образи Docker безпосередньо в pipelines.
Як це відбувається:
- Відкриті політики витягування: pipeline светри myorg/base: найновіший без перевірки джерела чи цілісності
- Скомпрометовані облікові записиЗловмисники отримують доступ до реєстру контейнерів та замінюють довірені образи.
- ТипоскватінгРозробники помилково витягують myorg-base замість myorg/base
Приклад у завданні GitLab CI:
Тут, вузол:останній може змінитися за одну ніч. Якщо зловмиснику вдасться опублікувати отруєний останній зображення, він автоматично витягується. Безпечна версія:
Блокування образів до певної версії запобігає тихому дрейфу. Шкідливий образ Docker може потрапити, лише якщо ви сліпо довіряєте «latest».
Чому не всі реєстри Docker безпечні за замовчуванням
Не кожен реєстр Docker застосовує суворі налаштування за замовчуванням. Розробники часто довіряють публічним джерелам, не перевіряючи походження. Ризики включають:
- Неавтентифіковані витягування з публічних реєстрів контейнерів
- Непідписані зображення без жодних доказів того, хто їх збудував
- Сторонні реєстри зі слабкою політикою, що призводить до підробки базових зображень
Приклад невпевненої поведінки:
Небезпека: ви не знаєте, хто його побудував, коли або що всередині. Безпечніший підхід:
Завжди перевіряйте видавця, перевіряйте криптографічну цілісність та віддавайте перевагу перевіреним офіційним реєстрам. Припущення, що кожен реєстр Docker безпечний за замовчуванням, створює сліпі зони в ланцюжку поставок.
Забезпечення походження зображень за допомогою підписів та контролю доступу
Щоб запобігти появі шкідливих образів Docker, команди DevSecOps повинні забезпечувати перевірку походження образів. Це означає перевірку автентичності, перш ніж будь-який образ потрапить на етап розробки, тестування або виробництва. Найкращі методи:
- Підписування зображеньВикористовуйте Docker Content Trust або Sigstore для підписання образів
- Політики RBACОбмежте, хто може надсилати або отримувати дані з реєстру контейнерів
АтестаціїВимагати метадані, що підтверджують, як і де було створено зображення. Приклад із довірою до контенту Docker:
Якщо ввімкнено довіру, непідписані образи відхиляються. У поєднанні з RBAC це запобігає вставлянню отруєних збірок до реєстру Docker зловмисними користувачами.
Автоматизація перевірок безпеки зображень CI/CD Pipelines
Ручна перевірка не масштабується. Перевірки безпеки мають бути автоматизовані, щоб блокувати шкідливі образи Docker до їх поширення.
Техніка:
- Політичні механізмиТакі інструменти, як OPA Gatekeeper, забезпечують дотримання дозволених реєстрів та тегів
- Сканери уразливостей: Автоматичний аналіз зображень на наявність відомих CVE
- Pipeline гвардіяБлокування розгортання відбувається, якщо зображення не відповідає вимогам до підпису або сканування.
CI/CD Приклад
Міні-контрольний список для розробників (CI/CD Безпека реєстру)
- Ніколи не використовуйте останній теги у виробництві pipelines
- Отримувати дані лише з перевірених реєстрів Docker
- Застосувати криптографічний підпис для кожного зображення
- Сканування зображень під час збірки та розгортання
- Автоматично блокувати непідписані або невідскановані зображення
Автоматизація перевірок гарантує, що зловмисники не зможуть підкрасти шкідливий образ Docker, поки розробники пишуть код.
Побудова безпечної стратегії реєстру Docker за принципами DevSecOps
Захищений реєстр Docker — це більше, ніж просто система зберігання даних; це частина вашої системи безпеки. Основні практики:
- Обмежте операції push/pull лише довіреними обліковими записами
- Сегментація реєстрів за середовищем (розробка, проміжне, виробництво)
- Увімкнути журнал аудиту для кожної дії реєстру
- Регулярно очищуйте невикористовувані зображення, щоб зменшити поверхню атаки
Реєстр контейнерів, узгоджений з Принципи DevSecOps гарантує, що кожне зображення, що рухається через pipeline контрольовано, відстежувано та захищено.
Рішення типу Ксігені покращити це шляхом постійного моніторингу реєстрів та pipelineдля несанкціонованих або підроблених зображень. Вони забезпечують guardrails тому до розгортання потрапляють лише перевірені зображення.
Блокування реєстру Docker
Ваш реєстр Docker є частиною вашої поверхні для атаки. Якщо зловмисники впровадять шкідливі образи Docker, ваш CI/CD pipeline може стати системою доставки своїх корисних вантажів. Висновки для розробників очевидні:
- Не довіряйте значенням за замовчуванням: перевірте кожне джерело зображення
- Закріпіть версії та уникайте останній
- Автоматизуйте сканування та забезпечте дотримання політик підписування
- Ставтеся до реєстру контейнерів як до критично важливої інфраструктури
Інтеграція безпеки реєстру у ваш робочий процес DevSecOps знижує ризик непомітного поширення отруєних збірок крізь середовища. Такі інструменти, як Xygeni, роблять це практичним, забезпечуючи видимість прихованих ризиків реєстру, забезпечуючи дотримання політик та виявляючи підроблені образи до їх публікації. Блокування реєстру Docker стосується не лише сховища, а й контролю над усім ланцюжком постачання контейнерів. Розробники, які розглядають реєстри як межу безпеки, зупиняють зловмисників ще до того, як вони досягнуть середовища виконання.
