La technologie Docker me plaît bien dans le principe et aussi vis-à-vis du gain de temps dans certaines situations et de la portabilité dans d’autres mais je m’interroge sur les failles de sécurité qu’elle peut induire. Notamment car certaines actions de Docker nécessitent des droits élevés (apparemment, le groupe “docker” a des permissions importantes, même si je n’ai pas encore trouvé beaucoup d’infos là-dessus).
Sécuriser les entrées est une chose, et peut se faire si on se donne la peine mais installer sans vergogne un contenu que l’on n’a pas forcément le temps de vérifier pose la question de la confiance des sources.
Aux utilisateurs de cette technologie : avez-vous des réflexes/habitudes d’utilisation pour limiter le risque de déployer des dockers vérolés ? (Empreintes/clés de vérification, dépôts éprouvés et approuvés, autre.)
bonsoir,
quand vous manipulez Docker,
avez-vous un “trés” bon parefeu?
quand vous manipulez Oracle, vous choissez vos produits chez Oracle,
quand vous manipulez un Linux, par défaut vous téléchargez depuis le mainteneur
quand vous manipulez avec M$ allez-vous par défaut chez M$
n’oublions pas que ces produits utilisent trés, trés souvent “des portes arrières”
mais je l’avoue, l’environnement Docker est une aide précieuse,
Lesquels, les seuls failles induites par docker lui même sont en générale comblé par le maintient à jour ?
Les autres viennent de l’humain (comme bien souvent).
Le groupe docker n’a pas de pouvoir autrement que sur docker (ce qui est déjà pas mal :D).
Après je vois pas en quoi un container est différents d’un paquet, si tu installe de la mer… tu installe de la mer…
JE ne déploie pas de container déjà préparé en production, en règle générale je refais mes fichiers compose et je n’utilise pas de répertoire autre que des répertoires officiels.
Si j’ai besoin d’un paquet spécifiques je le compile auparavant et j’utilise mon répo perso.
Pareil pour mes containers, j’ai une CI dans Gitlab qui me permet de gérer l’intégralité de mes containers /stacks.
Maintenant un docker file ce n’est qu’une recette, il faut bien regarder ce qu’il y a dedans et comprendre un minimum la provenance des paquets et autres fichiers de configurations, docker ce n’est pas de la magie non plus.
En exemple voici un exemple de docker file (il faut le voir comme une recette de cuisine finalement) :
Pour le restant tu n’expose pas inutilement tes services/ports, tu évite de piocher n’importe où et surtout faut avoir branché son cerveau, car finalement ce que tu déploie dans Docker c’est pareil que ce que tu déploie sur un serveur à peu de chose près.
Oui c’est exactement ce que je veux dire. Par exemple, je fais confiance aux dépôts Debian (je n’ai pas le temps de décortiquer chaque paquet avant de le compiler à la main) et à quelques autres rares que j’étudie un minimum avant d’utiliser.
C’est un peu mon interrogation, sont-ils fiables (je sais on n’est jamais sûr à 100% mais c’est pour avoir un retour utilisateur) ? Je suis récemment tombé sur cet article : https://banyanops.com/blog/analyzing-docker-hub/ mais il est vieux (mai 2015) et je n’ai pas pu trouver d’infos plus récentes à ce sujet.
C’est mon but. Probablement avec Gitlab d’ailleurs.
C’est peut-être là que ça déconne, je vais regarder ça dès que possible.^^
Docker hub c’est bien pour une chose trouver une recettes fonctionnel rapidement, après faut toujours analyser et et comprendre si c’est ce que l’on recherche (selon nos différents besoins).
Après déployer un reverse proxy nginx c’est pas extraordinaire donc pourquoi vouloir réinventer la roue, vue que le docker file va demander à installer un paquet qui proviendra d’un dépôts de … en fait ce que tu préfère.
(comme bien souvent).