Привилегированные контейнеры и возможности



Если я запускаю контейнер в привилегированном режиме, имеет ли он все возможности ядра или мне нужно добавить их отдельно?

700   3  

3 ответов:

Запуск в привилегированном режиме действительно дает контейнеру все возможности. Но это хорошая практика всегда давать контейнеру минимальные требования, которые ему нужны Если вы посмотрите на документы Docker, они также ссылаются на этот флаг

Полные возможности контейнера (--privileged)

Флаг --privileged предоставляет контейнеру все возможности, а также снимает все ограничения, наложенные контроллером группы устройств. Другими словами, контейнер может после этого сделать почти все, что может сделать хозяин. Этот флаг существует, чтобы разрешить специальные варианты использования, такие как запуск Docker внутри Docker.

Вы можете предоставить определенные возможности, используя флаг --cap-add. Видишь man 7 capabilities Для получения дополнительной информации об этих возможностях. Можно использовать литеральные имена, например --cap-add CAP_FOWNER.

Поскольку этот пост занимает высокое место в поисковой строке google, я хотел бы добавить информацию о том, почему вы никогда не хотите запускать контейнер с помощью --privileged

Я делаю это на моем ноутбуке, который имеет диски NVMe, но он будет работать для любого хоста.

docker run --privileged -t -i --rm ubuntu:latest bash

Сначала давайте сделаем что-нибудь незначительное, чтобы протестировать файловую систему /proc

Из контейнера:

root@507aeb767c7e:/# cat /proc/sys/vm/swappiness
60
root@507aeb767c7e:/# echo "61" > /proc/sys/vm/swappiness    
root@507aeb767c7e:/# cat /proc/sys/vm/swappiness
60

Хорошо, он изменил его для контейнера или для хоста?

$ cat /proc/sys/vm/swappiness
61

Ой!, мы можем произвольно изменять параметры ядра хостов. Но это просто ситуация DOS, давайте посмотрим, можем ли мы собирать привилегированную информацию от родительского хоста.

Давайте пройдемся по дереву /sys и найдем главное минорное число для загрузочного диска.

Примечание: у меня есть два диска NVMe, и контейнеры работают под управлением LVM на другом диске

root@507aeb767c7e:/proc# cat /sys/block/nvme1n1/dev
259:2

OK позволяет создать файл устройства в месте, где правила dbus не будут автоматически сканироваться.

root@507aeb767c7e:/proc# mknod /devnvme1n1 b 259 2
root@507aeb767c7e:/proc# sfdisk -d /devnvme1n1 
label: gpt
label-id: 1BE1DF1D-3523-4F22-B22A-29FEF19F019E
device: /devnvme1n1
unit: sectors
first-lba: 34
last-lba: 2000409230
<SNIP>

Хорошо, мы можем прочитать загрузочный диск, давайте сделаем Файл Устройства для одного из перекрытия. Хотя мы не можем установить его, так как он будет открыт, мы все еще можем использовать dd, чтобы скопировать его.

root@507aeb767c7e:/proc# mknod /devnvme1n1p1 b 259 3
root@507aeb767c7e:/# dd if=devnvme1n1p1 of=foo.img
532480+0 records in
532480+0 records out
272629760 bytes (273 MB, 260 MiB) copied, 0.74277 s, 367 MB/s
Хорошо, давайте смонтируем его и посмотрим, сработали ли наши усилия!!!
root@507aeb767c7e:/# mount -o loop foo.img /foo
root@507aeb767c7e:/# ls foo
EFI
root@507aeb767c7e:/# ls foo/EFI/
Boot  Microsoft  ubuntu
Таким образом, в основном любой хост-контейнер, на котором вы разрешаете кому-либо запускать контейнер --privileged, является тем же, что и предоставление им корневого доступа к каждому контейнеру на этом хосте.

К сожалению, проект docker выбрал доверенную вычислительную модель, и за пределами плагинов auth нет способа защитить от этого, так что всегда ошибка на стороне добавления необходимых функций по сравнению с использованием --privileged

Есть хорошая статья, покрывающая из RedHat, покрывающая это

Хотя контейнер docker, работающий как "root", имеет меньше прав, чем root на хосте, он все же может нуждаться в усилении в зависимости от вашего варианта использования (использование в качестве среды разработки против общего производственного кластера)

Comments

    Ничего не найдено.