web-dev-qa-db-ja.com

boot2dockerで実行されているDockerコンテナで/ dev / randomをサポートするのに十分なエントロピーがありません

仮想化Linuxシステムでエントロピーが不足することは、一般的な問題のようです（例： / dev/random Extremely Slow？ 、 Linuxを/ dev/randomにバッファリングする ）。ハードウェア乱数ジェネレーター（HRNG）を使用しているにもかかわらず、 [〜＃〜] haveged [〜＃〜] のようなエントロピー収集デーモンの使用がしばしば推奨されます。ただし、エントロピー収集デーモン（EGD）はDockerコンテナー内で実行できません。ホストによって提供される必要があります。

EGDの使用は、Ubuntu、RHELなどのLinuxディストリビューションに基づいたdockerホストで正常に動作します。このようなデーモンをTiny Core Linux（TCL）に基づいたboot2docker内で動作させることは別の話のようです。 TCLには拡張メカニズムがありますが、エントロピー収集デーモンの拡張機能 利用できないようです 。

したがって、EGDは（実稼働）ホスティング環境でDockerコンテナを実行するための適切なソリューションのように見えますが、boot2dockerで開発/テストするためにそれを解決する方法はありますか？

Boot2dockerでEGDを実行するのは難しすぎると思われたため、/ dev/randomではなく/ dev/urandomを使用することを考えました。/dev/urandomの使用は安全性はそれほど高くありませんが、長期の暗号化キーを生成しないほとんどのアプリケーションでは問題ありません。少なくとも、boot2docker内での開発/テストには問題ありません。

dockerboot2docker
50
mbonato

ホストから/ dev/urandomを/ dev/randomとしてコンテナにマウントするだけで簡単であることに気付きました。

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

結果は期待どおりです。

$ 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

少なくとも、今は自分のboot2dockerイメージを構築する方法を知っています;-)

49
mbonato

私が見つけた最もエレガントなソリューションは、別のコンテナでHavegedを実行することです。

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

十分なエントロピーが利用可能かどうかを確認します。

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

別のオプションは、rng-toolsパッケージをインストールし、/ dev/urandomを使用するようにマップすることです。

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

これにより、ドッカーコンテナにボリュームをマッピングする必要がなくなりました。

3
Alexandre L Telles

開発/テスト用にDockerコンテナを変更したくないので、boot2dockerイメージを変更しようとしました。幸いなことに、boot2dockerイメージはDockerでビルドされており、簡単に extended にできます。そこで、独自のDockerビルドをセットアップしました boot2docker-urandom 。標準のboot2dockerイメージを、 here が見つかったudevルールで拡張します。

独自のboot2docker.isoイメージの構築は次のように簡単です

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

Boot2dockerに付属している標準のboot2docker.isoを置き換えるには、次を行う必要があります。

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

制限事項、Dockerコンテナ内から/ dev/randomはまだブロックします。最も可能性が高いのは、Dockerコンテナがホストの/ dev/randomを直接使用せず、対応するカーネルデバイスを使用するためです-依然としてブロックします。

2
mbonato

Alpine Linux は、軽量のdockerホストに適した選択肢です。 Alpine LXC＆docker画像は5MBのみです（boot2docker）

havegedのゲストには Alpine で、LXCのゲストにはDebianでdockerを使用します。コンテナにgpg/sshキーとopenssl証明書を生成するのに十分なエントロピーを与えます。 Alpineには公式のdockerリポジトリがあります 。

または、Tiny Core用のhavegedパッケージをビルドします- パッケージビルドシステム が利用可能です。

2
Stuart Cardall

Java app（たとえばFROM Tomcat:Alpineを作成））を実行する自己構築イメージから作成されたドッカーコンテナーにこの問題があり、ホストにアクセスできない場合（たとえば管理されたk8sクラスターで）、次のコマンドをdockerfileに追加して、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

2つの正規表現は、file:/dev/randomをfile:/dev/urandomで置き換え、NativePRNGBlockingをNativePRNGで$Java_HOME/lib/security/Java.securityファイルで置き換えます。これにより、Tomcatはvm上でかなり高速に起動します。 Alpineベース以外のopenjdkイメージでもこれが機能するかどうかは確認していませんが、sedコマンドが失敗した場合は、コンテナー内のファイルJava.securityの場所を確認し、それに応じてパスを調整します。

note： jdk11では、パスが$Java_HOME/conf/security/Java.securityに変更されました

2
Remigius Stalder