Exécuter Portainer en tant que non-root ?

[molinadiaz]

Bonjour,

• Synology DS918+
• DSM 7.1.1-42962 Update 3
• Utilisateur : portainer-ce
• Groupe : docker
• Image : portainer/portainer-ce https://registry.hub.docker.com/r/portainer/portainer-ce/

Je passe en revue chacun de mes containers Docker. L'objectif étant que chaque container soit exécuté par un utilisateur non-root. Par exemple, pour le container vaultwarden, le docker-compose.yml ressemble à ceci où user: 1001:1001 permet de faire exécuter le container par l'utilisateur PUID 1001 du groupe PGID 1001 du système hôte.

version: "3.8"
services:
  vaultwarden:
    image: vaultwarden/server
    user: 1001:1001

Tous mes containers s'exécutent en non-root. Il ne me reste plus qu'à sudo docker-compose up -d mon fichier .yml pour Portainer. Mais le coup du user: 1001:1001 ne prend pas. Voici les logs :

L'arborescence ainsi que les privilèges pour config.json sur lequel il y a une permission non accordée :

Merci pour votre aide.

Cordialement,

Modifié le 12 janvier 2023 par molinadiaz

[.Shad.]

Hello,

Il y a une petite confusion entre plusieurs éléments :

- PUID et PGID ne définissent pas QUI exécute le conteneur, ils définissent le mappage à faire entre un utilisateur dans le conteneur (abc chez Linuxserver souvent) et un utilisateur sur l'hôte. Ces variables ne sont là que pour s'affranchir des problèmes des permissions et du fait que sur les NAS, les UID < 1024 sont réservées par le système.

- UID et GID sont les ID numériques des utilisateurs

- "user:group" (group étant facultatif) que tu définis dans le fichier compose disent QUI exécute le conteneur. Pour que ça fonctionne, il faut que le Dockerfile de l'image le prévoit. La plupart des images sont prévues pour être exécutées via root, sauf à ce que le développeur prenne la peine de créer un utilisateur non privilégié. C'est la bonne pratique mais malheureusement trop peu répandue. Si par laxisme ou par volonté, un utilisateur lambda du conteneur pourrait faire fonctionner l'application, alors tant mieux, mais la plupart du temps tu auras des problèmes de permission comme dans ce cas-là.

[molinadiaz]

Hello @.Shad.,

On est bien d'accord qu'avec :

version: "3.8"
services:
  vaultwarden:
    image: vaultwarden/server
    user: 1001:1001

C'est bel et bien l'utilisateur du système hôte ayant pour UID 1001 et GID 1001 qui exécute mon container ? Je ne me fais pas de fausse idée là-dessus ? En d'autres termes, mon container vaultwarden est bien exécuté en non-root, n'est-ce pas ?

Il y a 2 heures, .Shad. a dit :

Pour que ça fonctionne, il faut que le Dockerfile de l'image le prévoit. La plupart des images sont prévues pour être exécutées via root, sauf à ce que le développeur prenne la peine de créer un utilisateur non privilégié. C'est la bonne pratique mais malheureusement trop peu répandue. Si par laxisme ou par volonté, un utilisateur lambda du conteneur pourrait faire fonctionner l'application, alors tant mieux, mais la plupart du temps tu auras des problèmes de permission comme dans ce cas-là.

Je suis tombé sur ça : https://github.com/portainer/portainer/issues/1888

Bon, ça date un peu, c'est vrai. Et c'est pas vraiment la même image (le repo portainer/portainer est considéré comme déprécié). À ce que je comprends, le gars serait parvenu à exécuter portainer par un utilisateur non-root en mappant depuis l'extérieur un fichier config.json vide dans le container. Juste comme ça :

volumes:
  - "./data:/data"
  - "./config.json:/config.json"

J'ai essayé. Ça ne fonctionne pas.

[.Shad.]

C'est plus compliqué que ça.

Le "service" Docker est par défaut exécuté par root, par opposition à Docker Rootless qui existe depuis plusieurs mois maintenant (mais non présent sur Synology). C'est Docker Rootless qui permet d'exécuter le service Docker avec des utilisateurs non privilégiés. Mais a de fait certaines limitations, voir ici : https://docs.docker.com/engine/security/rootless/

Quand tu spécifies user:group, tu dis que le service à l'intérieur du conteneur est exécuté par l'utilisateur/groupe spécifié. En aucun cas c'est cet utilisateur qui exécute le conteneur sur le NAS, tu peux le vérifier en tapant :

ps aux | grep docker

Tu verras que root est l'utilisateur exécutant.

Donc pour te répondre :

Il y a 6 heures, molinadiaz a dit :

C'est bel et bien l'utilisateur du système hôte ayant pour UID 1001 et GID 1001 qui exécute mon container ? Je ne me fais pas de fausse idée là-dessus ? En d'autres termes, mon container vaultwarden est bien exécuté en non-root, n'est-ce pas ?

