ci

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

  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. Цель

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