Cómo preparar Docker para una pequeña empresa con varios usuarios

Introducción

Preparar Docker para una pequeña empresa con varios usuarios significa decidir con claridad quién puede utilizar las aplicaciones, quién puede administrar los proyectos y quién puede controlar realmente el motor Docker y el servidor. Estas tres capacidades no son equivalentes. Una persona que usa una aplicación web desplegada en un contenedor no necesita acceso al host; quien modifica un archivo Compose puede necesitar acceso al proyecto; y quien controla el daemon de Docker dispone de un nivel de privilegio muy elevado sobre la máquina.

El problema aparece cuando una plataforma que inicialmente administraba una sola persona empieza a compartirse. Se crea una cuenta común para “Docker”, varias personas utilizan las mismas credenciales, los proyectos quedan dentro del directorio personal de un administrador, cualquiera que necesita ejecutar docker ps termina añadido al grupo docker y los cambios dejan de tener un autor claro. La plataforma puede seguir funcionando, pero pierde trazabilidad y aumenta el riesgo de errores.

Una empresa pequeña no necesita implantar una infraestructura corporativa de identidad para resolver este problema. Puede aplicar unas pocas reglas consistentes: cuentas nominales, privilegios administrativos limitados, proyectos situados fuera de directorios personales, permisos previsibles, accesos revocables, procedimientos comunes y una fuente de verdad que no dependa de la cuenta de una persona concreta.

Este artículo explica cómo organizar la administración compartida de Docker desde una perspectiva práctica. El objetivo es permitir que varias personas puedan trabajar con la plataforma sin convertir el acceso a Docker en un permiso general e indiscriminado sobre el servidor.

La arquitectura general se desarrolla en cómo diseñar una plataforma Docker para una pequeña empresa. Aquí el foco es específico: cómo organizar personas, cuentas, permisos y responsabilidades alrededor de una plataforma Docker compartida.

Índice

• Distinguir tres tipos de usuario
• Aplicar mínimo privilegio desde el principio
• Utilizar cuentas nominales en el servidor
• Evitar cuentas administrativas compartidas
• Entender qué implica pertenecer al grupo docker
• Separar acceso Linux y administración Docker
• Organizar el acceso remoto por SSH
• Mantener proyectos fuera de directorios personales
• Diseñar permisos previsibles sobre los proyectos
• Controlar quién puede modificar Docker Compose
• Evitar que compartir administración implique compartir todos los secretos
• Tratar el socket Docker como un recurso privilegiado
• No usar un panel web como única capa de control
• Definir responsabilidades operativas
• Registrar cambios y mantener trazabilidad
• Organizar actualizaciones cuando hay varios administradores
• Separar producción y pruebas
• Usar un inventario común
• Documentar para que la plataforma no dependa de una persona
• Procedimiento para incorporar un nuevo administrador
• Procedimiento para retirar accesos
• Preparar acceso de emergencia
• Errores frecuentes
• Modelo sencillo para una pequeña empresa
• Procedimiento paso a paso
• Lista de comprobación
• Preguntas frecuentes
• Conclusión

Distinguir tres tipos de usuario

El primer paso consiste en no utilizar la palabra “usuario” para situaciones completamente diferentes.

Usuario de una aplicación

Utiliza un servicio desplegado con Docker mediante una interfaz web, una API u otro mecanismo propio de la aplicación. Normalmente no necesita cuenta en el servidor ni acceso a Docker.

Operador o mantenedor de un proyecto

Puede necesitar consultar documentación, revisar configuración, comprobar logs o participar en un procedimiento de despliegue. Sus permisos deberían limitarse a lo que necesita para esa responsabilidad.

Administrador de Docker y del host

Puede crear, detener, recrear y modificar contenedores, redes y volúmenes. Dependiendo del mecanismo de acceso, esta capacidad puede proporcionar un control muy elevado sobre el servidor.

