Как запретить Docker Daemon монтировать корневую файловую систему хоста в контейнер
У меня есть следующая установка контейнера.
На голом железе установлены и работают два демона Docker.
- Главный демон Docker Запускает контейнеры моего приложения, открывая доступ к 80/443 внешнему миру.
- Плагин Docker Daemon Запускает некоторые контейнеры, предоставленные заказчиком, которые связываются с моим приложением через 80/443.
Я хотел бы предоставить клиенту доступ к API (2376) Plugin Docker Daemon , чтобы клиент мог развертывать / запускать / останавливать свои собственные контейнеры. У клиента будет доступ только к API, а не к хосту (SSH).
Проблема, с которой я сейчас сталкиваюсь, заключается в том, что, если клиенты запускают контейнер, который делает что-то небезопасное, например docker run -v /: / host / root Ubuntu rm -rf / host / root .
У меня вопрос: что я могу сделать, чтобы запретить Plugin Docker Daemon монтировать корневой каталог / или любой другой каталог за пределами / home / user / ,
- Можно ли запустить демон Docker в
/ home / user /? - Могу ли я использовать магию LSM (Linux Security Modules SELinux / Apparmor), чтобы запретить демону Docker монтировать некоторые или все пути к хостам, кроме пользователей home или var / docker / libs?
- Может ли
- userns-remapпомочь мне в достижении моей цели? - Доступны ли какие-либо другие варианты, кроме виртуальных машин?
Сервер полностью принадлежит одному заказчику. Так что безопасность или утечка данных не являются моей главной заботой. Чего я действительно хочу предотвратить, так это того, что кто-то в Plugin Daemon делает что-то глупое, это влияет на мои контейнеры, которые работают в Main Docker Daemon . Я хотел бы придерживаться рабочего процесса только для докеров и не хочу настраивать дополнительный рабочий процесс для создания виртуальных машин.
SELinux в качестве доказательства предотвратит монтирование в качестве тома внутри контейнера докера чего-либо неправильно обозначенного, здесь, используя один файл, та же самая политика применяется к каталогам:
$ sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 30
Используя файл-пример:
$ cat sample_script.sh
echo 'Hello, world'
Его контекст безопасности по умолчанию:
$ ls -lrtZ sample_script.sh
-rw-------. 1 david david unconfined_u:object_r:user_home_t:s0 20 Oct 3 17:18 sample_script.sh
Попытка использовать этот файл внутри контейнера не удалась, как и ожидалось:
$ docker run -v /home/david/sample_script.sh:/sample_script.sh --rm ubuntu bash sample_script.sh
bash: sample_script.sh: Permission denied
А отказ AVC будет записан в журнал:
$ sudo ausearch -m avc -ts recent
time->Mon Oct 3 17:39:28 2016
type=AVC msg=audit(1475512768.444:784): avc: denied { read } for pid=28720 comm="bash" name="sample_script.sh" dev="dm-13" ino=101062112 scontext=system_u:system_r:svirt_lxc_net_t:s0:c457,c992 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=0
После изменения контекста безопасности на один Docker может использовать:
$ sudo chcon -Rt svirt_sandbox_file_t sample_script.sh
$ ls -lrtZ sample_script.sh
-rw-------. 1 david david unconfined_u:object_r:svirt_sandbox_file_t:s0 20 Oct 3 17:18 sample_script.sh
Контейнер теперь имеет доступ к файлу:
$ docker run -v /home/david/sample_script.sh:/sample_script.sh --rm ubuntu bash sample_script.sh
Hello, world
Дополнительная информация о Docker и SELinux в официальной документации Red Hat и этой статье Дэна Уолша.