Sécurisation de Docker

[goerges]

Bonjour,

J'ai remarqué que mes conteneurs qui avaient besoin d'un PUID avaient tous le PUID 1026 qui correspond à l'id de l'administrateur du nas, et, je crois, que niveau sécurité, c'est pas l'idéal ;-).

Comme disait @.Shad.dans un autre post:

Le mieux est de faire un utilisateur et groupe dédié, il faut a minima que le groupe donne les droits sur les dossiers utiles (lecture seule sur /volume1/music, lecture/écriture sur le dossier dans lequel tu montes la config du conteneur et éventuellement le dossier playlist. Attention que ton utilisateur fait automatiquement partie du groupe users, si tu as interdit l'accès à un des dossiers concernés à ce groupe, ça prend le pas sur toutes les autorisations que tu pourrais donner par ailleurs.

Je me demandais alors:

-Faut-il un utilisateur par conteneur ?

-Faut-il absolument créer un groupe pour cet utilisateur ? Ne peut-on pas directement spécifier les droits au niveau utilisateur ?

-Si on "disable"  l'utilisateur, le conteneur fonctionnera t-il encore ?

-Doit-on faite quelque chose de spécial avec les conteneurs qui n'ont pas de PUID spécifié ?

-Y a t-il quelque chose d'autre à faire ?

Merci.

 

Georges.

[.Shad.]

Il y a 5 heures, goerges a dit :

-Faut-il un utilisateur par conteneur ?

Pas nécessairement, par défaut si on ne précise rien c'est root qui exécute le conteneur.
Dans certains cas c'est inévitable, quand on doit aller monter le socket docker par exemple : /var/run/docker.sock

Dans les autres cas, la logique est la même que sur DSM, limiter les accès de chaque utilisateur à ce dont ils ont besoin pour l'utilisation attendue.
Par exemple pour Plex ou Emby, j'ai un utilisateur qui donne les droits en lecture seule sur tout ce qui est multimedia, et lecture!;écriture dans le dossier docker, toutes les applications DSM lui sont interdites.

Il y a 5 heures, goerges a dit :

-Faut-il absolument créer un groupe pour cet utilisateur ? Ne peut-on pas directement spécifier les droits au niveau utilisateur ?

Si on le peut, c'est une question de goût, j'essaie autant que faire se peut de passer par les groupes pour un maximum de permissions, celles de l'utilisateur étant la variable d'ajustement. Plus facile en cas de changement de droits aussi, j'ai juste à modifier ceux du groupe plutôt qu'individuellement.

Il y a 5 heures, goerges a dit :

-Si on "disable"  l'utilisateur, le conteneur fonctionnera t-il encore ?

Jamais essayé, c'est à expérimenter. J'aurais tendance à dire que ça devrait marcher, car je pense que l'utilisateur serait inaccessible depuis l'interface DSM mais pas en ligne de commande.

Il y a 5 heures, goerges a dit :

-Doit-on faite quelque chose de spécial avec les conteneurs qui n'ont pas de PUID spécifié ?

Généralement non, et certaines images s'accommoderaient mal que l'on force l'utilisateur.
Mais pour certaines images, ça ne pose pas de problème.
Dans l'optique où tu utilises Docker sur ton NAS, je t'inviterai à privilégier les images qui permettent de spécifier l'UID et/ou le GID.
Que ce soit par les images Linuxserver ou d'autres collectifs/développeurs.

1000/1000 est souvent le choix par défaut, sauf que là où ça fonctionne bien sur une distribution Linux classique avec un utilisateur par défaut 1000/1000, le NAS se réserve tout un tas d'UID/GID qui rendent l'exécution d'un conteneur compliquée.

[Einsteinium]

Oui alors la vous partez dans un sacré délire les gas...

1) C'est root qui exécute tous les docks, c'est inévitable, la commande docker vous pouvez la tenté avec votre user admin, vous n'aurez aucun droit.

2) Maintenant dans le dock en lui même, oui l'utilisateur qui s’exécute dedans par défaut sera root, le dock est dockerisé... sauf si vous cochez l'options des privilèges élevés ou alors plus granulaire (cap-add, device ou security-opt par exemple), ce dock n'aura nullement accès au nas. Sa seul propriété sera les fichiers créer par ce même dock en interne ou externe (dans l'hypothèse que vous lui monté des volumes pour ce second point)

Il n'y a donc nécessité de faire des utilisateurs avec droit que dans le cas ou vous souhaitez donner des accès en dehors du dossier docker (par défaut tout volume monté dans le dossier docker sera accessible par ce dernier en lecture/écriture)

[.Shad.]

il y a 16 minutes, Einsteinium a dit :

1) C'est root qui exécute tous les docks, c'est inévitable, la commande docker vous pouvez la tenté avec votre user admin, vous n'aurez aucun droit.

root n'exécute pas forcément tous les conteneurs, par contre c'est nécessairement root (sauf depuis la sortie de docker-rootless, mais ça date de quelques jours seulement, et pas sur DSM) qui exécute le service Docker. Ce n'est pas la même chose.
Docker autorise tout à fait qu'on utilise un conteneur avec un utilisateur autre que root via l'argument "user: uid:gid" à sa création.

il y a 20 minutes, Einsteinium a dit :

2) Maintenant dans le dock en lui même, oui l'utilisateur qui s’exécute dedans par défaut sera root, le dock est dockerisé... sauf si vous cochez l'options des privilèges élevés ou alors plus granulaire (cap-add, device ou security-opt par exemple), ce dock n'aura nullement accès au nas. Sa seul propriété sera les fichiers créer par ce même dock en interne ou externe (dans l'hypothèse que vous lui monté des volumes pour ce second point)

D'accord avec ça.

il y a 21 minutes, Einsteinium a dit :

Il n'y a donc nécessité de faire des utilisateurs avec droit que dans le cas ou vous souhaitez donner des accès en dehors du dossier docker (par défaut tout volume monté dans le dossier docker sera accessible par ce dernier en lecture/écriture)

Ce qui est le cas d'une grande partie des images qu'on va probablement utiliser sur un NAS.
Donc oui, pas obligatoire, mais préférable, chacun définit après le niveau d'isolation des services qu'il souhaite mettre en place.

[Einsteinium]

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

root n'exécute pas forcément tous les conteneurs, par contre c'est nécessairement root (sauf depuis la sortie de docker-rootless, mais ça date de quelques jours seulement, et pas sur DSM) qui exécute le service Docker. Ce n'est pas la même chose.
Docker autorise tout à fait qu'on utilise un conteneur avec un utilisateur autre que root via l'argument "user: uid:gid" à sa création.

Oui alors c'est ce que je voulais dire, c'est root qui exécute le service docker, maintenant transmettre une uid/gid en commande comme cela ce n'est n'y officiel, n'y sécurisé (il faut faire du mapping), maintenant c'est surtout un problème de droit sur les fichiers écrits et accès et désormais bon nombre d'image permette cela sans soucis.