Separar estas funciones evita conceder privilegios administrativos a una persona simplemente porque necesita utilizar o revisar una aplicación.

Aplicar mínimo privilegio desde el principio

El criterio general debería ser que cada persona reciba únicamente el acceso necesario para realizar su trabajo.

Esto significa evitar decisiones como:

• dar acceso al grupo docker a todo usuario técnico;
• compartir una cuenta de administrador;
• entregar todas las credenciales de todos los proyectos;
• permitir edición indiscriminada de cualquier archivo Compose;
• dar acceso al host a quienes solo utilizan aplicaciones.

El mínimo privilegio no busca dificultar el trabajo. Busca hacer visible qué capacidad necesita cada función y limitar el impacto de un error o una cuenta comprometida.

Utilizar cuentas nominales en el servidor

Cuando varias personas administran un servidor, las cuentas nominales ayudan a conservar trazabilidad. Cada administrador debería acceder con su propia identidad siempre que resulte práctico.

Esto permite:

• revocar a una persona sin cambiar la cuenta de todos;
• identificar sesiones y acciones;
• mantener claves SSH separadas;
• aplicar permisos diferentes;
• evitar compartir contraseñas administrativas.

La identidad debe sobrevivir al cambio de personas

Los proyectos no deberían depender del directorio personal de quien los desplegó. La persona administra la plataforma; no debe convertirse en parte estructural de ella.

Evitar cuentas administrativas compartidas

Una cuenta como dockeradmin utilizada por varias personas parece sencilla, pero elimina buena parte de la trazabilidad.

Con una cuenta compartida resulta más difícil responder:

• quién cambió una configuración;
• quién añadió una clave;
• quién ejecutó un despliegue;
• qué acceso debe revocarse cuando alguien deja de administrar.

Las cuentas de servicio son otra cosa

Puede existir una identidad técnica utilizada por un proceso automatizado. Eso no significa que varias personas deban iniciar sesión interactivamente con esa cuenta.

Entender qué implica pertenecer al grupo docker

Una de las decisiones más importantes en una plataforma multiusuario consiste en controlar quién puede comunicarse con el daemon de Docker.

En muchos sistemas, añadir una cuenta al grupo docker permite ejecutar comandos Docker sin anteponer sudo. Esa comodidad no debe confundirse con un permiso menor.

El acceso administrativo a Docker implica un nivel muy elevado de control sobre el host. Un usuario capaz de crear contenedores y realizar montajes sensibles puede acceder a recursos del servidor que normalmente estarían protegidos.

El grupo docker debe ser pequeño

Conviene que sus miembros sean:

• pocos;
• identificados;
• necesarios;
• revisados periódicamente.

La plataforma general ya debe considerar el acceso al daemon como una responsabilidad administrativa, no como una comodidad para cualquier usuario técnico.

Separar acceso Linux y administración Docker

Tener una cuenta Linux no significa necesitar control de Docker. Del mismo modo, una persona que administra determinados servicios no necesita necesariamente privilegios generales sobre todo el servidor.

Conviene distinguir:

• acceso al host;
• capacidad de elevar privilegios;
• capacidad de controlar Docker;
• permisos sobre archivos de proyectos;
• acceso a secretos.

Estas capacidades deben asignarse deliberadamente y no aparecer juntas por accidente.

Evitar privilegios “por si acaso”

Un permiso administrativo añadido para resolver una incidencia puntual debería revisarse después. Los accesos temporales tienen tendencia a convertirse en permanentes si no existe un procedimiento de retirada.

Organizar el acceso remoto por SSH

Si la administración se realiza por SSH, cada persona autorizada debería poder identificarse de forma independiente.

Una gestión ordenada implica:

• cuentas separadas;
• claves individuales;
• retirada de claves antiguas;
• documentación de quién mantiene acceso;
• evitar reutilizar una misma clave privada entre varias personas.

La baja debe ser sencilla

