Moby: --insecure-レジストリは「dockerpull」にある必要があります

すべてのCIおよび本番環境で、セキュリティで保護されていない内部のDockerレジストリを実行します。 安全でないすべてのレジストリに1つずつリストすることなく、単にアクセスできるようにすると非常に便利だと言わなければなりません。 HAの各環境には複数のレジストリがあります。 この変更により、事態はさらに複雑になりました。 この問題は、デーモンではなくプルにオプションを移動することであるため、特にこれに対処するための別の問題チケットを開きます。

また、レジストリの実行に固定ポートを使用しない場合は、鶏が先か卵が先かという問題が少しあります。

Dockerによってどのポートが割り当てられるかが事前にわからないため、それを参照するフラグを使用してデモを実際に開始することはできません。

：+1：

したがって、 docker pullコマンドラインで--insecureをサポートし、明らかに_this_ pullコマンドのセキュリティチェックを強制的に無効にすると、 @ proppyと@octalthorpeの問題も解決されると

@abourgetリモートAPIでもサポートされている必要があります。

現在、docker-pyはpull関数でinsecure_registryフラグを公開していますが、これはエンドポイントを解決するためにのみ使用されます： https ：

犯人はhttps://github.com/docker/docker/commit/6a1ff022b0744213ed588d9c16dbb13ce055eda6のようです

しかし、その変更が議論された対応するPRまたは問題を見つけることができませんでした。

@tiborvass何かアイデアはありますか？

@ proppy-これは禁輸されたセキュリティの脆弱性として扱われ、広報では議論されませんでした。 コアチームは、この問題を可視化し、投票しました。

このような変更がlocalhost / 127.0.0.1に与える影響について考える必要がありますが、特に熱心ではありません。 これは非標準の珍しい構成であり、ソリューションは十分に文書化されています。

一方、 @ ewindischには、レジストリコンテナがlocalhost実行されている、すでに多くのdockerデーモンが実行されています。

文字通りすべてのユーザーが--insecure-registry localhost:5000を渡す必要がある場合は、それをデフォルトにすることもできます。

@ewindisch禁輸クラスの脆弱性を構成するものについてのドキュメントやガイダンスはありますか？ これは、リモートの認証されていないRCEではありません。 ここでの危険は、警告なしにポイントリリースの重大な変更を正当化するほど深刻ではないようです。

@ mmdriley -Mitre / NSTによる定義が一般的に適用されます。 この場合、影響を受けるシステムで任意の信頼できないコードを実行できる中間者攻撃が実行可能であるため、これをRCEとして分類します。 これは、たとえば、Dockerを使用してカフェのラップトップで画像をプルする場合、そのWiFiアクセスポイントの別のユーザーが攻撃者によって提供された任意のアプリケーションを実行する可能性があることを意味します。 また、DockerHubアカウントまたは認証対象の他のレジストリにアクセスする可能性もあります。

編集：CVEの説明へのリンクを追加： https ：

うん、これはRCEではないと言うのは間違っていた。 これは悪いバグであり、堅牢な画像署名が優れたアイデアである理由の優れた証拠です。 ただし、悪用は簡単ではありません。近くの誰かが安全でないWiFi経由でDockerを使用することを期待して、アクティブな攻撃者がスターバックスにたむろする必要があります。 これは一夜にして兵器化されることはありません-したがって、警告なしに後方互換性のない変更に値することはありません。

上で示唆したように、互換性を損なうことなくセキュリティを即座に改善する明白な方法がありました。 たとえば、index.docker.ioやその他の人気のあるパブリックレジストリのHTTPSフォールバックを無効にすると、ほとんどのユーザーの問題が効果的に解決されます。 HTTPフォールバックが発生しているという警告をコンソール出力に追加すると、対話型のケースが軽減されます。 HTTPフォールバックは非推奨としてマークされ、たとえば来月のリリースで削除されます。 最後に、localhostと:: 1は明らかに脆弱ではありません。

繰り返しになりますが、脆弱性の範囲を軽視するべきではありませんでしたが、対応プロセスと修正が顧客を壊さないことに十分な価値をもたらさなかったのではないかと心配しています。

現在、Dockerレジストリを動的に作成/破棄しているのは、これらのインスタンスの多くで利用可能なFQDNがない環境です。 （リモートAPIを介して）レジストリ関連のリクエストに対して--insecure-repositoryオプションをサポートすると、このセキュリティ修正によって作成された重大な問題が解消されます。

Docker1.3.1でも同様の問題があります。 アドレスhttp：// docker ：5000 /でローカル（プライベート）Dockerレジストリを使用します。 Docker 1.3.0までは、問題なく動作していました。 Dockerバージョン1.3.1では、DockerクライアントはレジストリがHTTPSで到達可能であると自動的に想定するため、機能しなくなりました。 ただし、HTTPSはまったく使用していません。

DockerレジストリサーバーにHTTPS経由でアクセスできない場合は、HTTPを使用するフォールバックメカニズムを実装すると便利です。

@kruxikデーモンの起動時に--insecure-registry docker:5000を使用すると、HTTPにフォールバックします。

@tiborvass提案ありがとうございます。 あなたは正しいです。 しかし、ワークステーションやノートブックを持っている開発者がたくさんいる場合、各ステーションに--insecure-registryを設定するのは現実的ではありません。 少なくとも、プル/プッシュ操作のオプションのパラメーターとしては十分です;）

+1

これは1.3.0で機能しましたが、1.3.1では機能しました

Dockerバージョン
...。
サーバーバージョン：1.3.1
...。
docker push 10.121.4.236：5000 / debian7 / consul
-> ....このプライベートレジストリが不明なCA証明書を持つHTTPまたはHTTPSのみをサポートしている場合は、デーモンの引数に--insecure-registry 10.121.4.236:5000を追加してください。 HTTPSの場合、レジストリのCA証明書にアクセスできる場合は、フラグは必要ありません。 CA証明書をに配置するだけです

ダウングレード
サーバーバージョン：1.3.0
docker push 10.121.4.236：5000 / debian7 / consul
->問題なくコンテナをアップロードします。

1.3.0から1.3.1で問題が発生している他の人のために、boot2dockerを使用してOSXに対して次の変更を加える必要がありました。

$ boot2docker delete #removes old image
$ rm -f ~/.ssh/id_boot2docker* # remove old keys
$ boot2docker init #generates new keys, cert
$ boot2docker up
$ boot2docker ssh
$ # add EXTRA_ARGS="--insecure-registry <YOUR INSECURE HOST>" 
$ # to /var/lib/boot2docker/profile
$ sudo /etc/init.d/docker restart

そうすれば、Dockerプルを実行できるはずです。

figを使用する場合は、Fig1.0.1も必要です。

$ fig up --allow-insecure-ssl

@mhamrahありがとう！ これを修正しようとして何時間も費やしました...

ローカルホストが安全であると仮定することへの+1。 誰かが実際にこれに反対していますか？

ええ、ローカルホストが安全であると仮定すると、大いに役立ちます。 Dockerボックスにvagrantを使用しているので、ボックスを破棄または起動するたびにinitスクリプトを更新するのは非効率的です。 浮浪者のinitを変更できるように、Dockerボックスを操り人形にする必要があると思います。

また、プルとプッシュで--insecureフラグを使用すると、必要に応じてvagrant boxIPを使用できるので便利です。

@thocking ：ローカルホストが安全であると仮定したhttps ： ください

正直なところ、自動化されたJenkinsContainerbuildsがプッシュに失敗した理由も疑問に思っていました...
（本番環境に移行する前にtestenv。を用意しておくとよいでしょう）。
この「機能」が本当に発表されたかどうかを確認する必要があります。発表されていない場合は、デーモンの動作の極端な大規模な変更についてより偏執的になります。

