Сложности запуска Docker в CI

Когда я писал прошлый пост про работу 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/[email protected]

То происходит следующее:
- 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/home
18+