Докер в Докере без привилегированного режима

Вопрос или проблема

В последний раз я использовал Docker в Docker для runners, но это требует привилегированного режима

Файл compose:

version: '3.7'
services:
  runner:
    image: gitlab/gitlab-runner:latest
    volumes:
      - ./config:/etc/gitlab-runner
      - ./run:/var/run/
#      - /var/run/docker.sock:/var/run/docker.sock

  docker:
    image: docker:dind
    restart: always
    privileged: true # <-- проблемы с безопасностью
    volumes:
      - ./run:/var/run/

У меня есть персональный компьютер. У меня есть команда Gitlab, которая нуждается в запуске docker build или docker-compose up скриптов с помощью Gitlab CI. Я действительно хочу ускорить CI. Поэтому я делюсь своим хостовым Docker с runners, теперь у них есть кеш Docker (образы и так далее), и когда один этап строит образ, а другой его требует, это действительно быстро.

У меня такая же проблема с Jenkins. Мне нужно поделиться хостовым Docker с рабочими узлами.

В последний раз я хотел протестировать новый подход и запустить runners с их собственным Docker. У меня почти нет 2 важных вещей:
– ограничение ресурсов (я хочу предоставить 7 из 8 ядер CPU, 10 из 16 ГБ памяти, некоторые ограничения на HDD)
– безопасность

Важно добавить: у меня нет CI-скриптов, которые требуют GPU, сетевых возможностей, монтирования некоторых устройств и так далее. Обычно они выполняют простые docker build и docker push, иногда мне нужно забрать артефакты с помощью docker cp, и это всё.
Основной вопрос: как запустить Docker в Docker без прав root на хост-машине?

Оба – совместное использование сокетов или привилегированный режим создают уязвимости для хост-машин, а наличие виртуальной машины (например, VirtualBox или что-то подобное) медленно и трудно осуществить, также я хочу делиться ресурсами и хочу, чтобы Docker мог использовать 10 из 16 ГБ, но 10 ГБ должны быть свободны, когда они не используются.

У меня есть некоторые неопределенные ошибки от контейнера dind (перед отказом), когда я запускаю его с обычными привилегиями:

gitlab-runner-docker | mount: permission denied (are you root?)
gitlab-runner-docker | mount: permission denied (are you root?)
gitlab-runner-docker | Could not mount /sys/kernel/security.
gitlab-runner-docker | AppArmor detection and --privileged mode might break.

С какими проблемами я столкнусь, если попытаюсь запустить Docker в Docker без привилегированного режима? Как это сделать?

Что касается балансировки нагрузки оперативной памяти, я не могу помочь, но вы можете запустить Docker в Docker (dind) без прав sudo, добавив вашего текущего пользователя в группу docker,

Я не вижу безопасности совместно используемых сокетов, потому что это теряет свою целостность, но я бы рекомендовал инстанцировать dind с параметром компоновщика с привилегированным параметром: true

Ответ или решение

Запуск Docker внутри Docker (DinD) без использования привилегированного режима представляет собой серьезную задачу, особенно если вы хотите обеспечить безопасность и управляемость ресурсов. Привилегированный режим предоставляет контейнеру неограниченный доступ к ресурсам хоста, что может создать уязвимости. Давайте рассмотрим, как можно организовать подобное окружение без использования этого режима, и какие проблемы могут возникнуть.

1. Установка Docker и настройка GitLab Runner

Для начала, вам нужно установить Docker на вашем хосте и убедиться, что ваш пользователь добавлен в группу docker. Это позволит вашему пользователю выполнять команды Docker без использования sudo.

sudo usermod -aG docker $USER

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

2. Использование Docker Socket

Наиболее рекомендуемым подходом к запуску DinD без привилегий является использование монтированного сокета Docker. Это позволит вашему GitLab Runner запускать Docker-контейнеры, используя Docker хоста.

Вместо использования отдельного сервиса docker, вы можете модифицировать ваш docker-compose.yml, чтобы монтировать сокет Docker напрямую в контейнер GitLab Runner. Вот как это можно сделать:

version: '3.7'
services:
  runner:
    image: gitlab/gitlab-runner:latest
    volumes:
      - ./config:/etc/gitlab-runner
      - /var/run/docker.sock:/var/run/docker.sock  # Монтируем сокет хоста

3. Ограничение ресурсов

Чтобы контролировать использование ресурсов (ЦП и ОЗУ) контейнерами GitLab Runner, вы можете настроить ограничения в соответствующих конфигурациях. Однако ограничения ресурсов следует устанавливать в GitLab CI/CD pipeline.

Пример .gitlab-ci.yml конфигурации с ограничениями ресурсов:

job:
  script:
    - echo "Running a Docker job"
  tags:
    - docker
  resource_group: my-resource-group
  limits:
    memory: 10Gi
    cpu: "7"

4. Решение проблем с безопасностью

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

  1. Аудит безопасности: Регулярно проверяйте и аудируйте доступ к вашим контейнерам и конфигурациям.
  2. Изоляция окружений: Используйте различные ресурсы (например, разные сетевые пространства, имена хостов), чтобы изолировать задачи, которые могут потенциально конфликтовать.

5. Проблемы, с которыми можно столкнуться

При запуске Docker в Docker без привилегий могут возникнуть следующие проблемы:

  • Недостаток привилегий: Некоторые функциональные возможности, такие как монтирование определенных файловых систем или использование сетевых пространств, могут быть недоступны. Это может привести к ошибкам, таким как "permission denied".
  • Ограниченные возможности: Возможно, вам придется адаптировать ваши CI/CD скрипты, чтобы они работали в более ограниченной среде.
  • Проблемы с совместимостью: Обновления либо изменения конфигураций в вашем контейнере GitLab Runner могут привести к несовместимостям с используемым образом Docker.

Заключение

Для реализации Docker в Docker без привилегий рекомендуется монтировать сокет Docker с хоста и установить подходящие ограничения ресурсов через конфигурацию GitLab CI. Хотя это может потенциально ослабить уровни безопасности, правильная настройка и мониторинг могут помочь минимизировать риски. Важно оставаться внимательными к безопасному управлению и настройке вашего CI/CD процесса.

Оцените материал
Добавить комментарий

Капча загружается...