run - docker tag image
Contenedores y capacidades privilegiadas (3)
Si estoy ejecutando un contenedor en modo privilegiado, ¿tiene todas las capacidades de Kernel o debo agregarlas por separado?
Hay un buen artículo que cubre de RedHat que cubre este
Mientras que el contenedor acoplable que se ejecuta como "raíz" tiene menos privilegios que la raíz en el host, aún puede ser necesario reforzarlo en función de su caso de uso (utilizando como entorno de desarrollo frente a clúster de producción compartido).
Correr en modo privilegiado le da al contenedor todas las capacidades. Pero es una buena práctica darle siempre a un contenedor los requisitos mínimos que necesita. Si observa los documentos Docker, también se refieren a esta bandera.
Capacidades completas del contenedor (--privilegiado)
El distintivo privilegiado otorga todas las capacidades al contenedor y también elimina todas las limitaciones impuestas por el controlador cgroup del dispositivo. En otras palabras, el contenedor puede hacer casi todo lo que el host puede hacer. Esta marca existe para permitir casos de uso especiales, como ejecutar Docker dentro de Docker.
Puede otorgar capacidades específicas utilizando el --cap-add . Vea las man 7 capabilities para obtener más información sobre esas capacidades. Los nombres literales se pueden usar, por ejemplo, --cap-add CAP_FOWNER .
Como esta publicación ocupa un lugar --privileged ranking de búsqueda de Google, quería agregar información sobre por qué no desea ejecutar un contenedor utilizando --privileged
Estoy haciendo esto en mi computadora portátil que tiene unidades NVMe, pero funcionará para cualquier host.
docker run --privileged -t -i --rm ubuntu:latest bash
Primero hagamos algo menor, para probar el sistema de archivos / proc
Del contenedor:
root@507aeb767c7e:/# cat /proc/sys/vm/swappiness
60
root@507aeb767c7e:/# echo "61" > /proc/sys/vm/swappiness
root@507aeb767c7e:/# cat /proc/sys/vm/swappiness
60
OK ¿lo cambió para el contenedor o para el host?
$ cat /proc/sys/vm/swappiness
61
OOPS !, podemos cambiar arbitrariamente los parámetros del kernel de los hosts. Pero esto es solo una situación de DOS, veamos si podemos recopilar información privilegiada del host principal.
Caminemos por el árbol /sys y busquemos el número menor principal para el disco de arranque.
Nota: Tengo dos unidades NVMe y los contenedores se están ejecutando bajo LVM en otra unidad
root@507aeb767c7e:/proc# cat /sys/block/nvme1n1/dev
259:2
OK, hagamos un archivo de dispositivo en una ubicación donde las reglas de dbus no se escanearán automáticamente.
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>
OK, podemos leer el disco de arranque, hagamos un archivo de dispositivo para una de las particiones. Si bien no podemos montarlo ya que estará abierto, aún podemos usar dd para copiarlo.
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
¡OK, vamos a montarlo y ver si nuestros esfuerzos funcionaron!
root@507aeb767c7e:/# mount -o loop foo.img /foo
root@507aeb767c7e:/# ls foo
EFI
root@507aeb767c7e:/# ls foo/EFI/
Boot Microsoft ubuntu
Así que, básicamente, cualquier host de contenedor en el que permita que alguien lance un contenedor --privileged es el mismo que le da acceso de root a cada contenedor en ese host.
Lamentablemente, el proyecto docker ha elegido el modelo informático de confianza, y fuera de los complementos de autenticación no hay forma de protegerse de esto, por lo que siempre hay un error al agregar las características necesarias vs. usar --privileged