Lista de comprobación para la asignación de usuarios y grupos de contenedores en recursos compartidos NAS

El enfoque seguro consiste en tratar la comprobación de la asignación de identidades numéricas, desde la exportación del NAS, pasando por el montaje del host, hasta el proceso del contenedor en ejecución, como una secuencia de puntos de control observables, no como un único comando.

En un host de contenedores Linux que utiliza recursos compartidos NAS respaldados por SMB o NFS, el riesgo práctico es que un contenedor pueda ver una ruta montada del NAS, pero las lecturas o escrituras fallen con errores de permisos. Registra la identidad actual y el punto de recuperación, comienza con el discriminador menos invasivo, interpreta los resultados correctos y fallidos antes de cambiar otra variable, y detente cuando el almacenamiento se vuelva inestable o la única copia recuperable pudiera quedar expuesta. El flujo de trabajo siguiente solo termina cuando la carga de trabajo original funciona o las pruebas alcanzan un límite que requiere escalamiento.

Identifica la identidad real del proceso del contenedor

Inspecciona la documentación de la imagen, la configuración user de Compose, las variables de entorno, el comportamiento del punto de entrada y los grupos suplementarios, UID y GID del proceso de la aplicación en ejecución. Las variables llamadas PUID y PGID son convenciones de las imágenes, no funciones universales de Docker, así que confirma que esta imagen las admite.

Un caso de la comunidad de LinuxServer sobre un caso de permisos de PUID y PGID en un contenedor demuestra que unos valores de PUID y PGID aparentemente correctos aún pueden dejar inaccesible un montaje enlazado. Usa el caso como recordatorio para inspeccionar el proceso y el montaje en ejecución, no como prueba de que todas las imágenes implementen la misma lógica de inicialización.

Registra los valores numéricos con id dentro del contenedor y en el host. Detente si la aplicación se ejecuta como root únicamente porque los permisos fallaron anteriormente; el acceso de root oculta el defecto de asignación y aumenta el impacto de un servicio comprometido.

Rastrea la propiedad desde el NAS hasta el montaje del host

En el NAS, inspecciona el propietario numérico, el grupo, el modo, la ACL y la ACL predeterminada del directorio de destino. En el host del contenedor, inspecciona los mismos objetos montados y compara los valores numéricos. Si los nombres difieren pero los números coinciden, las etiquetas son meramente cosméticas; si los números difieren, la ruta de autorización es realmente distinta.

Para NFS, incluye las opciones de exportación, la versión de NFS, la asignación de identidades, la ocultación de root y la identidad de montaje del cliente. Para SMB, incluye las credenciales de montaje, la identidad asignada en el servidor, las opciones de presentación uid o gid y si se utilizan extensiones Unix o traducción de ACL.

No cambies a la vez las ACL del servidor y las opciones de montaje del cliente. La etapa se supera cuando un archivo de prueba tiene un propietario numérico conocido y el host muestra una asignación estable después de desmontar, volver a montar y reiniciar.

Prueba el montaje enlazado y los grupos suplementarios

Confirma que la ruta de origen del contenedor sea el montaje esperado del host, en lugar de un directorio local vacío creado antes de que se montara el recurso compartido de red. Inspecciona el montaje en ejecución y prueba a listar, leer, crear, cambiar de nombre y eliminar como el usuario de la aplicación en un subdirectorio desechable.

Un caso de Server Fault documenta una discordancia de permisos de ACL en NFS incluso cuando el propietario y las entradas de la ACL parecen coincidir, lo que demuestra por qué es necesario inspeccionar la máscara de la ACL, la asignación del servidor y la identidad efectiva. Captura getfacl tanto del directorio como del archivo creado.

Si se necesita acceso mediante grupos, añade el grupo numérico suplementario compatible y vuelve a crear el contenedor, porque los grupos del proceso se fijan al iniciarse. Usa la guía de ZimaSpace sobre el diagnóstico de rutas vacías en contenedores cuando la aplicación se inicia con una ruta vacía; eso es un problema de orden de montaje, no de ACL.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Aplica la corrección de identidad más limitada y vuelve a probar

Da prioridad a alinear el UID, el GID o el grupo suplementario compatible de la aplicación con la política del NAS. Usa un grupo compartido y una ACL heredada cuando varios servicios colaboren. Evita los permisos de escritura para todos, los cambios recursivos de propiedad en conjuntos de datos no relacionados y los contenedores privilegiados como atajos.

Vuelve a crear el contenedor, vuelve a montar el recurso compartido si cambiaron las opciones de asignación y repite las mismas operaciones. Reinicia el host una vez para verificar que el orden de montaje y la identidad numérica sobrevivan al arranque. Confirma que los archivos nuevos sigan siendo modificables por los clientes humanos previstos sin otorgar derechos innecesarios al contenedor.

Cierra la lista de comprobación cuando la aplicación supere su carga de trabajo original, las operaciones denegadas sigan denegadas y la propiedad permanezca estable tras reiniciar. Escala el caso si los espacios de nombres de usuario, las asignaciones sin root o los servicios de identidad del NAS reescriben los ID de una forma que la imagen elegida no pueda admitir.