# Comprender los requisitos de permisos para Docker Desktop en Mac


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)](#installing-symlinks) en `/usr/local/bin`.
- [Vinculación de puertos privilegiados](#binding-privileged-ports) 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](#ensuring-localhost-and-kubernetesdockerinternal-are-defined) 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**.

### Instalación de enlaces simbólicos (symlinks)

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`](/desktop/settings-and-maintenance/settings/#advanced) 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](/desktop/setup/install/mac-install/#install-from-the-command-line). 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`.

```console
$ 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](/enterprise/security/hardened-desktop/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.