web-dev-qa-db-fra.com

Entropie insuffisante pour prendre en charge / dev / random dans les conteneurs docker exécutés dans boot2docker

Le manque d'entropie dans les systèmes Linux virtualisés semble être un problème courant (par exemple / dev/random Extremely Slow? , Obtenir Linux pour tamponner/dev/random ). Malgré l'utilisation d'un générateur de nombres aléatoires matériel (HRNG), l'utilisation d'un démon de collecte d'entropie comme A FORGÉ est souvent suggérée. Cependant, un démon de collecte d'entropie (EGD) ne peut pas être exécuté à l'intérieur d'un conteneur Docker, il doit être fourni par l'hôte.

L'utilisation d'un EGD fonctionne très bien pour les hôtes Docker basés sur des distributions Linux comme Ubuntu, RHEL, etc. Faire fonctionner un tel démon dans boot2docker - qui est basé sur Tiny Core Linux (TCL) - semble être une autre histoire. Bien que TCL ait un mécanisme d'extension, une extension pour un démon de collecte d'entropie ne semble pas être disponible .

Un EGD semble donc être une bonne solution pour exécuter des conteneurs Docker dans un environnement d'hébergement (de production), mais comment le résoudre pour le développement/test dans boot2docker?

Étant donné que l'exécution d'un EGD dans boot2docker semblait trop difficile, j'ai pensé à utiliser simplement/dev/urandom au lieu de/dev/random. L'utilisation de/dev/urandom est un peu moins sécurisée, mais reste correcte pour la plupart des applications qui ne génèrent pas de clés cryptographiques à long terme. Au moins, cela devrait convenir pour le développement/test dans boot2docker.

dockerboot2docker
50
mbonato

Je viens de réaliser qu'il est simple de monter/dev/urandom depuis l'hôte en tant que/dev/random dans le conteneur:

$ docker run -v /dev/urandom:/dev/random ...

Le résultat est comme prévu:

$ docker run --rm -it -v /dev/urandom:/dev/random ubuntu dd if=/dev/random of=/dev/null bs=1 count=1024
1024+0 records in
1024+0 records out
1024 bytes (1.0 kB) copied, 0.00223239 s, 459 kB/s

Au moins, je sais comment construire mes propres images boot2docker maintenant ;-)

49
mbonato

La solution la plus élégante que j'ai trouvée est d'exécuter Haveged dans un conteneur séparé:

docker pull harbur/haveged
docker run --privileged -d harbur/haveged

Vérifiez si suffisamment d'entropie disponible:

$ cat /proc/sys/kernel/random/entropy_avail
2066
13
Oleksandr Horobets

Une autre option consiste à installer le package rng-tools et à le mapper pour utiliser le/dev/urandom

  yum install rng-tools
  rngd -r /dev/urandom

Avec cela, je n'avais pas besoin de mapper de volume dans le conteneur Docker.

3
Alexandre L Telles

Comme je n'aimais pas modifier mes conteneurs Docker pour le développement/test, j'ai essayé de modifier l'image boot2docker. Heureusement, l'image boot2docker est construite avec Docker et peut être facilement étendue . J'ai donc mis en place ma propre version Docker boot2docker-urandom . Il étend l'image boot2docker standard avec une règle udev trouvée ici .

Construire votre propre image boot2docker.iso est aussi simple que

$ docker run --rm mbonato/boot2docker-urandom > boot2docker.iso

Pour remplacer le boot2docker.iso standard fourni avec boot2docker, vous devez:

$ boot2docker stop
$ boot2docker delete
$ mv boot2docker.iso ~/.boot2docker/
$ boot2docker init
$ boot2docker up

Limitations , depuis l'intérieur d'un conteneur Docker/dev/random still blocks. Très probablement, car les conteneurs Docker n'utilisent pas directement/dev/random de l'hôte, mais utilisent le périphérique noyau correspondant - qui se bloque toujours.

2
mbonato

Alpine Linux peut être un meilleur choix pour un hôte docker léger. Alpine LXC & docker les images ne font que 5 Mo (contre 27 Mo pour boot2docker)

J'utilise haveged sur Alpine pour LXC invités et sur Debian pour docker invités. Il donne suffisamment d'entropie pour générer gpg/ssh clés et openssl certificats dans les conteneurs. Alpine a maintenant un repo officiel docker .

Alternativement, créez un paquet haveged pour Tiny Core - il y a un système de construction de paquet disponible.

2
Stuart Cardall

si vous rencontrez ce problème dans un conteneur Docker créé à partir d'une image auto-construite qui exécute une application Java (par exemple créée FROM Tomcat:Alpine)) et qui n'a pas accès à l'hôte ( par exemple sur un cluster k8s géré), vous pouvez ajouter la commande suivante à votre dockerfile pour utiliser l'amorçage non bloquant de SecureRandom:

RUN sed -i.bak \
  -e "s/securerandom.source=file:\/dev\/random/securerandom.source=file:\/dev\/urandom/g" \
  -e "s/securerandom.strongAlgorithms=NativePRNGBlocking/securerandom.strongAlgorithms=NativePRNG/g" \
  $Java_HOME/lib/security/Java.security

les deux expressions rationnelles remplacent file:/dev/random par file:/dev/urandom et NativePRNGBlocking par NativePRNG dans le fichier $Java_HOME/lib/security/Java.security, ce qui permet à Tomcat de démarrer assez rapidement sur un vm. je n'ai pas vérifié si cela fonctionne également sur les images openjdk non alpines, mais si la commande sed échoue, vérifiez simplement l'emplacement du fichier Java.security à l'intérieur du conteneur et adaptez le chemin en conséquence .

remarque: dans jdk11, le chemin d'accès est devenu $Java_HOME/conf/security/Java.security

2
Remigius Stalder