この議論で私が見逃していること：
ホストごとに「デフォルト」のセキュア/非セキュアモードを使用するようにデーモンに指示する必要があるのはなぜですか？

このデフォルトの動作でレジストリを設定する方が生産的ではないでしょうか。
したがって、セットアップに応じて、-secureまたは--insecureパラメータが指定されていない場合、デーモンは要求する必要があります
安全な方法が可能であり、そうでない場合は、安全でないものへのフォールバックが使用されました。

dockerの主な機能の1つは、完全に使いやすく、完全な環境をセットアップできることです。 このような「リリース/決定」でこのWOW効果を殺さないでください...

ちょうど私の2セント...

@jwthompを含む上記の問題と同様の問題がここにあります。 私はこの問題を解決するために10時間以上を費やしましたが、その間にdocker1.3.0にダウングレードしました。

私はMarathonでdockerレジストリを実行しており、dockerレジストリは現在「nginxをフロントエンドとして実行することでSSLをサポート」しています（https://github.com/docker/docker-registry/issues/697を参照）が、nginxをフロントエンドとして使用するのはさまざまなスレーブホスト/ポートでDockerレジストリを実行するMarathonによって複雑になります。

（GUNICORN_OPTSを使用して）レジストリ内でSSLを直接有効にすることはできますが、SSLを話すだけで、Marathonヘルスチェックに合格できません。

Bamboo HAProxy構成システムを変更して、nginxと同じようにHAProxyをすべてのサービスのhttpsフロントエンドとして構成しましたが、Dockerがプライベートレジストリで証明書を検証する際に問題が発生するため、それでも問題は解決しません。この時私。

RCEから保護することはすべて非常にうまくいきますが、下位互換性も必要です。 少なくとも、すべてのレジストリを安全でないものとして指定するためのdockerデーモンのフラグ。 各dockerpullコマンドのレジストリ名の一部としてhttpまたはhttpsを指定する方法が必要です。 現時点では、1.3.1はプライベートレジストリを使用している人にとっては大きなキャッチ22のようです。

@mhamrah https://github.com/boot2docker/boot2docker/pull/630

良い。
10:42イリヤRadchenkoで金、2014年11月14日には[email protected]
書きました：

@mhamrah https://github.com/mhamrah boot2docker / boot2docker＃630
https://github.com/boot2docker/boot2docker/pull/630

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/8887#issuecomment-63082089 。

@mhamrah sshキーなどを削除する必要はありませんでした。必要な行を/ var / lib / boot2docker / profileに追加し、dockerを再起動しました。 ヒントをありがとう！

いいね。 sshすることさえ問題がありました、私はいくつかのバージョンのために推測します
DockerISO間の不一致。 私は実際にvagrant +の使用に切り替えました
Dockerサポート用のcoreosであり、うまく機能します。 設定する必要があります
boot2dockerが自動的に行うDOCKER_HOST。

午前1時52分21秒AM Kayvanシルバンの木2014年11月20日には[email protected]
書きました：

@mhamrahhttps ：//github.com/mhamrahの削除を行う必要はありませんでした
sshキーなど。必要な行をに追加しました。
/ var / lib / boot2docker / profileと再起動されたdocker。 ヒントをありがとう！

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/8887#issuecomment-63768043 。

申し訳ありませんが、私は早く応答するつもりでした。

@ewindischがすでに述べたように、このクライアント側の動作を奨励したくありません。 デーモンフラグとしてフラグを要求することによって引き起こされる苦痛は、人々が実際にレジストリにTLSを設定することです。 そうでなければ、インセンティブはありません。 わかってくれてありがとう。

公式のDockerレジストリには、Dockerレジストリの「公式の」Dockerベースのイメージがあります。 TLSなしでの使用をお勧めします。

DockerがユーザーにレジストリにTLSを設定することを希望する場合、デフォルトでTLSを提供する公式のDockerイメージを

@tiborvass 。 内部のファイアウォールの背後にある開発ケースを無視しています。 そのため、レジストリの前でSSLを有効にしてリバースプロキシを設定するか（これを行う理由はまったくありません）、開発者全員にアクセスして、実行中のデーモンの引数を変更する必要があります。 boot2docker内。 これは意味がありません。 構成可能なセキュリティを提供する多くの開発環境があり、開発環境ではセキュリティが無効になっていることがよくあります。 解決策への投票が非常に多いときに、この問題を解決するのを見て驚いています。

すべてのプライベートIPをホワイトリストに登録するのはどうですか？ 中途半端？

または、プロトコル名、「http」または「https」をプルのイメージ名の一部にします。

@tiborvass @sroebuckと@blevineの両方が大きなポイントを作ります。 これは、社内でコンテナを構築するショップのシナリオになり、以前のワークフローを破ることへの怒りも高まります。 私たちは皆、これのセキュリティ面を理解しており、プルはそれを解決するための適切な場所ではないかもしれませんが、公式のレジストリイメージがこの変更に対処するための簡単な、すぐに使える方法を提供しない限り、それはすべきです解決すべき非常に重要なUXの問題と見なされます。

ねえ@tiborvass ！ この問題は今も私たちを悩ませています。 @nickandrewのアプローチが好き

@blevineは、1.3.2の時点で、 localhostがデフォルトでホワイトリストに登録されていることに注意してください。https ： ください。

-p 127.0.0.0:5000:5000をdocker run渡すことで、レジストリをローカルホストでリッスンさせることができます。

@proppy 、ローカルホストでリッスンすることがどのように役立つかはよくわかりません。

docker pull {http}myregistry.domain.com/myapp:latest

それとも実際のURLにする必要がありますか？ レジストリプロトコルについては何も知りませんが、現在の構文を拡張して適切なURLを指定することには互換性がないようです。

@blevineは、ローカルミラーリングレジストリを設定できることを意味します。

Arg、マシンを起動するには、coreosのcloud-configをbase64でデコードする必要があります

