Compartir comentarios
Las respuestas se generan en base a la documentación.

Comprender los requisitos de permisos para Docker Desktop en Mac

Tabla de contenidos

Esta página contiene información sobre los requisitos de permisos para ejecutar e instalar Docker Desktop en Mac.

También ofrece aclaraciones sobre la ejecución de contenedores como root en contraste con tener acceso de root en el host.

Docker Desktop en Mac está diseñado pensando en la seguridad. Los derechos de administrador solo se requieren cuando es absolutamente necesario.

Requisitos de permisos

Docker Desktop para Mac se ejecuta como un usuario sin privilegios. Sin embargo, Docker Desktop requiere ciertas funcionalidades para realizar un conjunto limitado de configuraciones privilegiadas, tales como:

  • Instalación de enlaces simbólicos (symlinks) en /usr/local/bin.
  • Vinculación de puertos privilegiados inferiores al 1024. Aunque los puertos privilegiados (puertos inferiores a 1024) no se suelen utilizar como límite de seguridad, los sistemas operativos siguen impidiendo que los procesos sin privilegios se vinculen a ellos, lo que interrumpe comandos como docker run -p 127.0.0.1:80:80 docker/getting-started.
  • Asegurar que localhost y kubernetes.docker.internal estén definidos en /etc/hosts. Algunas instalaciones antiguas de macOS no tienen localhost en /etc/hosts, lo que hace que Docker falle. Definir el nombre de DNS kubernetes.docker.internal permite a Docker compartir contextos de Kubernetes con contenedores.
  • Almacenar en caché de forma segura la política de Registry Access Management, que es de solo lectura para el desarrollador.

El acceso privilegiado se concede durante la instalación.

La primera vez que se inicia Docker Desktop para Mac, presenta una ventana de instalación donde puedes elegir usar la configuración predeterminada, que funciona para la mayoría de los desarrolladores y requiere que concedas acceso privilegiado, o usar la configuración avanzada.

Si trabajas en un entorno con requisitos de seguridad elevados, por ejemplo, donde se prohíbe el acceso administrativo local, puedes utilizar la configuración avanzada para eliminar la necesidad de conceder acceso privilegiado. Puedes configurar:

  • La ubicación de las herramientas de la CLI de Docker, ya sea en el directorio del sistema o del usuario.
  • El socket de Docker predeterminado.
  • El mapeo de puertos privilegiados.

Dependiendo de qué ajustes avanzados configures, deberás introducir tu contraseña para confirmar.

Puedes cambiar estas configuraciones más adelante desde la página Advanced en Settings.

Los binarios de Docker se instalan de forma predeterminada en /Applications/Docker.app/Contents/Resources/bin. Docker Desktop crea enlaces simbólicos para los binarios en /usr/local/bin, lo que significa que se incluyen automáticamente en el PATH en la mayoría de los sistemas.

Puedes elegir si deseas instalar los enlaces simbólicos en /usr/local/bin o en $HOME/.docker/bin durante la instalación de Docker Desktop.

Si se elige /usr/local/bin y esta ubicación no permite la escritura por parte de usuarios sin privilegios, Docker Desktop requiere autorización para confirmar esta elección antes de que se creen los enlaces simbólicos a los binarios de Docker en /usr/local/bin. Si se elige $HOME/.docker/bin, no se requiere autorización, pero entonces debes añadir manualmente $HOME/.docker/bin a tu PATH.

También se te da la opción de habilitar la instalación del enlace simbólico /var/run/docker.sock. La creación de este enlace simbólico garantiza que varios clientes de Docker que dependen de la ruta predeterminada del socket de Docker funcionen sin cambios adicionales.

Debido a que /var/run está montado como un tmpfs, su contenido se elimina al reiniciar, incluido el enlace simbólico al socket de Docker. Para garantizar que el socket de Docker exista después del reinicio, Docker Desktop configura una tarea de inicio de launchd que crea el enlace simbólico ejecutando ln -s -f /Users/<usuario>/.docker/run/docker.sock /var/run/docker.sock. Esto asegura que no se te solicite en cada inicio crear el enlace simbólico. Si no habilitas esta opción durante la instalación, el enlace simbólico y la tarea de inicio no se crearán y es posible que tengas que definir explícitamente la variable de entorno DOCKER_HOST como /Users/<usuario>/.docker/run/docker.sock en los clientes que utilices. La CLI de Docker depende del contexto actual para obtener la ruta del socket; el contexto actual se establece en desktop-linux al iniciar Docker Desktop.