Si eliminar el acceso de una persona obliga a cambiar las credenciales utilizadas por todos, el diseño de acceso es demasiado compartido.

Mantener proyectos fuera de directorios personales

Una plataforma administrada por varias personas no debería depender de rutas como:

/home/ana/docker/app
/home/carlos/proyecto
/root/compose/servicio

Una ubicación común facilita continuidad:

/srv/docker/
├── proxy/
├── aplicacion-a/
├── aplicacion-b/
└── monitorizacion/

La elección exacta de la ruta puede variar. Lo importante es que la estructura pertenezca al sistema y no al ciclo de vida de una cuenta personal.

La organización física de los proyectos se desarrolla en cómo organizar correctamente los proyectos Docker.

Diseñar permisos previsibles sobre los proyectos

Los directorios de proyectos necesitan propietarios y permisos coherentes. Si cada persona corrige permisos manualmente cuando aparece un error, el sistema terminará acumulando excepciones.

Conviene decidir:

• quién puede leer configuración;
• quién puede modificar archivos Compose;
• quién puede ejecutar scripts;
• qué archivos contienen información sensible;
• qué datos no deben ser editados directamente.

No utilizar permisos excesivos como solución rápida

Dar escritura global a un directorio puede ocultar un problema de propiedad, pero introduce otro mayor. La configuración de permisos debe expresar quién administra realmente el recurso.

Controlar quién puede modificar Docker Compose

Un archivo Compose puede cambiar imágenes, redes, montajes, puertos, variables y privilegios. Modificarlo es una acción administrativa importante.

Por ello conviene diferenciar:

• quién puede consultar la definición;
• quién puede proponer cambios;
• quién puede aplicarlos en producción;
• cómo queda registrada la versión desplegada.

Evitar ediciones anónimas sobre producción

La definición activa debería estar controlada y ser recuperable. Varias copias editables en distintos directorios hacen difícil saber qué versión es la real.

Evitar que compartir administración implique compartir todos los secretos

Una persona puede necesitar mantener un proyecto sin tener acceso a todas las credenciales de la plataforma.

Conviene separar:

• credenciales de bases de datos;
• tokens de APIs;
• claves privadas;
• credenciales de registros;
• cuentas administrativas de aplicaciones.

Documentar la referencia, no el valor

La documentación puede indicar qué secreto necesita un servicio, dónde se custodia y cómo se rota sin reproducir el valor sensible.

Revisar al retirar un usuario

Si una persona ha tenido acceso directo a una credencial compartida, su baja puede requerir rotarla. Por eso conviene reducir el número de secretos compartidos desde el principio.

Tratar el socket Docker como un recurso privilegiado

El socket de Docker permite comunicarse con el daemon. Montarlo dentro de un contenedor o conceder acceso a una herramienta administrativa puede proporcionar una capacidad muy elevada sobre el host.

Antes de exponerlo a un contenedor conviene preguntar:

• ¿la aplicación realmente necesita controlar Docker?
• ¿puede cumplir su función sin acceso al socket?
• ¿quién puede utilizar esa aplicación?
• ¿qué ocurriría si esa aplicación se compromete?

Un panel cómodo no justifica por sí solo conceder control general del motor.

No usar un panel web como única capa de control

Una interfaz gráfica puede facilitar la operación a varias personas, pero no debería convertirse en la única fuente de verdad.

Si el panel deja de funcionar, debe seguir siendo posible conocer:

• proyectos;
• contenedores;
• imágenes;
• redes;
• volúmenes;
• configuración desplegada.

Las herramientas estándar y la documentación deben permitir reconstruir la plataforma sin depender de una interfaz concreta.

Definir responsabilidades operativas

Con varias personas administrando, conviene asignar responsabilidades explícitas.

Una tabla sencilla puede distinguir:

En una empresa pequeña una misma persona puede asumir varias funciones. La utilidad está en definirlas, no en crear puestos artificiales.

