Когда я писал прошлый пост про работу CI в GitVerse, я получил несколько вопросов относительно: а как работает Docker-in-Docker (DinD) в таком CI? Я спросил ребят, как они планируют реализовать данную фичу в ближайшем будущем. Ответ получился очень интересным.
Со стороны задача "запустить DinD в публичном CI" не выглядит как-то архи-сложно. Однако, на деле как всегда есть нюансы.
Какие вообще есть варианты запуска DinD?
1. Можно взять docker:dind и прокинуть ему
docker.sock, а затем получить побег из курятника, и наблюдать, как пользователи получают полный доступ к машине, где гоняются другие сборки других проектов (с секретами, конечно же). Так делать совершенно точно нельзя!Вот пример, насколько просто сбежать из такого контейнера (в самом простом случае):
# Запускаем контейнер
» docker run --name=first -v /var/run/docker.sock:/var/run/docker.sock -it docker:dind sh
# Внутри docker:
/ # ls -alh /var/run/docker.sock
srwxr-xr-x root /var/run/docker.sock
/ # hostname
700809c044d6 # <- наш текущий хост, контейнер `first`
/ # docker container ls
CONTAINER ID NAMES
e7d7857b965a other
700809c044d6 first
/ # docker exec -it other sh
/ # hostname
e7d7857b965a # <- мы получили доступ к соседнему контейнеру на хосте :(
Тут – просто вопиющий случай, который делает неправильно буквально все: выставляет
docker.sock и использует root внутри контейнера. Даже если вам нужно выставить docker.sock, то есть варианты лучше 2. Можно взять
docker:dind и запустить его с --privileged, прокинуть ему DOCKER_TLS_CERTDIR, запустить второй контейнер "клиент" без --privileged, но с нужными сертификатами, и выполнять все на нем. Такой способ уже безопаснее, но все равно есть много вариантов побега и privilege escalation Я подготовил пример такой сборки: https://gitverse.ru/sobolevn/dind-demo
3. Можно запускать контейнеры в изолированной виртуалке, которая будет быстро стартовать, работать и умирать. 0 рисков, никаких общих сокетов и возможности сбежать
GitHub и Packer
GitHub пошел по третьему пути. Когда мы указываем в actions:
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: wemake-services/wemake-python-styleguide@1.1
То происходит следующее:
- GitHub берет образ виртуалки ubuntu-latest из заранее подготовленных
- Быстро разворачиваем готовый образ при помощи Instant Restore / InPlace Restore из Azure
- GitHub запускает контейнер с
wemake-services/wemake-python-styleguide и выполняет код action внутри dockerНо, внутри образов есть не только docker, там есть всё. Образ ubuntu весит 18GB 🫠
Но есть и минимальные виртуалки без всего. Собираются они при помощи packer.
Планы
GitVerse прямо сейчас разрабатывают что-то очень похожее. В планах:
- Разные ОС: разные linux, macos, windows
- Разные архитектуры: x86_64, arm
Кажется, что такой путь – очень удобный. Быстро, надежно, кастомизируемо.
Подпишись на их канал @gitversenews, чтобы быть в курсе всех новостей. Поддержка заинтересованных в развитии опенсорса продуктов и компаний, таких как GitVerse, помогает мне бесплатно делиться контентом с вами. Спасибо им большое за поддержку и помощь в подготовке поста.
Реклама. АО «СберТех»
ИНН:7736632467 Erid:2W5zFJeNAVn Сайт: https://gitverse.ru/home18+