@tiborvassうわー、これは本当に残念です。 :(

その場で起動および停止する開発クラスターがあり、これらのクラスターを処理する方法の一部は、そのクラスターのレジストリを作成することです。 クラスターは、多くの物理ノードまたはVMである可能性があり、開発者のデスクトップマシンまたはラップトップ上にある可能性もあります（ただし、通常、フルスタックを起動することはできません）。 各クラスターは、完全に自己完結型のスタックおよび開発環境です。 また、開発者が社内の開発クラスター設定と対話できるようにするDockerベースのコマンドラインツールもあります。

この種の複雑で動的な環境では、レジストリでTLSを要件にすることは非常に困難です。 セットアップするたびにdockerデーモンの起動を変更する必要があり、レジストリが存在する可能性のある新しいネットワークを追加することも同様に面倒です。

誤解しないでください。TLSを排他的にサポートしたいという考えに感謝しますが、サポートに必要な痛みとインフラストラクチャを軽減するために、環境がTLSの複雑さの除去を安全にサポートする有効なケースがあることを考慮してください。それ。

@ tiborvass + 1。 +1000。 これは絶対に不必要な複雑さを生み出しました
非常に動的な開発ワークフローに私たちを。 参入障壁は
ここで大幅に引き上げられたのは、
プロダクションコンテキスト。 私たちの痛みを終わらせてください。

2014年12月9日（火曜日）には、ジェフ・トンプソン[email protected]
書きました：

@tiborvass https://github.com/tiborvassうわー、これはそれらの1つです
悲しいことに、仮想テーブルの反転の瞬間。 :(

私たちはその場で上下する開発クラスターを持っています
これらのクラスターを処理する方法の1つは、そのクラスターのレジストリを作成することです。 NS
クラスターは、多くの物理ノードまたはVMである可能性があり、
開発者のデスクトップマシンまたはラップトップ（通常、起動することはできませんが
フルスタック）。 各クラスターは完全に自己完結型のスタックと開発です
環境。 Dockerベースのコマンドラインツールもあります。
開発者は、社内の開発クラスター設定と対話します。

この種の複雑で動的な環境では、レジストリでTLSを作成します
要件は巨大な痛みです。 Dockerデーモンの起動を変更する必要がある
セットアップするたびに、レジストリが存在する可能性のある新しいネットワークを追加します。
同様に痛み。

誤解しないでください、私はサポートしたいという背後にある考えに感謝します
TLS、ただし、環境が安全に削除をサポートしている場合があります
必要な痛みとインフラストラクチャを削減するためのTLSの複雑さ
それをサポートします。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/8887#issuecomment-66367681 。

@justinclayton @jwthomp @mattwilliamson @nickandrew @blevine

--insecure-registry 0.0.0.0/8あなたの問題を解決しませんか？ そうすれば、引き続きHTTPを使用できます。

このCIDR表記は、「-insecure-registry 172.16.0.0/12」などの範囲を指定することにより、「ファイアウォールの背後」構成を有効にするために、よりきめ細かく使用できます。 このオプションを使用することはまったくお勧めしませんが、0.0.0.0 / 8のすべてのアドレスではなく、より選択的な範囲（IPスペースなど）を使用するようにこのオプションを選択することをお勧めします。

dockerデーモンはcoreosに組み込まれているため、クラスター全体のスタートアップにこれらのフラグを追加する必要があります。 dockerデーモン自体を制御できない環境では、pullコマンドで使用する方がはるかに柔軟だと思います。

これは、共有phpホストのphp.iniファイルを変更するように指示するのと同じです。

2014年12月9日には、22：18で、ティボーヴァースの[email protected]は書きました：

@justinclayton @jwthomp @mattwilliamson @nickandrew @blevine

--insecure-registry 0.0.0.0/8は問題を解決しませんか？ そうすれば、引き続きHTTPを使用できます。

—
このメールに直接返信するか、GitHubで表示してください。

@mattwilliamson実行フラグはCoreOSで構成できます。 Dockerのsystemd構成ファイルを編集できます。 これをクラスター用に構成するには、cloud-configを使用できます。

Docker構成の変更例は、CoreOSWebサイトにあります。 命令を簡単に変更してデバッグフラグを追加し、代わりに安全でないレジストリフラグを指定することができます。

https://coreos.com/docs/launching-containers/building/customizing-docker/

@tiborvass構成エコシステム全体が、箱から出して簡単に機能するためにこれをサポートする必要があります。 人々は、独自の内部レジストリを設定するステップに移行するときに、プルする可能性のあるすべての場所（boot2docker、coreos、chef / puppetモジュールとともにインストールされるものなど）に非標準のカスタマイズを行うことを期待していません。 readmeで「推奨」とマークされた手順を使用すると、公式のレジストリコンテナイメージ自体が_機能しなくなります_。 実際、ReadmeではTLSについては何も言及されておらず、これを設定することは簡単なプロセスではありません。 さらに、 @ mattwilliamsonが前述したように、共有ビルド環境のように、デーモンを使用してイメージをプルする人がデーモンを構成する人と同じではない場合が無数にあります。

肝心なのは、これをクライアント側の議論にすることは、明らかに混乱の少ない解決策であり、さらに重要なことに、より規範的な解決策ではないということです。 Dockerは、他の数百とは言わないまでも数十のプロジェクトやワークフローですでにプリミティブになっているため、このスコープでの使用パターンを実際に指示するべきではありません。 Gitがhttp.sslverifyを無効にする簡単なランタイム構成オプションを提供しているからといって、LinusTorvaldsが重要なコンテキストで機密データを保護しないように人々に勧めているわけではありません。

gitの例えは、これがどのように機能するかを示す良い例です。 GitはTLSの使用を強制するものではなく、ホストをセットアップするときにサポートするレベルをユーザーが決定します。 また、必要な（またはバイパスしたい）セキュリティのレベルを引き出すときのユーザーの決定でもあります。 構成は、グローバルまたはリポジトリごとの簡単な手順です。 DockerはTLSの使用を強制しませんが、代替手段を重要にすることにより、他の合理的なオプションを提供しません。

CIDR表記では、ほぼ間違いなく「ヘビーハンマー」アプローチが可能であり、AFAIKはDNS名にマップされないため、10.0.0.0 / 16をマスクしても、some.private-registry.comを10.0 / 16ウォンでプルします。動作します。 さらに重要なことに、構成は簡単ではありません。

Dockerは、コンテナー化の単純さで成長し、さまざまな環境でアプリケーションをデプロイする際の障壁を大幅に下げます。 私たちは皆、その利点を知っています。 ほとんどの開発者は単純なCIDR表記の質問に答えることができず、docker構成ファイルが非標準の場所にある可能性があり（boot2dockerとCoreOSの場所は両方とも他のディストリビューションとは異なります）、これらの構成ファイルを難しいフィードバックループで混乱させるのはかなり簡単です。成功。 Syslogを調整する必要がありますか？ ああ、私がRHELにいるのを待って、それはメッセージですか？

新しい開発者はdocker pullスニペットを簡単にコピーして貼り付けることができますが、それらをboot2dockerホストにSSHで接続し、viを実行し、構成ファイルを編集してから、syslogでエラーを追跡します...それほど多くはありません。 そして、そうそう、あなたはdockerデーモンを再起動するのを忘れました。

これが私が見たいものです：

• dockerコマンドを介して適用されるDockerデーモン設定
• dockerコマンドで指定されたTLSオーバーライドのDockerプル設定
• 特定のレジストリのコマンド間で保持されるDockerプル設定

ええ、でもアマゾンではautoscscaleの設定を変更することはできません。 私はそれのコピーを作成するか、まったく新しいものを作成する必要があります。

2014年12月9日には、23時55分で、エリックWindischの[email protected]は書きました：

実行フラグはCoreOSで構成できます。 Dockerのsystemd構成ファイルを編集できます。 これをクラスター用に構成するには、cloud-configを使用できます。

Docker構成の変更例は、CoreOSWebサイトにあります。 命令を簡単に変更してデバッグフラグを追加し、代わりに安全でないレジストリフラグを指定することができます。

https://coreos.com/docs/launching-containers/building/customizing-docker/

—
このメールに直接返信するか、GitHubで表示してください。

私は現在、「boot2docker up」を実行するたびに、この入念に調査されたコマンドを実行することにより、会社の開発環境でこの問題を回避する必要があります。

boot2docker ssh 'sudo sh -c "echo \"EXTRA_ARGS=\\\"--insecure-registry 10.0.0.0/8\\\"\" > /var/lib/boot2docker/profile && sudo /etc/init.d/docker restart"'

なんて痛い。 この問題が原因で、400人以上の会社でのDockerの採用が停滞しています。 すべてが制御されている内部開発環境では、TLSをまったく使用していません。 私たちは、パブリックハブリポジトリでの使用を称賛し、すべての場合において他の場所にそれを強制することは大きな間違いであると考えています。

@CleanCutは非常にうまくいっています。 1.4.0が出入りし、この問題が未解決のままであることに本当に失望しました。

@CleanCut awesome- boot2docker init初期ペイロードにさらに情報を追加してもらうことです。これにより、これが自動的に行われます。

vm-based-boot2docker以外の特定の問題は解決しませんが、b2dユーザーが望むサイト固有のカスタマイズは--insecure-registryだけではありません。

boo2dockerリポジトリでプルリクエストまたはこれを発行できますか？

障壁を下げることで称賛されたプロジェクトを誰かが使用するための障壁を本当に上げます。

2014年12月13日には、2：10で、ジャスティン・クレイトン[email protected]は書きました：

@CleanCutは非常にうまくいっています。 1.4.0が出入りし、この問題が未解決のままであることに本当に失望しました。

—
このメールに直接返信するか、GitHubで表示してください。

@SvenDowideitもちろんです。 ここにあります

このスレッドには、これは解決された問題ではないというコンセンサスがあるようです。 この問題を再開してもらえますか？

はい、お願いします！
Le 2014-12-15 15:05、「ジャスティンクレイトン」 [email protected]écrit ：

このスレッドには、これは解決されていないというコンセンサスがあるようです。
問題; この問題を再開してもらえますか？

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/8887#issuecomment-67055878 。

+1。 追加するものは何もありませんが、この決定に対する不満を解消したいと思います。 他のみんなと同じように、私はローカルネットワーク上でレジストリを実行しています。ローカルネットワークでは、セキュリティが他の場所で悪意を持って処理されています。 数十のDockerコンテナを実行していますが、「十分に文書化された」フラグを追加するためにバウンスする必要があります。

@ bfirsh-これは、Dockerデーモン構成ファイルとkill -HUP <dockerdaemonpid>が素晴らしい例の1つです-再起動せずにcfgを再読み取りするようにトリガーします-したがって、コンテナーの再起動を回避します

リロード機能の@ SvenDowideit + 1、単純な構成でサーバーを再起動するのは本当に面倒です。

+1

私が物事を正しく理解していない場合は許してください、しかしこの問題は私自身のシナリオの根源にあるようです（私の会社が証明書書き換えプロキシを持っている@blevineによって概説されたものと同様に私はできませんパブリックDockerHubレジストリに話しかけることもできます）。 最終的には自分のプライベートレジストリを設定したいと思うことはわかっていますが、まだ学習段階にあり、Dockerを採用するかどうかはまだわかりません。 これは、採用の初期段階にいる人にとってはUXの悪夢です。

http://stackoverflow.com/questions/27536180/docker-on-mac-behind-proxy-that-c​​hanges-ssl-certificate

コミュニティは現在のソリューションに本当に満足していないように見えるため、このディスカッションを再開するには+1します。

https://twitter.com/justinclayton42/status/550143834705780737

このトピックに関する決定的な答えが聞こえるまで、あらゆる角度からこれを打とうとしています。

+1、これは現在、構成して機能させるのが困難です。

@mhamrahは素晴らしいポイントを作ります。 物事を強制するのではなく、ユーザーが自分のニーズに合わせて決定および構成できるようにします。

自己署名証明書を使用するレジストリも、特に問題です。
読み取り専用ファイルに切り替えたboot2dockerを使用する開発者のコ​​ンテキストで
システム。 これには、追加の異なる構成手順が必要です。
実行中のVMをブートストラップします。

このスレッドに投稿されたすべての人が価値と利益を理解していると思います
Dockerの、毎日それを使用している、彼らの中でそれを宣伝しようとしています
組織が、痛みを伴う不必要な問題を経験しています
養子縁組を妨げる。

私たち全員がdockerを知っている限り、それはまだ多くの技術者には知られていません。
特に企業内で。 ドキュメントは役に立ちますが、私たちはまだです
フープを飛び越えて、それは全体的にネガティブな大きなブロッカーです
効果。
日には、2015年1月25日17:54ジェイ・テイラーの[email protected]は書きました：

+1、これは現在、構成して機能させるのが困難です。

@mhamrahhttps ：//github.com/mhamrahは素晴らしいポイントを示しています。 強制しないでください
物事は、ユーザーが自分のニーズに合わせて決定および構成できるようにします。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/8887#issuecomment-71398193 。

+1はすぐに試すのに適しています

：+1：

：+1：

Dockerデーモンにフラグを渡さないと、安全でないレジストリからプルできないことは非常に残念です。 これは、私たちが展開するすべての新しいマシンにとって、もう1つの面倒です。

+1

いくつかの考え：

1. ホスト名のワイルドカードを使用できますか？ 例： --insecure-registry=*.internal
2. 自己署名証明書はhttpとは異なる方法で処理できますか？
3. 2に関連して、dockerはSSHと同様のことを行い、新しい証明書を見つけたときはいつでも自己署名証明書を受け入れるようにユーザーに促し、不一致の証明書がある場合は大声で文句を言うことができますか？

そして、私が提案をしている間、ローカルホストを常に安全であるとして扱ってみませんか？ （Chromeのように）

編集：ああ、私はそれがすでにあると思います。

これで+1000 ..そして構成のリロード機能で+1、それがこれを2倍悪くしている理由です。 デーモンの--insecure-registryフラグが展開と修正にどれほど煩わしいかをメンテナが理解するだろうと確信したので、v1.2を使い続けましたが、どういうわけかマイナーリリースはそれを無視し続けます。

たとえば、なんらかの理由でプライベートレジストリIPを変更する必要がある場合、レジストリが変更されたという理由だけで、すべてのVMですべてのDockerデーモンを再起動する必要があります。 これらの2つのことは、それほど緊密に結合されるべきではありません。 そして、0.0.0.0 / 8を追加するように人々に指示すると、そもそもセキュリティ実装の目的全体が無効になります。

このフラグをpush / pullコマンドに追加することは、デーモンフラグのフォールバックとして非常に明白なようです。誰かがまだそれと戦っている理由を説明してください。ただし、その間に「便利な」機能を追加してください。

@agquickのコメントは、特に「持っていてよかった」機能にスポットを当てています。

これはかなりの数のユーザーにとって継続的な苦痛であることに気づき、 pull --insecureを追加することを再検討しています。 @ewindischと私はこの問題にリンクするPRに取り組んでいます。

長い間お詫び申し上げます。ご意見をお聞かせいただき、問題点を指摘していただきありがとうございます。

@tiborvass安全でないレジストリからのプルを許可したくないユーザーも同様に多数いると想像できます。 Dockerは現在、アクセス許可/構成をきめ細かく制御できないことを認識していますが、これを「ロック」できる可能性がある場合は、それはいい感じだと思います。

ああ、そうだ！ 自分で実装しようとしていました。

Bellネットワーク上のBlackBerry10スマートフォンから送信されました。
差出人：Sebastiaan van Stijn
送信：2015年2月23日月曜日16:53
宛先：docker / docker
返信先：docker / docker
Cc：クリストファーシープラク
件名：Re：[docker] --insecure-registryは「dockerpull」（＃8887）にある必要があります

@tibor vasshttps：//github.com/tiborvass安全でないレジストリからのプルを許可したくないユーザーが同じくらい多いと想像できます。 Dockerは現在、アクセス許可/構成をきめ細かく制御できないことを認識していますが、これを「ロック」できる可能性がある場合は、それはいい感じだと思います。

—
このメールに直接返信するか、Gi tHubhttps：//github.com/docker/docker/issues/8887#issuecomment-75644600で表示してください。

@thaJeztah私はあなたが考えているユースケースを理解しようとしています。つまり、 --insecure-registryフラグをdocker pullすることはできません。

• ユーザーが誤って安全なレジストリでMITMされたくない場合は、 --insecure-registryを渡さないようにすることができます。
• ユーザーがすべての画像が安全なレジストリからのものであることをユーザーに強制したい場合（つまり、「エンタープライズ」シナリオ）、とにかく現時点では実際にはこれを強制することはできません。

では、 docker pull --insecure-registry何を阻害するのか詳しく説明していただけますか？

2つ目のポイントを詳しく説明すると、Dockerの動作をかなり再考せずに、これをどのようにロックするかがわかりません。 独自のレジストリプラーを作成し、 docker run -vを使用してprivをエスカレーションし、デーモン引数に何かを追加することで取得できるtarballをdocker loadできることは別として、 '執行'：

$ docker pull registry:5000/aidanhs/blah                                    
FATA[0004] Error: v1 ping attempt failed with error: Get https://registry:5000/v1/_ping: EOF. If this private registry supports only HTTP or HTTPS [...]
$ socat tcp4-listen:5000,reuseaddr,fork tcp4:registry:5000 &
[1] 22924
$ docker pull localhost:5000/aidanhs/blah
Pulling repository localhost:5000/aidanhs/blah
[...]
Status: Image is up to date for localhost:5000/aidanhs/blah:latest
$ docker tag localhost:5000/aidanhs/blah registry:5000/aidanhs/blah

ユーザーがすべての画像が安全なレジストリからのものであることをユーザーに強制したい場合（つまり、「エンタープライズ」シナリオ）、とにかく現時点では実際にはこれを強制することはできません。

はい、これがシナリオです。

2つ目のポイントを詳しく説明すると、Dockerの動作のかなりの量を再考せずに、これをどのようにロックするかがわかりません。

私は（現時点では）それをロックする方法がないことを完全に理解しています。 docker.sockアクセスできるユーザーは、事実上rootアクセス権を持っているため、好きなように変更できます。 また、デーモンフラグを変更して、デーモンを再起動することもできます。

ただし、 docker pull --insecure-registry ..でエラーが発生した場合（「安全でないレジストリが無効になっています」）、ユーザーに明確なシグナルが送信されます。エラーは、たとえば、ユーザーが見つけた例を試したときに、望ましくないことをユーザーに通知します。どこか。

それで、それはすべての場合をカバーしますか？ いいえ、それは_痛い_でしょうか、私もそうは思いません。

個人的には、実際には非常に表面的な保護であるにもかかわらず、「ああ、dockerはこれを強制する」と人々に誤解させるため、それは良いことよりも害を及ぼすと感じています。 先に進むこともできますが、結局は好みの問題だと思います。

それがどのように傷つくかを探しているなら、ただ上にスクロールしてください。 このアプローチには、採用の障壁となるUXの問題が無数にあり、それらはすべて上記で詳しく説明されています。

私は主にサブを殺さずに再起動できないdockerの問題を表示します
コンテナ。 そのため、構成/再構成がはるかに困難になります。

8時11分PMに水、2015年4月15日には、ヤン・クルーガー[email protected]
書きました：

+1

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/8887#issuecomment-93362359 。

この問題に対してまだ何らかの措置が講じられていないことに、私はかなり失望しています。 それは明らかに多くの人々の痛みを引き起こしています。

それは明らかに多くの人々にとって迷惑であり、現在私の仕事を積極的に妨げています。 安全でないレジストリからのプルを許可するためにDockerデーモンを再起動する必要があるのは、状況に応じて、煩わしいものからまったく不可能なものまでさまざまです。

これを行わないことの主な議論は、システム管理者がシステムをロックダウンし、安全なリポジトリからのイメージのみをプルできるようにする必要があるということのようです。 そのユースケースは間違いなく現実的ですが、それは悪いデフォルトになると思います。 のような起動時にデーモンに渡すことができるフラグ持っているより多くの合理的なようだ--no-insecure無効にする--insecure-registryでの使用をpull 。 そうすれば、管理者は本当に必要な場合に物事をロックダウンできます。

この動作を強く望んでいる人のために、私は以下の回避策を提供します。 プルにDockerAPIを使用しないため、すべてのユーザーが実行できるわけではないことを理解しています。 それもやや遅いです...

私のプロジェクト「docker-pull」を参照してください： https ：

あなたはそれをそのように使うでしょう：

docker run ewindisch/docker-pull --insecure-registry 10.0.0.0/16 10.0.1.2/someimage | docker load

すべてのレジストリを安全でないものとして許可することも可能です。

docker run ewindisch/docker-pull --insecure 10.0.1.2/someimage | docker load

実際にこれを行うことは_まだ_非常に賢明ではないことを思い出します。

@ewindisch気の利いたハック。

もう1つの非常に優れた解決策は、tcpトンネルを使用することです。

$ docker pull host:5000/image #fails
$ ssh -N -L 5000:host:5000 user<strong i="8">@host</strong>
$ docker pull localhost:5000/image #works

これらは両方とも素晴らしい回避策です！

私もデフォルトを逆にしたいと思います。

2015年4月15日には、18:14で、ジョーDolinerの[email protected]は書きました：

この問題に対してまだ何らかの措置が講じられていないことに、私はかなり失望しています。 それは明らかに多くの人々の痛みを引き起こしています。

それは明らかに多くの人々にとって迷惑であり、現在私の仕事を積極的に妨げています。 安全でないレジストリからのプルを許可するためにDockerデーモンを再起動する必要があるのは、状況に応じて、煩わしいものからまったく不可能なものまでさまざまです。

これを行わないことの主な議論は、システム管理者がシステムをロックダウンし、安全なリポジトリからのイメージのみをプルできるようにする必要があるということのようです。 そのユースケースは間違いなく現実的ですが、それは悪いデフォルトになると思います。 プルでの--insecure-registryの使用を無効にする--no-insecureのように、起動時にデーモンに渡すことができるフラグを設定する方がはるかに合理的と思われます。 そうすれば、管理者は本当に必要な場合に物事をロックダウンできます。

—
このメールに直接返信するか、GitHubで表示してください。

したがって、これは再開され、4か月後の現在のステータスは何もありません。回避策として、多数のハックを使用しますか？ ：-/これが他の場所で起こっていることについての議論はありますか、それともただ死んでいますか？

はい、+ 1

+1

+1

このページで「+1」のインスタンスを数えましたが、これまでのところ31になっていることを指摘しておきます。 それは、実際にはその正確な文字列を含まない他の支持的なコメントを数えていません。

ここでの問題は、プルで--insecureを有効にすると、それが属するsysadminからコントロールが奪われることです。
セキュリティは難しいものであり、セキュリティを緩めるために変更を加えることは簡単な決断ではありません。
また、現在の設定に完全に満足している人はここに来ることはなく、これも-1です。
一方で...
レジストリからの安全でないプルを有効にするためにデーモンを再構成するのは簡単です。
いくつかの自己署名証明書をセットアップすることも簡単であり、dockerを再構成する必要さえありません。

「Sysadmin」はdockerの1つのユースケースですが、私は「developer」と「non-sysadmin」も同様に有効なユースケースです。 開発者にとって、 --insecureオプションを提供すると、ワークフローの摩擦が軽減されます。

おそらく、システム管理者が--insecureオプションの使用を_拒否_するように指定できるオプションを提供することで、両方の長所を活かすことができます。 そうすれば、システム管理者は引き続き完全に制御できますが、システム管理者以外の場合はワークフローの問題に対処する必要はありません。

システム管理者にとって些細なことは、非システム管理者にとっては驚くほど面倒な場合があります。 私は、開発グループで使用されている5つの異なるOS間で、約20人の開発者がこの構成変更を行う（および再作成する）のを支援する必要がありました。 私は実際に、環境の構成変更を自動化するスクリプトを維持しています。

私たちのシステム管理者は、それが簡単であるかどうかにかかわらず、現在、私たちのレジストリに自己署名証明書を設定しません。

とにかく、これが変わらなくても、最終的には人々はそれらに適応するでしょう。 次回システム管理者がレジストリのメンテナンスを行うときに、実際のSSL証明書をインストールできるようになるはずなので、私が扱っている問題はすべて解消されると思います。 おそらくそれが要点です。 今後の安全でないパスよりも安全なパスを使用しやすくします。

：+1： @CleanCut 、そして他のみんながそれをすべて言った。 私は開発者のケースでのみ作業し、dockerデーモンを再構成することは私たちにとって時間の無駄です。

今日、Dockerソケットにアクセスできる場合は、システム管理者です。 あなたは
ルートはすでに「dockerload」があり、回避策がすでにあります
安全でないレジストリプル。 クライアントに画像オプションを追加することはありません
現状よりも安全性が低い。

ただし、意図的に増加させることについては、言いたいことがあります。
誘惑するために他の人に間違ったことをしようとしている開発者のための摩擦
彼らは正しいことをするようになります。
2015年6月18日12:41 PM、「BrianGoff」 [email protected]は次のように書いています。

ここでの問題は、プル時に--insecureを有効にすると、制御が失われることです。
それが属するシステム管理者から。
セキュリティは難しく、セキュリティを緩めるために変更を加えることは少なくありません
決断。
また、現在の設定に完全に満足している人は行きません
ここに来て、これも-1です。
一方で...
デーモンを再構成して、からの安全でないプルを有効にするのは簡単です。
レジストリ。
いくつかの自己署名証明書を設定することも簡単であり、設定する必要さえありません
Dockerを再構成します。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/8887#issuecomment-113213172 。

@ewindisch @tiborvassを読み返すと、 https： //github.com/docker/docker/issues/8887#issuecomment-75638745が表示され

これはかなりの数のユーザーにとって継続的な苦痛であることに気づき、プルするために--insecureを追加することを再検討しています。 @ewindischと私はこの問題にリンクするPRに取り組んでいます。
長い間お詫び申し上げます。ご意見をお聞かせいただき、問題点を指摘していただきありがとうございます。

それはまだ現在の位置ですか？ （PRが作成されたとは思いません）

+1

これは私を日常的に悩ませ、苛立たせ続けています。

:(悲しいコーンヘッド。

--inscureは、開発者のPOVから完全に理にかなっています。 それを安全にするために彼らの環境にdockerを実装する人にそれは。

+1

：+1：

_USER POLL_

_このディスカッションに変更があったときに通知を受け取る最良の方法は、右上の[購読]ボタンをクリックすることです。_

以下にリストされている人々は、ランダムな+1であなたの有意義な議論に感謝しています：

@justinclayton
@anandkumarpatel
@ tangr1
@ fred4jupiter
@mingfang
@djannot
@Frusty
@ tobegit3hub
@testaccountspivey
@mhamrah
@mwhooker
@ ryan-ステートレス
@jonathanvaughn
@gollawil
@ebartz
@maelp

+1

+1

+1

閉じたネットワークで内部レジストリを使用します。これを追加すると、展開が容易になります。

+1

この問題がハロウィーンまでにまだ開かれている場合は、すべての+1で1年間の港湾労働者の悲しみに溺れる記念パーティーを開く必要があると思います。

悲しみのパーティーに+1！

2015年9月14日には、13:32で、ゴードン[email protected]は書きました：

ユーザー投票

このディスカッションに変更があったときに通知を受け取る最良の方法は、右上の[購読]ボタンをクリックすることです。

以下にリストされている人々は、ランダムな+1であなたの有意義な議論に感謝しています：

@justinclayton
@anandkumarpatel
@ tangr1
@ fred4jupiter
@mingfang
@djannot
@Frusty
@ tobegit3hub
@testaccountspivey
@mhamrah
@mwhooker
@ ryan-ステートレス
@jonathanvaughn
@gollawil
@ebartz
@maelp

—
このメールに直接返信するか、GitHubで表示してください。

+1

悲しみのパーティーのための+1

「+1」の使用をやめるように指示するボットの所有者の皆様：
+1を使用して処理しますが、これ以上言うことはありません。

+1

+1

SSHトンネルの使用など、いくつかの回避策がありますが、それにはレジストリホストにsshアカウントが必要です。 次の回避策は、それを必要としません。

次のように、レジストリポートフォワーダを実行します。

docker run --name registry_forwarder -d -p 5000:5000 -e REGISTRY_HOST="<registry_host_ip>" -e REGISTRY_PORT="5000" rsmoorthy/registry-forwarder

次に、ローカルレジストリからイメージをプルまたはプッシュします。

docker pull localhost:5000/your-image
docker push localhost:5000/my-image

@rsmoorthyそれは素晴らしいです。 この現在の制限の無益さを簡潔に示してくれてありがとう。

Docker、この特定のバッテリーを再度含めてください。

+1

ユーザーのセキュリティを強制的に奨励することで、dockerの使用に関する私の考えが大きく揺らいでいると言わざるを得ません。 起動時にデーモンに--insecure-registryフラグを追加できることを完全に理解しています。また、常に機能しない、または不可能な理由をすべて説明することはできません。

Docker開発者に質問がありますが、エンドユーザーにとって何が最善か知っていると本当に思いますか？ レジストリが実行されているネットワークはすでに完全に暗号化されているため、私はレジストリにSSLをまったく必要としません。 では、なぜ私は暗号化されたトラフィックを暗号化するのでしょうか？これは、オーバーヘッドを追加し、すでに複雑で大規模なシステムにピースを移動する以外に、本当に何かをしているのでしょうか？

また、人々がインターネットを介してプライベートレジストリを使用している実際のユースケースはありますか？ その意味で認証についてはどうするのでしょうか。 画像を下に引っ張ってから分解するだけではいけませんか？ 別のコンピューターに向かう途中で傍受しようとする代わりに？

TL; DR +1

+1

@Supernomadはよく言った。

Docker側から見てください。これは、公式に実装されないように維持する方がよい問題の1つですが、痛みを和らげるための多くの可能な回避策があります。 大声で叫ぶ一部のユーザーは、競合他社のマーケティングラベルドッカーよりも「意図的に安全ではない」との痛みが少なく、その評判を永遠に損なうことがあります。
そうは言っても、+ 1。

@ tiborvass @ ewindischこの問題は1年以上前のものです。 再評価するとおっしゃってから8ヶ月以上経ちます。 あなたはそれを評価しましたか？ もしそうなら、何が決定されましたか？ 兄弟をぶら下げたままにしないでください！ :-)

この問題が最初に開かれ、閉じられ、再び開かれて以来、コミュニティは、主にこのデフォルト設定の無益さを実証するために、これを自分で修正する多くの方法を考え出しました。

• ssh -N -L 5000:host:5000 user<strong i="10">@host</strong> && docker pull localhost:5000/lolsecurity
• socat tcp4-listen:5000,reuseaddr,fork tcp4:registry:5000 && docker pull localhost:5000/lolsecurity
• docker-machine create -d virtualbox --engine-insecure-registry 0.0.0.0/0 lolsecurity
• docker run --name registry_forwarder -d -p 5000:5000 -e REGISTRY_HOST="<registry_host_ip>" -e REGISTRY_PORT="5000" rsmoorthy/registry-forwarder && docker pull localhost:5000/lolsecurity

言うまでもなく、CoreOSにはデフォルトで--insecure-registry 0.0.0.0/0付属しています。 これらの例は、「sysadmin」と「developer」の間に関心の分離の線があるという考えが、2015年にはほとんど恣意的で偽物になっていることを明確に示しています。実際、コンテナーの考えそのもの（Dockerがチーフです） evangelist）は、そもそも誰もが「システム管理者」と呼ぶのが面倒な従来の運用から離れて、この傾向を大幅に加速させました。

とにかく、私はこれが何らかの形で永久に閉鎖されるのを見たいと思います。

+1

+1

+1

SSL秘密鍵でDockerレジストリを信頼する必要があるのはなぜですか？

この干渉によって乾燥するために取り残された他のCoreOSユーザーにとって、
https://coreos.com/os/docs/latest/registry-authentication.html#using -a-registry-without-ssl-configured

@politicianは、自分でそれを上手く言うことはできませんでした。 間違いなく、dockerは、ユーザーの大部分が少なくとも不満を持っているという事実を無視しているようです。

事実、私はDockerから完全に移行する過程にあり、その決定に満足することはできませんでした。 私は現在gitとlxcを使用しており、dockerよりも高速に受け継がれるだけでなく、完全かつ完全に間違っているとはいえ、他の会社が私にとって最善であると考えていることではなく、実際に自分の会社にとって最善のことを行うことができます。

いくつか例を挙げると、ロケット、raw lxc、qemu（同じではありませんがそれでも優れています）など、dockerよりも正直に優れている代替案を検討することを強くお勧めします。

これからコンテナを検討している私が知っているすべての人に、この行動方針を強く提案します。 少なくとも、dockerの人々が自分たちにはわからないことに気付くまで、私は_絶対に_わからないことを強調します。セキュリティの観点からエンドユーザーにとって何が最善かを強調します。

私はあきらめて、安い専用SSL証明書を購入しました。 CAシステムへのDockerCLIの依存関係は非常に強力です。自己署名証明書は、操作上イライラするだけでなく、単に機能しません。

• docker-machineは、ダウン/アップ間のca.crtオーバーライドを削除します
• どのベースイメージにも、CI用のドローンのような証明書作成ツールが含まれていません
• docker CLIは証明書に非標準のフォルダーを使用するため、これは覚えておくべきことです。
• 18時間後に動作させたとしても、何か他のものが壊れているというしつこい感じが常にあります。

結論：Dockerは、自己署名証明書を使用しようとすると、運用チームに永続的な継続的なペナルティを課します。

curl -kが永遠に存在していたので、これはさらにいらいらします。

+1

彼らがこれについて気にしないのはかなり悲しいことです。 一部の開発者がDockerをいじって自分の環境をホストしたいだけの場合、通常はSSL証明書などをいじりたくないでしょう。 さらに、自宅に公開されそうにない独自のサーバーがある場合は、SSLは必要ありません。

@buehlerは、デーモンの設定またはdaemon.json構成ファイルに--insecure-registryオプションを追加できます。 その後、一度設定するだけで、フラグを指定せずにプルできます

私たちからの更新：それ以来、インフラストラクチャからレジストリを取り除き、AzureBlobストレージサポートを備えたカスタムフォークのドジェストリーを使用

@buehlerだけの構成に次の行を追加し、@thaJeztahの提案を具体化するために：

--insecure-registry 0.0.0.0/0

必要なレジストリにアクセスできるようになります。 ものをテストするためにうまく機能します。

@politician画像が異なるリポジトリでタグ付けされている場合、重複が発生します。 ブロブの削除の欠如は非常に大きな問題です。

@thaJeztahは簡単に実行できますが、80％（明らかに任意の数）のユーザーが実行する必要がある場合は、デフォルトにしてください。

@justinclaytonいいえ; このオプションを設定すると、基本的に「レジストリへの安全な通信に関する問題を無視する」と表示されるため、「箱から出して」中間者攻撃を許可するか、デーモンを非TLS「http：//」にフォールバックさせます。 。 Dockerは、 127.x.x.x範囲のレジストリのデフォルトとしてすでに設定しています。

ローカルレジストリがあり、その証明書を生成したくない場合は、デーモンオプションに--insecure-registryを追加するのに1分もかかりません。 ただし、これは意図的なアクションであり、デフォルトで設定されているものではありません。

@thaJeztah私はあなたの議論を理解していますが、それで終わりではありません。 これがデーモン側にある結果として、新しい開発者のユーザーエクスペリエンスには大きなギャップがあります。 これが苦痛である_majority_シナリオは、docker.comの指示に従ってMacにDockerToolboxインストーラーをダウンロードして実行する新しい開発者です。 完了すると、すぐにdocker pull <internally-signed-registry>/fooを実行しようとし、エラーが表示されます。 これが本当の問題です。 おそらくそれは、この問題の名前を変更する必要があることを意味しますか？

これを解決できる方法は他にもたくさんあります。 コミュニティと会社はそのうちの1つに同意できると確信しています。

• この問題の現在の名前は「--insecure-registryは「dockerpull」にある必要があります」です。 この問題はまだ未解決であるため、このオプションはまだ検討中であると想定する必要があります。
• 初心者ユーザーにとって簡単な、これに対する単一コマンドのソリューションが提供（および文書化）されていれば、これは解決されます。
• この場合、レジストリは保護されています。 ビルド環境の他のすべてと同様に、内部CAによって署名された証明書を使用します。 これは十分なセキュリティです。 デーモンがどういうわけかMacOSの証明書ストアを尊重できれば、この頭痛の種もなくなります。
• ツールボックスのインストールプロセス中に、証明書を追加するか、この構成をdocker-machineに作成するように求められた場合は、おそらくそれでも問題ありません。

この問題の70人以上の参加者に、これをどの方向に進める予定かを知らせてください。そうでない場合は、問題を閉じて、問題が解決しないようにしてください。 ありがとう。

@thaJeztah
実行中のすべてのコンテナを再起動せずに、デーモンoptsに単一の--insecure-registryを追加する方法はありません。 それが主な問題の1つです。 再起動せずに構成を再ロードすることはできません（問題は2013年から続きます）。デーモンにオプションを追加して再起動しない限り、他の安全でないレジストリからイメージをプルすることはできません。 そして今日では、その問題を修正するための明確なロードマップがまだありません。

@apakhomovは、 https： //docs.docker.com/engine/reference/commandline/daemon/#configuration-reloadingを再起動せずに更新できる構成変更のリストに追加できると推測してい

+1。

一部のPaaSプロバイダーは、デーモンへのアクセスを許可せず、ユーザーのプライベートネットワークを実行します（たとえば、Jelastic）。

Dockerに複数の安全でないレジストリを追加することは可能ですか？
--insecure-registry xxxx：xxxx --insecure-registry zzzz：zzzzのようなもの

@kkorada --insecure-registry=0.0.0.0/0は、Dockerを以前と同じように動作させます。

@kkoradaはい、複数のレジストリを指定できます（フラグは--insecure-registry=[]です。角かっこは複数回指定できることを示します）。

また、docker 1.12の場合、デーモンを再起動せずに、このオプションをdaemon.json構成ファイルで構成可能にします。 こちらのオープンプルリクエストをご覧ください： //github.com/docker/docker/pull/22337

@mingfangと@thaJeztahに感謝します

@mhamrahと@justinclaytonが提案したように、GitがsshとTLSの両方を使用してリポジトリへのアクセスを許可するのと同様に、TLSに加えてsshを使用するソリューションもお勧めします。 これは、 @ justinclaytonがリストしたssh回避策を利用する可能性があります。

私の主張を裏付けるデータはありませんが、ファイアウォールの背後で実行されているプラ​​イベートレジストリは、オープンインターネットで実行されているレジストリよりもはるかに多いと思います。 その場合、sshは構成が簡単で、TLSよりも安全です。

さらに、 docker pushとローカルのプライベートレジストリを内部の十分に安全な仮想マシン内で実行して何日も戦った後（そして自己署名証明書の作成に苦労して）、本当に感謝するようになりましたrkt --insecure-options=image,tls,http 。

これがクライアント設定ではないのは気が狂っています。 明らかに、それは安全でない練習を助長するので、デフォルトでオンにすべきではありません。 ただし、デーモンに設定を設定すると、デバッグ目的やローカル開発環境では非常に実用的ではなくなります。

私の現在のユースケース：dockercomposeで開発環境を実行しています。 環境にはローカルDockerレジストリが必要です。 これは、完全にローカルVMで実行することを目的としています。

Dockerの方法：各開発者のマシンで安全でないレジストリを有効にするようにdocker-machineを構成する方法を説明します。既にある場合は、docker-machineを再作成するか、手動で構成を編集する必要があります。

ハッキーな解決策：レジストリを使用する必要がある各コンテナで実行されているsocatは、localhostにリダイレクトされます。

物事を簡単にするわけではありません...

+1

--insecureがクライアント構成にならないのは本当に残念です！
それは私たちにとっても多くの苦痛を生み出し、上記の説明の多くと非常によく似ています。
デフォルトで--insecure-registry = 0.0.0.0/0を設定してください。prは、docker-compose構成だけでなくdockerコマンドにも渡す方法を提供します。

+1

+1

毎年恒例の+ 1Pity Partyの時間ですか？

2016年12月13日、午前1時に、沙包妖梦[email protected]は次のように書いています。

+1

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

画像レイヤーが署名されている場合、セキュリティのためにCAPKIを使用する必要はありません。 apt / yumの動作も参照してください。 さらに、LANでSSLを使用することはほとんど意味がなく、クラウド環境では、証明書自体は別として、適切なランダム性ソースをプロビジョニングする必要があります（https://lukehinds.github.io/2015-03も参照）。 -03-Entropy-in-the-cloud /）。

簡単に言うと、不要な場合は、ユーザーに無理に押し込まないでください。

関連する＃29736を開いたところです。

+1、クライアント側の--insecure-registryフラグを使用できない場合は、 docker pullおよびdocker push使用する信頼できる証明書を指定する方法が必要です。 誰もがOSレベルの信頼証明書にアクセスしたり、Dockerデーモンをいじったりするためのアクセス権を持っているわけではありません。

ホストされたCIサーバー（Dockerイメージの構築とプライベートレジストリへのプッシュに使用されている）は、そのレベルのアクセス権がない可能性がある場合の良い例です。

+1

@ajhodges https://docs.docker.com/registry/insecure/#using -self-signed-certificates

@tiborvass
sudoアクセスがある場合にのみ機能します...

開発者がDockerを使用するのを思いとどまらせるための+1の良い方法

+1、 docker login --insecure-registryも見たいです。

あなたが意識的にそれをしているので、私はこれをセキュリティの問題とさえ見ていません。 また、許可されていない誰かがルートアクセスを取得した場合、これもセキュリティを提供しません。 この制限には実際にどのようなメリットがありますか？

悪意がある場合は、イメージを信頼できるDockerHubにアップロードするだけで済みます。

+1そして率直に言ってこれは頭を悩ませます

ペイントレインに+1。

プラスF * cking One！

このためのPRはありますか？

AFAIKではありません。 上記のリンクは、私自身のコードの一部がこの問題を参照しているために生成されています。 ここでスパムを静めるために、しばらくの間その参照を引き出します。

+1も...

+1

+1、 deamon.json設定を追加してdockerを再起動するのは非常に不便です。

マシンが異なればOSも異なります。 yum 、 apt-getからdockerをインストールするものもあれば、バイナリを直接使用するものもあります。 だから私はそれを検出してdockerdを正しく再起動する必要があります....それは災害です

Dockerプルには--insecure-registryフラグが必要だと強調します。

たった3年です-今は希望を失わないようにしましょう

バンプ🤣

+1

+1

これにより、ユーザーがレジストリを安全なものとして設定するように促すという議論は、思いがけないだけでなく、重要なポイントも欠いています。 これにより、Dockerレジストリが頻繁に移動する、操作作業を行うために多くの人がrootアカウントにアクセスできる必要がある位置に操作が配置されます。
この結合は、運用上のセキュリティの観点から、より大きなセキュリティリスクを生み出します。

第2に、プライベートネットワーク（多層クラウドホストアプリケーションなど）では、レジストリのセキュリティ保護は不要であり、最上位に位置するテクノロジの実装がさらに複雑になり、セキュリティ管理のレイヤーが必要になります（自動Docker認証を処理するため/更新）安全なDockerレジストリが使用されている場所。

少なくとも、ドッキングウィンドウデーモンは、安全でないレジストリパラメータを渡すことができるようにするために、設定する必要があります適切な場所にセキュリティ設計を移動する- 。ドッキングウィンドウ自体の管理者の手の中に、外。

FWIWシェルスクリプトからjson構成にパッチを適用することは大きな問題であるため、「安全でないレジストリのリストにレジストリを追加する」コマンドに満足しています。

+1

：+1：+1

+1

+1

+1

+1

要求された実装の多くは、Dockerを利用している企業がSOCコンプライアンス要件などを順守することを不可能にします。

これには解決策があるはずですが、画像の保存方法と実行方法に、より大幅なアーキテクチャの変更を加えない簡単な解決策はないと思います。

それでも、それは起こるはずです。

私はDocker開発に関与しなくなったので、言及から自分自身を削除します。 頑張ってください^ _ ^

SOC要件は良い点です。 その場合、この機能は、システム全体のDocker構成に追加される構成オプションで有効にする必要があります。 そうすれば、SOC要件を維持できます。 dockerコマンドラインで--insecure-registryフラグを有効にする「ALLOW_INSECURE_REGISTY_OPTION」のようなもの。

SOCに準拠するには、このオプションを有効にしないでください。

+1

たった3年です-今は希望を失わないようにしましょう

5.5。

この提案（現在の形で）は、さまざまな理由で実施される可能性はほとんどありません。
理由、その中で;

• Dockerデーモンを管理する人がどの接続を担当するかを維持します
  デーモンは作成を許可されています。 このオプションは「ライブリロード」できることに注意してください。
  したがって、構成を変更するためにデーモンを再起動する必要はありません。
• レジストリと相互作用する可能性のあるすべてのコマンドまたはコードパスには、
  変更する; docker pullでなく、 docker build 、 docker run 、
  docker plugin 、 docker service 、 docker stackサブコマンド、および
  ワーカーノードからイメージをプルするswarmkitなどのオーケストレーター。
• SOCコンプライアンス（上記のとおり）

少なくとも、dockerデーモンは安全でないことを許可するように構成可能である必要があります
渡されるレジストリパラメータ。これにより、セキュリティ設計が適切なものに移行します。
場所-管理者の手に、Docker自体の外に。

この場合の管理者は、
リモートに接続するユーザーではなく、Dockerデーモンが実行されるホスト
API。 これが、この構成がデーモン構成である理由です。

シェルスクリプトからjson構成にパッチを適用することは、大きな問題です。

これは公正な点ですが、この議論とは直交しています。 それは_不可能_ではありません
JSON構成にパッチを適用しますが、他の構成よりも複雑になる可能性があることに同意しました
ファイル形式。 この構成は、フラグを使用して設定することもできます。
systemdドロップインユニットファイルを使用して再構成できるデーモン。
デーモン。

dockerコマンドラインで--insecure-registryフラグを有効にする「ALLOW_INSECURE_REGISTY_OPTION」のようなもの。

レジストリからの安全でないプルを許可する場合（これは同等です）
--insecure-registryフラグを追加することで、「インターネット」を安全でないものとして許可できます。
レジストリ; 以下は、任意のIPv4アドレスを安全でないレジストリとして使用できるようにする必要があります。
（したがって、非TLS接続にフォールバックします）;

/etc/docker/daemon.json構成ファイルを介して;

{"insecure-registries": ["0.0.0.0/1","128.0.0.0/2","192.0.0.0/3","224.0.0.0/4"]}

または、デーモンのフラグとしてオプションを渡すことによって（systemdで設定できます）
オーバーライドファイル）;

dockerd \
    --insecure-registry=0.0.0.0/1 \
    --insecure-registry=128.0.0.0/2 \
    --insecure-registry=192.0.0.0/3 \
    --insecure-registry=224.0.0.0/4