Vinculación de puertos privilegiados

Puedes elegir habilitar el mapeo de puertos privilegiados durante la instalación, o desde la página Advanced en Settings después de la instalación. Docker Desktop requiere autorización para confirmar esta elección.

Asegurar que localhost y kubernetes.docker.internal estén definidos

Es tu responsabilidad asegurarte de que localhost se resuelva como 127.0.0.1 y, si se utiliza Kubernetes, que kubernetes.docker.internal se resuelva como 127.0.0.1.

Instalación desde la línea de comandos

Las configuraciones privilegiadas se aplican durante la instalación con la opción --user en el comando de instalación. En este caso, no se te pedirá que concedas privilegios de root en la primera ejecución de Docker Desktop. Específicamente, la opción --user:

  • Desinstala el com.docker.vmnetd anterior si está presente.
  • Configura los enlaces simbólicos.
  • Asegura que localhost se resuelva como 127.0.0.1.

La limitación de este enfoque es que Docker Desktop solo puede ser ejecutado por una cuenta de usuario por máquina, concretamente la especificada en la opción --user.

Asistente privilegiado (Privileged helper)

En las situaciones limitadas en las que se necesita el asistente privilegiado, por ejemplo para vincular puertos privilegiados o almacenar en caché la política de Registry Access Management, el asistente privilegiado es iniciado por launchd y se ejecuta en segundo plano a menos que se deshabilite en tiempo de ejecución como se describió anteriormente. El backend de Docker Desktop se comunica con el asistente privilegiado a través del socket de dominio UNIX /var/run/com.docker.vmnetd.sock. Las funciones que realiza son:

  • Vincular puertos privilegiados inferiores a 1024.
  • Almacenar en caché de forma segura la política de Registry Access Management, que es de solo lectura para el desarrollador.
  • Desinstalar el asistente privilegiado.

La eliminación del proceso del asistente privilegiado se realiza de la misma manera que la eliminación de procesos de launchd.

$ ps aux | grep vmnetd
root             28739   0.0  0.0 34859128    228   ??  Ss    6:03PM   0:00.06 /Library/PrivilegedHelperTools/com.docker.vmnetd
user             32222   0.0  0.0 34122828    808 s000  R+   12:55PM   0:00.00 grep vmnetd

$ sudo launchctl unload -w /Library/LaunchDaemons/com.docker.vmnetd.plist
Password:

$ ps aux | grep vmnetd
user             32242   0.0  0.0 34122828    716 s000  R+   12:55PM   0:00.00 grep vmnetd

$ rm /Library/LaunchDaemons/com.docker.vmnetd.plist

$ rm /Library/PrivilegedHelperTools/com.docker.vmnetd

Contenedores ejecutándose como root dentro de la VM de Linux

Con Docker Desktop, el demonio de Docker y los contenedores se ejecutan en una VM ligera de Linux gestionada por Docker. Esto significa que, aunque los contenedores se ejecutan por defecto como root, esto no concede acceso de root a la máquina host Mac. La VM de Linux sirve como límite de seguridad y limita a qué recursos se puede acceder desde el host. Todos los directorios del host montados mediante bind en los contenedores de Docker conservan sus permisos originales.

Enhanced Container Isolation

Además, Docker Desktop es compatible con el modo Enhanced Container Isolation (ECI), disponible únicamente para clientes de Business, el cual protege aún más los contenedores sin afectar los flujos de trabajo de los desarrolladores.

ECI ejecuta automáticamente todos los contenedores dentro de un espacio de nombres de usuario (user-namespace) de Linux, de modo que el root en el contenedor se mapea a un usuario sin privilegios dentro de la VM de Docker Desktop. ECI utiliza esta y otras técnicas avanzadas para proteger aún más los contenedores dentro de la VM de Linux de Docker Desktop, de manera que estén más aislados del demonio de Docker y de otros servicios que se ejecutan dentro de la VM.