Варианты запуска сборок

1. Shell executor

   • Небезопасно, т.к. можно выполнять какие угодно docker команды на хосте, в т.ч. пробрасывать хостовые папки и запускать privileged контейнеры

2. docker-in-docker

   • Изолированные друг от друга контейнеры, т.к. здесь child контейнеры от контейнера dind, а не от хостового docker.sock
   • Необходим запуск с privileged (небезопасно)

3. Проброс docker.sock

   • Все контейнеры - siblings (видят друг друга), т.к. запускается через хостовый docker
   • Небезопасно, т.к. можно выполнять какие угодно docker команды на хосте, в т.ч. пробрасывать хостовые папки и запускать privileged контейнеры

4. buildah/buildkit/img

   • Позволяют внутри докер контейнера запускать сборку образа без докер-демона
   • Требуется unprivileged_userns_clone (user namespaces), у которого свои security-риски
   • Синтаксис запуска отличается -> переучивать команду

5. kaniko

   • Позволяют внутри докер контейнера запускать сборку образа без докер-демона
   • Не поддерживается установка бинарника в свой образ. Необходимо использовать официальный образ
   • Синтаксис запуска отличается -> переучивать команду

Потенциальные векторы атаки

1. Источник

   • В сборке используется публичный образ, в котором в entrypoint выполняется команда проверки docker.sock и запуск контейнера через него
   • При сборке в зависимостях (напрмер, node) скачивается зловред, который запускается в процессе сборки. Далее проверка docker.sock и запуск контейнера через него

2. Цель

   • Закрепиться в системе. Через докер возможно установить свои бинарники и сервисы в систему
   • Дальнейший скан сети и поиск уязвимостей для распространения и закрепления