Du tout, tu dis à ton conteneur que l'application Bitwarden doit être exécutée par un utilisateur 1001:1001 au sein du conteneur. Si l'image est prévue pour être exécutée par root, alors ça marchera uniquement si tes exécutables sont par exemple en 777, ce qui est peu probable. Si 1001:1001 peut écrire dans un dossier dans un conteneur, alors ces fichiers appartiendront à 1001:1001, et sur le NAS tu verras 1001:1001, sauf si un utilisateur/groupe d'UID/GID 1001 existe, auquel cas tu verras les noms d'utilisateur et de groupe associés (ce qui n'est pas mon cas sur mon DS918+).

C'est là que les PUID et PGID entrent en jeu et nous rendent de fiers services sur un NAS, où le classique 1000:1000 n'est pas exploitable comme sur la grande majorité des distributions Linux. Ils permettent de dire que par exemple l'utilisateur toto d'UID 1045 sur le NAS, et le groups users de GID 100 sur le NAS, sont mappés vers 1001 et 1001 du conteneur. C'est là que la magie opère, car du coup tu n'as pas à gérer cet UID dans DSM, il suffit gérer correctement les accès pour le combo 1045:100.

J'espère que c'est plus clair, si pas n'hésite pas à demander, c'est un concept parfois difficile à appréhender pour les débutants et même les utilisateurs réguliers, ça pourrait donc servir à d'autres.

 

Modifié le 13 janvier 2023 par .Shad.

[molinadiaz]

Hello @.Shad.,

Je suis en déplacement. J'avais prévu de répondre longuement. Mais je vais morceler ma réponse afin d'avancer au compte goutte. 

Il y a 15 heures, .Shad. a dit :

Quand tu spécifies user:group, tu dis que le service à l'intérieur du conteneur est exécuté par l'utilisateur/groupe spécifié. En aucun cas c'est cet utilisateur qui exécute le conteneur sur le NAS, tu peux le vérifier en tapant :

ps aux | grep docker

Tu verras que root est l'utilisateur exécutant.

Je voulais d'abord m'assurer de ça. Étrangement, la commande ne me retourne rien si ce n'est grep lui-même (forcément) exécuté par l'utilisateur du terminal. Comment ça se fait ? Docker avait été installé via le Centre de paquets Synology. Il tourne pourtant actuellement. Et 3 containers aussi, d'ailleurs.

Merci 🙂

[.Shad.]

Tu es bien connecté en root ? Sinon ajouter sudo devant la commande.

[molinadiaz]

Il y a 22 heures, .Shad. a dit :

Tu es bien connecté en root ? Sinon ajouter sudo devant la commande.

Hello @.Shad.,

Oui, oui 😅

Je suis toujours en déplacement. Je repasserai ici naturellement une fois que je serai un peu plus posé car j'ai quelques questions à poser, effectivement. En attendant, sais-tu pourquoi la commande ne retourne rien ? Je confirme que mon Docker est bel et bien en cours de processus, et que mes containers tournent.

Par avance, merci !

[.Shad.]

@molinadiaz désolé pour le temps que j'ai mis pour répondre : effectivement idiotie de ma part, c'est bien le grep qui apparaît....

En revanche, si tu dans le moniteur des ressources de DSM -> Gestionnaire des tâches -> Processus, tu devrais y trouver Portainer, et le PID associé.
En SSH, si tu tapes :

ps -p <PID> au

tu devrais voir root en face du process, c'est le cas chez moi avec Watchtower, qui est un processus exécuté par root dans le conteneur également.

En revanche, je corrige ce que j'ai dit, la plupart des conteneurs Linuxserver exécutent le conteneur depuis l'utilisateur mappé. De ce que je comprenais jusqu'à présent, les deux ne sont pas forcément liés, mais ils essaieraient de faire exécuter l'application via cet utilisateur. Ne prend pas ce que je dis pour argent comptant, je vais investiguer voir si ce n'est pas une incompréhension fondamentale de ma part. 😅

[molinadiaz]

Hello @.Shad.,

À mon tour désolé pour le délais de réponse, je suis toujours en déplacement. Alors, merci pour la petite astuce pour retrouver facilement l'ID de traitement. Tout se passe comme je l'imaginais, je peux te le confirmer :

La commande 

ps -p <PID> au

me retourne bel et bien le processus watchtower exécuté par l'utilisateur watchtower créé au préalable sur le système, et ce grâce à la stack déployée via Portainer de la manière suivante :

version: "3.8"
services:
  watchtower:
    image: containrrr/watchtower:amd64-latest
    user: xxxx:yyyy

où xxxx et yyyy représentent respectivement le UID et le GID !

Pour mon container vaultwarden, même chose, il est bien exécuté par mon utilisateur vaultwarden ! Tout roule 🙂 Les processus sont mieux isolés s'ils ne sont pas gérés par root et la surface d'attaque est amoindrie (du moins, je crois et je l'espère lol).

Forcément, je n'ai que le container portainer-ce qui est exécuté par root, puisque je ne suis pas en mesure de déployer une stack pour portainer lui-même si celui-ci ... n'existe pas encore ! Si maintenant il existe une manière de changer à la volée le user qui exécute le container portainer-ce (maintenant qu'il tourne) pour que celui-ci ne soit plus exécuté par root, je suis preneur ! Reste encore à se poser la question de savoir si ce sera possible de déployer des stacks si Portainer a des droits limités.