Registrar cambios y mantener trazabilidad

Cuando varias personas pueden modificar una plataforma, los cambios deben dejar contexto.

Conviene registrar al menos:

• qué cambió;
• cuándo;
• por qué;
• qué proyecto se vio afectado;
• cómo volver atrás cuando proceda.

El servidor no debería depender de conversaciones informales para explicar su estado actual.

La trazabilidad del host puede ampliarse en cómo registrar cambios realizados en un servidor Linux.

Organizar actualizaciones cuando hay varios administradores

Una actualización necesita coordinación mínima para evitar que dos personas modifiquen simultáneamente el mismo servicio.

Un procedimiento sencillo puede incluir:

1. identificar la versión actual;
2. registrar quién realiza el cambio;
3. comprobar backup cuando sea necesario;
4. aplicar la nueva versión;
5. validar el servicio;
6. actualizar inventario y documentación.

La mecánica específica se desarrolla en cómo actualizar servicios Docker minimizando interrupciones.

Separar producción y pruebas

Una plataforma multiusuario aumenta el riesgo de que una prueba termine afectando a producción si ambos entornos comparten recursos sin una frontera clara.

Conviene separar como mínimo:

• datos;
• credenciales;
• puertos;
• proyectos;
• redes cuando sea necesario;
• procedimientos de despliegue.

No probar con privilegios de producción por comodidad

La persona que experimenta con una imagen o configuración nueva no debería necesitar acceso a todos los datos reales para comprobar si el contenedor funciona.

Usar un inventario común

Cuando varias personas administran Docker, todas deberían partir del mismo mapa operativo.

El inventario debe identificar:

• proyecto;
• servicio;
• imagen;
• estado;
• redes;
• volúmenes;
• criticidad;
• dependencias;
• responsable.

El método completo se desarrolla en cómo inventariar todos los contenedores de una empresa.

Documentar para que la plataforma no dependa de una persona

Una plataforma compartida es más madura cuando otra persona autorizada puede comprenderla y recuperarla sin reconstruir decisiones a partir de la memoria del administrador anterior.

La documentación debería permitir saber:

• dónde están los proyectos;
• cómo se despliegan;
• qué datos conservan;
• qué redes utilizan;
• qué secretos necesitan;
• cómo se actualizan;
• cómo se recuperan.

Este enfoque se desarrolla en cómo documentar una infraestructura basada en Docker.

Procedimiento para incorporar un nuevo administrador

El alta de una persona debería seguir una secuencia conocida.

1. Definir función. Qué tareas va a realizar.
2. Crear identidad nominal. Evitar reutilizar cuentas de otra persona.
3. Configurar acceso remoto. Añadir únicamente sus credenciales.
4. Asignar permisos. Solo los necesarios para su responsabilidad.
5. Dar acceso a documentación e inventario.
6. Entregar referencias a secretos estrictamente necesarios.
7. Explicar procedimiento de cambios y emergencias.
8. Registrar el alta.

El objetivo es que el acceso sea repetible y no una colección de excepciones improvisadas.

Procedimiento para retirar accesos

La baja es tan importante como el alta.

Conviene revisar:

• cuenta Linux;
• claves SSH;
• pertenencia a grupos administrativos;
• acceso a repositorios;
• acceso a documentación;
• credenciales compartidas conocidas;
• tokens personales;
• tareas o scripts asociados a la cuenta.

No eliminar la cuenta antes de revisar dependencias

Un proyecto situado dentro de un directorio personal o una tarea programada ejecutada por esa cuenta puede dejar de funcionar. Esa dependencia debe detectarse y corregirse.

Preparar acceso de emergencia

Una plataforma no debería quedar inaccesible porque la única persona administradora no está disponible.

La continuidad puede apoyarse en:

• más de una persona autorizada cuando sea necesario;
• documentación recuperable;
• inventario actualizado;
• credenciales de emergencia protegidas;
• procedimientos de recuperación;
• backups fuera del host.

