Docker умер. Да здравствует Docker

30 мая 2024 года ресурс Docker Hub перестал работать на территории России. Служба технической поддержки Docker сообщила, что теперь будет блокировать все IP-адреса, расположенные на Кубе, в Иране, Северной Корее, России, Судане и Сирии. Рассказываем, что это значит и что можем порекомендовать на данном этапе.

Официальный сайт с российского ip-адреса сейчас выглядит так:

Никаких уведомлений для пользователей ресурса перед блокировкой не наблюдалось, кроме новости в разделе «Блог» от 8 марта 2022 г. https://www.docker.com/blog/dockers-response-to-the-invasion-of-ukraine/.

Что это значит и чем грозит?

Ограничение доступа к ресурсу это не только невозможность скачать и загрузить образ, но также невозможность продлить или получить техническую поддержку в необходимом объеме даже по приобретенной подписке (https://www.docker.com/pricing/), так как ресурс в официальном ответе «удалил возможность приобретения подписок из указанных стран».

Самым очевидным способом обхода такого ограничения является подключение к Docker Hub через VPN или использование сторонних «зеркалов» сайта, которых за несколько часов появились десятки. В первом случае, если VPN-сервер не принадлежит лично вам, слабым звеном является само подключение к ресурсу. Во втором — сомнения вызывает скопированная на «зеркало» информация, возрастает риск подмены образа в хранилище.

Рекомендации на будущее

1)    Если вы разработчик и фиксировали у себя SHA-хэш, то в Docker вы можете заказать образ с конкретным SHA.

2)    Для проверки целостности внедрить в процесс разработки практику подписания контейнеров и проверки подписи.

3)    Хранить образы локально.

4)    Подвергать проверке образ.

5)    Использовать в разработке Software Bill of Materials, или SBOM — перечень зависимостей, файлов, библиотек и других элементов, имеющих отношение к конкретному сервису или инфраструктуре целиком. Также рекомендуется проверять перечень перед каждой сборкой. Не рекомендуется пользоваться частными «зеркалами» и неофициальными прокси для доступа к вашим контейнерам. На каждом этапе для исключения внедрения злоумышленниками вредоносного кода стоит провести проверку.

Безопасность

С точки зрения злоумышленников, закрытие Docker Hub – отличная возможность публиковать образы стандартных контейнеров, помещая в них вредоносный код или backdoor’ы.

Мы считаем, что опасность и количество атак на цепочки поставок в ближайшее время возрастет, к этому ведёт тенденция последних лет, сейчас еще и добавилась новость об образах, которыми пользовался почти весь мир.

Снижать возможность атак на цепочки поставок – значит менять процессы и принципы разработки программного обеспечения. Что можно сделать на данном этапе и желательно с небольшими затратами?

Организовать свой container registry и хранить образы локально.

Поднять репозиторий в зарубежных облаках и проксировать запросы на получение образа через них.

Сканировать образ на наличие уязвимостей и бекдоров с помощью SCA-анализаторов.

Следить за изменениями в SBOM.

Проводить поведенческий анализ контейнера во время его работы, и здесь отлично помогут решения класса container security.

Your own container registry

Создать собственный registry можно на базе инструментов с открытым исходным кодом (Gitlab, Harbor, Artifactory). Добывать необходимое для разработки, используя средства обхода, если образ находится всё-таки на запрещенном для РФ ресурсе, и отправлять в свой registry.

SCA images

SCA (Software Composition Analysis) – анализ зависимостей приложения. В данном случае, мы проверяем всё, что лежит внутри контейнера, на наличие уязвимостей.

Для этих целей из Open Source существуют snyk и trivy.

snyk container test : —file=Dockerfile

trivy image —scanners vuln [YOUR_IMAGE_NAME]

А также есть отличные инструменты от российских разработчиков.

SBOM

Software Bill of Materials – документ, содержащий перечень зависимостей приложения. В случае контейнеров термин можно расширить до «перечня всех сущностей приложения», включая, например, пакеты в образе. Следить за его изменением необходимо, регулярно обновляя до и после сборки приложения, а также при сборке целевого образа. Инструментов для этого существует много, например, те же snyk и trivy позволяют создавать SBOM.

Runtime

Ситуация располагает к тому, что не будет центрального авторитетного хранилища образов. А если и будет, то интерфейс работы с ним меняется настолько, что уже неизвестно — с docker hub ли образ, ведь проверить подпись уже не представляется возможным без использования сторонних ресурсов.

Отлично в этом может помочь класс решений container security, позволяющий отследить системные вызовы на самом хосте. Единственное, для более точного определения вторжений и нелегитимных действий внутри контейнера, необходимо писать правила, позволяющие уменьшить количество false-positive сработок. Если вы приверженец Open Source инструментов, то советуем является falco от sysdig или neuvector.

Чем мы можем помочь

УЦСБ развивает собственную платформу безопасной разработки, которая состоит из SAST, SCA, DAST, Fuzzing — готовы оперативно подключиться к процессу верификации используемых контейнеров и выстраиванию процессов по защите цепочек поставок.

Команда направления «Безопасная разработка» УЦСБ

Источник: habr.com

0 0 голоса
Рейтинг новости
0
0
Подписаться
Уведомить о
0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии