Qué pasó cuando prohibí el acceso root en todo mi catálogo de aplicaciones
Fabian, Fundador de Bitflake July 22, 2026
Blindé la plataforma: ninguna aplicación se ejecuta como root, los sistemas de archivos son de solo lectura por defecto, y cada aplicación queda aislada en su propio segmento de red para que una aplicación comprometida no pueda alcanzar las aplicaciones de nadie más. Después volví a desplegar todo el catálogo para ver qué se rompía.
Las cifras
Cincuenta y dos aplicaciones pasaron por la prueba. Las aplicaciones ya excluidas del catálogo por motivos ajenos a esto no formaron parte de esta ronda, ya que de todos modos no se están ejecutando.
- 17 aplicaciones (33 %) funcionaron sin cambios.
- 26 aplicaciones (50 %) necesitaron correcciones. Casi todas fueron del mismo tipo: un sistema de archivos de solo lectura únicamente permite escribir en las rutas que he abierto explícitamente, y la mayoría de las imágenes no documentan dónde escriben.
- 9 aplicaciones (17 %) no pueden funcionar en absoluto sin root, y ninguna de ellas ofrece una versión que sí pueda.
Por qué tantas aplicaciones quieren root
Dos patrones cubren casi todos los casos.
El primero es PUID/PGID, una convención popularizada por las imágenes de LinuxServer.io: el contenedor arranca como root, corrige la propiedad de los archivos de las carpetas que va a usar y después baja al ID de usuario configurado. Funciona bien en un servidor doméstico donde usted es dueño de toda la máquina. No funciona en absoluto si la plataforma directamente no deja que el contenedor arranque como root. La corrección de propiedad nunca llega a ejecutarse.
El segundo es el puerto 80. Ocho de las nueve aplicaciones bloqueadas sirven su interfaz web en el puerto 80 dentro del contenedor, y en Linux solo root puede vincular un puerto por debajo de 1024. Detrás de un proxy inverso, que es como en realidad se accede a todas estas aplicaciones, esa restricción no protege nada. Es un valor por defecto heredado.
Un patrón más pequeño y curioso: tres aplicaciones fallaban justo en el momento en que intentaban dejar de ser root. Sus puntos de entrada bajan privilegios con herramientas como su-exec o gosu, y bajar privilegios es en sí mismo una operación exclusiva de root. Una vez que al contenedor no se le permite arrancar como root, ese paso también falla. Dos de las tres se podían corregir omitiendo ese paso y arrancando directamente como el usuario de destino. La tercera no tenía ese atajo.
Qué significa esto si se autoaloja
Nada de esto hace que estas aplicaciones estén mal construidas. Sus imágenes están pensadas para un único servidor de confianza, donde arrancar como root para corregir unos cuantos permisos de archivos es una comodidad menor, no un riesgo. Una plataforma compartida que ejecuta decenas de aplicaciones sin relación entre sí, una junto a otra, es un entorno distinto: si una aplicación se ve comprometida, el acceso root dentro de su contenedor le da a un atacante una superficie de ataque mucho mayor contra el kernel, la capa que se supone que debe mantenerlo alejado de los datos de todos los demás.
Si usted mismo autoaloja alguna de estas aplicaciones, merece la pena comprobar cómo arrancan. La pista más rápida está en la documentación: si una imagen habla de PUID y PGID, arranca como root y baja de nivel más tarde. Los Pod Security Standards de Kubernetes documentan el perfil "restricted" que descarta esto, y es el perfil contra el que ahora ejecuto todo.
Dónde quedan las nueve
Por ahora, ninguna de las nueve funciona en el catálogo de Bitflake. No he decidido si eso es permanente. Las opciones son una corrección desde el proyecto original, una imagen distinta o una excepción acotada a la regla de no-root. Cada una tiene sus propias contrapartidas, y prefiero pensarlo bien antes de elegir una ahora mismo.