El acceso de emergencia no debe convertirse en una cuenta compartida de uso cotidiano.

Errores frecuentes

Añadir a todos los técnicos al grupo docker

El acceso al daemon concede una capacidad administrativa muy elevada y debe limitarse.

Compartir una sola cuenta SSH

Elimina trazabilidad y complica la revocación individual.

Guardar proyectos en /home de una persona

Vincula la infraestructura al ciclo de vida de esa cuenta.

Compartir todas las credenciales con todos

Administrar un proyecto no implica necesitar acceso a los secretos de todos los demás.

Montar el socket Docker en cualquier panel

La comodidad operativa no elimina el nivel de privilegio asociado.

Usar el panel gráfico como única documentación

Si falla, la plataforma sigue necesitando una fuente de verdad.

No registrar cambios

Con varias personas, las modificaciones sin contexto se convierten rápidamente en deuda operativa.

No tener procedimiento de baja

Las cuentas y claves antiguas permanecen indefinidamente.

Confundir usuarios de aplicaciones con administradores

La mayoría de los usuarios finales no necesita ninguna cuenta en el servidor Docker.

Dar permisos amplios para resolver un problema puntual

La excepción temporal suele quedarse si no se revisa expresamente.

Modelo sencillo para una pequeña empresa

Un modelo práctico puede estructurarse en cuatro niveles.

En una organización muy pequeña una misma persona puede ocupar varios niveles. La clasificación sigue siendo útil porque aclara qué privilegios derivan de cada responsabilidad.

Procedimiento paso a paso

1. Identifica quién utiliza aplicaciones y quién administra infraestructura.
2. Elimina la dependencia de cuentas compartidas. Utiliza identidades nominales cuando corresponda.
3. Revisa miembros del grupo docker. Mantén únicamente quienes necesitan realmente ese nivel de control.
4. Revisa sudo y otros privilegios. No los concedas por simple conveniencia.
5. Organiza SSH. Claves individuales y revocables.
6. Mueve proyectos fuera de directorios personales.
7. Define propietarios y permisos coherentes.
8. Controla quién modifica Compose y configuración.
9. Separa secretos por necesidad.
10. Revisa cualquier acceso al socket Docker.
11. Define responsabilidades operativas.
12. Registra cambios.
13. Mantén inventario y documentación comunes.
14. Define altas y bajas.
15. Prepara una vía de emergencia.
16. Revisa permisos periódicamente.

Lista de comprobación

Preguntas frecuentes

Conclusión

Preparar Docker para una pequeña empresa con varios usuarios exige separar claramente uso de aplicaciones, mantenimiento de proyectos y administración del motor Docker. No todas las personas necesitan una cuenta en el servidor y, entre quienes sí la necesitan, no todas requieren el mismo nivel de privilegio.

Las cuentas nominales, las claves individuales, los proyectos situados fuera de directorios personales y los permisos previsibles crean una base mucho más mantenible que una cuenta compartida utilizada por todos. El grupo docker y el socket del daemon deben tratarse como recursos administrativos de alto privilegio, no como simples mecanismos de comodidad.

La administración compartida funciona cuando cada acceso puede explicarse, cada cambio puede atribuirse y cada permiso puede revocarse sin desorganizar la plataforma.

El inventario y la documentación completan el modelo: permiten que otra persona autorizada comprenda qué servicios existen, cómo se despliegan, qué datos necesitan y cómo se recuperan. Así la continuidad deja de depender de una única cuenta o de la memoria de un único administrador.

Una pequeña empresa no necesita burocracia para conseguirlo. Necesita pocas reglas estables, acceso administrativo limitado, responsabilidades visibles y procedimientos sencillos de alta, cambio y baja. Con esas bases, Docker puede seguir siendo una plataforma flexible incluso cuando deja de estar administrada por una sola persona.