‫Prochaine place.
‫C'est un gros.
‫N'exécutez pas vos applications en tant que root dans le conteneur si vous
‫pouvez les éviter.
‫Si je fais ça très vite, sur une petite
‫démo ici.
‫D'accord. J'ai Docker en cours d'exécution, au
‫moins je devrais. D'accord.
‫Et si je cours juste ...
‫Si je viens de lancer Nginx, oui, et je
‫fais un docker top sur
‫ce conteneur.
‫Que voyons-nous ici?
‫Dans le conteneur, Nginx a démarré un processus
‫à la racine, puis a créé un
‫nouveau processus en tant qu'utilisateur non
‫root. Voir comment cet utilisateur est 101.
‫Ceci est commun à beaucoup de programmes basés sur les
‫démons comme MySQL, Postgres, Nginx.
‫Beaucoup d’entre eux qui ne sont pas des langages de programmation
‫le feront automatiquement. Donc, c'est sûr.
‫Cela permet à Nginx de générer des processus de
‫travail qui ne s'exécutent pas en tant que
‫root pour effectuer la majorité du travail.
‫Donc, ils ont un processus maître qui fonctionne en tant que root, mais
‫ce n'est pas ce qui accepte les connexions et fait la
‫majorité du travail. La plupart de
‫cela est dans ces processus de travail. Ils fonctionnent en tant qu'utilisateur
‫normal, ce qui signifie que s'il y a une vulnérabilité dans
‫Nginx, il y a de grandes chances
‫que les connexions entrantes entrent et que quelqu'un tente d'exploiter
‫le protocole HTTP Nginx, il sera verrouillé ou emprisonné dans cet utilisateur
‫à .. . la plupart du temps,
‫sauf en cas de vulnérabilité grave ici.
‫En bas, et ensuite, ils sont limités à ce qu'ils
‫peuvent faire, non. Même s'ils devaient prendre en
‫charge ce processus, ils sont toujours limités en tant qu'utilisateur.
‫Donc c'est OK.
‫Cela ne fonctionne toujours pas en tant que racine
‫véritable dans le conteneur. Ce dont je parle vraiment, c’est
‫que si vous exécutiez une
‫application Python, ou une application Node, ou quelque
‫chose du genre où il s’agissait d’un langage de programmation, il s’agirait de
‫quelque chose dont la racine par défaut serait root
‫car le langage de programmation du conteneur ne le permet pas. Sachez
‫comment fonctionne votre programme. Il ne sait pas ce que vous voulez qu'il fasse.
‫Donc, cela va faire root par défaut, et c'est
‫plus sur la compatibilité des applications.
‫Nous pourrions dire que nous voulons que cela soit sécurisé par défaut,
‫mais Docker a choisi de faire en sorte que tous ces conteneurs officiels fonctionnent réellement en
‫tant que root pour les langages de programmation.
‫Allons voir ça.
‫Oops. Pas celui là.
‫Firefox.
‫Donc, si nous allons, disons, à Hub.
‫Faisons juste Node.
‫Ceci est commun à la plupart des langues.
‫Je vais juste prendre Node comme exemple.
‫Inside Node,
‫si je vais dans l’un des fichiers Docker ici.
‫Ensuite, je recherche un utilisateur.
‫Vous remarquerez que je ne trouve rien en réalité.
‫C'est seulement cet utilisateur ajoute ici.
‫Vous remarquerez que c'est ce qui se passe, d'accord.
‫Techniquement, il ajoute un groupe appelé Node et
‫un utilisateur appelé Node.
‫Si vous effectuez une recherche dans le reste de ce fichier, vous réalisez qu'il
‫ne change jamais pour cet utilisateur avec la strophe U S
‫E R, non.
‫Vous devriez voir le noeud utilisateur quelque part comme une ligne.
‫Ils ne le font pas parce que c'est votre travail.
‫Donc, ce que vous devriez faire dans
‫votre fichier Dockerfile. Ainsi, tout fichier Docker
‫que vous créez à partir de ces
‫images officielles pour les langages de programmation, vous devriez tirer parti
‫des utilisateurs qu'ils créent pour vous. S'ils ne créent pas ces utilisateurs, vous pouvez en créer
‫un vous-même de la même manière. Vous pouvez juste voler
‫cette petite chose de deux lignes et changer à n'importe quel utilisateur
‫que vous voulez qu'il soit. Si c'est pour Python,
‫vous pouvez simplement l'appeler utilisateur Python, peu importe.
‫Si vous faites cela, les applications que vous exécutez
‫ne seront pas exécutées en tant que root dans le
‫conteneur. Par défaut,
‫si vous exécutez uniquement une application de nœud standard, elle utilisera l'utilisateur
‫root dans un conteneur.
‫Pourquoi est-ce si important?
‫Eh bien, deux choses.
‫Premièrement, si quelqu'un parvient à percer votre application
‫et à la pirater, il pourra accéder au système
‫de fichiers s'il ... si cette application est root, dans
‫le conteneur, ils peuvent faire ce qu'ils veulent dans
‫le conteneur, non. Ils peuvent écrire des
‫fichiers dans le système de fichiers. Ils peuvent installer plus de programmes
‫dans ce conteneur, qui peuvent être exécutés à tout moment.
‫Donc, nous ne voulons vraiment pas qu'ils fassent cela.
‫Nous préférerions qu'ils soient très limités.
‫Donc, si vos applications le prennent
‫en charge, faites-le. En gros, vous vous assurez que
‫l'utilisateur est disponible.
‫Ensuite, j'ai un exemple de DockerCon ici.
‫Chez DockerCon, j'ai eu toute une discussion sur Node. js, et l'un
‫des sujets était sur l'utilisateur.
‫Laissez-moi voir si je peux trouver ça.
‫Tu vois ce que j'ai fait ici? C'est un fichier assez simple.
‫Je vais lier ceci et le mettre dans.
‫Dans ce Dockerfile.
‫Donc, dans ce Dockerfile j'ai ...
‫Je n'ai pas créé d'utilisateur, car l'image du nœud
‫l'a déjà créée pour moi. Je suis juste en train de changer en noeud utilisateur.
‫Ensuite, j'installe mes paquets avec ces deux lignes, puis plus tard,
‫je vais l'exécuter.
‫Vous remarquerez que je dois commencer
‫à utiliser l'option chown dans mes commandes de copie pour m'assurer que
‫mes fichiers sont maintenant le même utilisateur que l'utilisateur sous lequel mon
‫programme sera exécuté. Sinon, il pourrait y avoir des
‫problèmes, non. Mon application probablement ... s'il
‫ne peut pas lire les fichiers, il ne peut pas l'exécuter, non.
‫Donc, j'ai besoin des modifications de ces autorisations.
‫Je peux le faire avec une seule ligne sur une commande de copie.
‫Vous verrez également ici que je crée et répertorie le répertoire
‫afin que, chaque fois que l'application est copiée, je souhaite
‫simplement m'assurer, avec une extrême certitude, que les
‫autorisations sont là pour lui permettre d'écrire.
‫À la minute où je change d'utilisateur, cette
‫commande de copie, ou plus précisément cette commande d'exécution, s'exécutera sous
‫cet utilisateur. S'il n'a pas
‫l'autorisation d'écrire dans les répertoires, il échouera également.
‫Donc, la raison pour laquelle Docker ne le fait pas pour vous, c'est
‫parce qu'ils savent que vos affaires vont probablement casser.
‫Donc, vous devez prendre ces mesures supplémentaires.
‫Mais ce n'est pas si difficile. C'est vraiment pas.
‫Vous pouvez probablement faire tous ces tests en une journée, puis
‫vous voudrez faire fonctionner vos systèmes avec un CI complet et
‫des tests complets sur vos serveurs car parfois, PHP est l'un de
‫ceux qui ne fonctionnent pas bien.
‫PHP aime exécuter un tas de fichiers journaux et
‫écrire sur le disque.
‫Vraiment, tout ce qui permet aux utilisateurs de télécharger va écrire
‫sur le disque. Donc, vous devez vous
‫assurer que ces autorisations sont correctes afin que lorsque les gens écrivent des fichiers,
‫par exemple, ils courent un blog WordPress.
‫Ce blog WordPress écrit sur le disque lorsque les utilisateurs
‫téléchargent des images dans leur blog.
‫Vous voulez vous assurer que ces autorisations vont fonctionner.
‫Donc, vous allez certainement devoir faire des tests.
‫Une fois que vous avez fait cela, votre application ne s'exécutera
‫plus en tant que root. Donc, il ne peut pas avoir un
‫contrôle total sur le conteneur. L'autre raison pour laquelle
‫vous voulez faire cela est s'il y a une vulnérabilité
‫dans Linux, ce qui est rare, ou Docker, qui est également
‫très rare, alors il y a moins de chances
‫qu'ils sortent de ce conteneur. Ce n'est que arrivé, eh bien, une
‫fois que je suis très au courant, et j'ai en fait documenté un
‫peu de cela ici.
‫Sale vache. Dirty COW était
‫une vulnérabilité sous Linux qui vous permettait de
‫sortir
‫d'un conteneur, n'est-ce pas? Changer votre utilisateur ici
‫ne résoudrait
‫pas nécessairement tout le problème, mais
‫cela ne l’a certainement pas gêné.
‫D'autres vulnérabilités, il serait probablement protéger contre.
‫Mais c'est une pratique exemplaire.
‫Je pense que si vous avez une équipe de sécurité, elle va
‫en quelque sorte insister pour que vous ne dirigiez pas les choses en tant que root.
‫Alors, tu ferais
‫ça.