Доступ к Unix-сокету Docker из контейнера Podman на удаленном сервере (SSH)

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

volumes:
  - /mnt/fuse_to_somewhere/var/run/docker.sock:/var/run/docker.sock:ro,z
security_opt:
  - label=disable
privileged: 
  - true

Commands: error querying for containers: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

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

Получение доступа к Unix-сокету Docker из контейнера Podman на удаленном сервере через SSH может оказаться сложной задачей из-за ряда специфических ограничений и требований конфигурации. Ваша цель заключается в том, чтобы контейнер Podman, работающий в вашей системе, мог взаимодействовать с демоном Docker, запущенным на удаленном сервере. Для этого необходимо обеспечить доступ к Unix-сокету Docker.

Теория

Unix-сокеты являются файловыми дескрипторами на уровне системы, которые позволяют межпроцессное взаимодействие без использования сетевых протоколов. В случае Docker, демон Docker предоставляет API через Unix-сокет, расположенный по умолчанию в /var/run/docker.sock. Доступ к этому сокету, как правило, разрешен только пользователю root и группе docker. Это делается по причине безопасности, поскольку потенциальная несанкционированная эксплуатация сокета может позволить использовать возможности Docker для выполнения произвольных команд на хосте.

Ваша задача усложняется тем, что вы подключаетесь к удаленному сокету Docker через SSHFS — это файловая система, основанная на протоколе SSH, которая монтирует удаленные каталоги через SSH. Однако SSHFS накладывает ограничения на передачу сокетов, так как такие коммуникации требуют специфической поддержки, которой в SSHFS может не быть.

Пример

Давайте рассмотрим, как это может быть организовано в идеальных условиях, чтобы понять, какие компоненты необходимо учесть:

1. Конфигурация привилегий и SELinux: Демон Docker должен быть настроен таким образом, чтобы монтируемый сокет был доступен для чтения и записи пользователем, под которым запущен контейнер Podman. Это требует соответствующей настройки SELinux и проверок прав доступа.

2. Конфигурация Podman: Контейнер Podman должен запускаться с параметрами --privileged=true и --security-opt=label=disable, что уже частично учтено в вашем случае. Эти параметры позволяют контейнеру обращаться к компонентам хоста, которые обычно недоступны.

3. Использование sshfs: При монтировании сокета через SSHFS необходимо убедиться, что передаются правильные атрибуты и права доступа. Однако, как уже отмечалось, SSHFS не поддерживает передачу Unix-сокетов, то есть использовать данный метод для доступа к Docker-сокету будет проблематично.

Применение

Теперь о том, как решить вашу проблему:

1. Убедитесь, что демоны работают: Убедитесь, что Docker-демон на удаленном сервере запущен и что к нему можно подключиться с хоста, на котором работает Podman. Для этого можно использовать команды вроде docker ps с удаленного сервера.

2. Использование SSH Tunneling: Используйте SSH-туннелирование для перенаправления соединения, а не SSHFS. Пример команды для создания туннеля:

   ssh -L 2375:/var/run/docker.sock user@remote-server -N

   После чего в контейнере Podman можно будет использовать -e DOCKER_HOST=tcp://localhost:2375.

3. Конфигурация безопасности: Удостоверьтесь, что ваш Docker-сокет защищен паролем или другими методами аутентификации, поскольку такая конфигурация делает его уязвимым для атак, если ваш SSH-сервер будет скомпрометирован.

4. SELinux и AppArmor: Проверьте и временно отключите любые политики SELinux или AppArmor, если они препятствуют работе. Вы также можете настроить их, чтобы они разрешали доступ.

5. Альтернативы и рекомендации: Как альтернативу вы можете рассмотреть использование более прямого метода, такого как Docker-клиенты с параметром context, который позволяет переключаться между конфигурациями Docker на различных хостах, если это возможно в вашем случае.

Помните, что предоставление доступа Docker-сокету — это вопрос безопасности, и необходимо строго контролировать и ограничивать доступ, чтобы минимизировать риск несанкционированного использования.