Moby: docker swarmモード：127.0.0.1のポートは0.0.0.0に公開されます

はい、これはエラーを出力するはずです。 サービス（デフォルト）は「ingress」ネットワークを使用して「公開」し、最終的にどの_node_に到達するかを予測できないため、IPアドレスの指定をサポートしません（したがって、使用可能なIPアドレスは不明です-127.0ですが.0.1が可能かもしれません）。 この問題は、その機能https://github.com/docker/docker/issues/26696を追跡してい

ここでのバグは、dockerがオプションを黙って無視するのではなく、エラーを生成する必要があることです。 この最小限のdocker-composeファイルを使用して再現可能。

version: "3.2"
services:
  mongodb:
    image: nginx:alpine
    ports:
      - "127.0.0.1:27017:80"

ping @dnephin @vdemeester

@ fer2d2スウォームモードで何かを公開すると（ ports場合はstack deploy ）、 ingressネットワークで公開されるため、公開されます。 そこを回避するいくつかの方法があるが、パッティングkind/bugその上で、我々は、少なくとも人々に警告しなければならないのでに関することやってたときにstack deployこの表記法を持っているポートを持つ（つまり、 host:port:port ）。

これを回避するには、いくつかの方法があります。

• まず、 mongoポートを公開する場合にのみ公開する必要があります。mongoからアクセスできます）。
• ingressではなくホストで公開する場合（つまり、スウォームモードを使用しない場合と同じように、スウォームパブリックではなく、実行中のホスト上でのみ）、ポート拡張構文を使用する必要があり

    ports:
      - mode: host
        target: 80
        published: 9005

docker run -p 80:9005 …と同じように動作するため、 0.0.0.0にバインドされますが、ホストに限定されます。

しかし、 @ thaJeztahが言ったように、「ここでのバグは、dockerがオプションを黙って無視するのではなく、エラーを生成するはずだということです」👼

/ cc @mavenugo @abochを使用して、実際に特定のIPにバインドできるようにする方法があるかどうかを確認しますか？ （ノードのIPが異なるため、達成するのは非常に困難です。）

@vdemeesterこの表記を使用して、ホストターゲットとしてlocalhostを指定できますか？

    ports:
      - mode: host
        target: 127.0.0.1:80
        published: 9005

これはポート構成の拡張フォーマットであるため、正しく機能するはずです。

前もって感謝します

長い構文では、ターゲットと公開の両方が整数型として適用されているようです

SSHトンネルを介して一部のサービスに接続している場合、これは望ましい動作ではないと思います。 たとえば、MySQLまたはMongoDBサーバーを127.0.0.1に配置し、SSHトンネル経由で接続する場合、Docker Swarmを使用して、0.0.0.0でデータベースポートを公開するか、SSHを内部で実行するカスタムデータベースコンテナを作成する必要が

SQL WorkbenchやRobomongoなど、この制限（特定のインターフェイスバインディング）のために使用できないSSHトンネルを使用するデータベースクライアントは多数あります。

私たちの会社では@ fer2d2と同じ問題があり、sshトンネルを介してMongoboosterをdockerswarmに接続しようとしています。 私たちが見つけた唯一の解決策は、27017ポートを開き、ユーザーとパスワードでデータベースを保護することでした。

連絡あった？

+1

+1

長い形式のポートマッピングにip_address ：portペアを許可する別の使用例は、エニーキャストアドレスまたはループバックに関連付けられている可能性のあるその他のアドレスです。 これらは、ループバックネットワークでのみ表示されるという点で127.0.0.1アドレスに似ています。 このプロパティを持つノードに制限されたサービスは、ポート変換のiptablesルールを回避しながら、ポートの衝突を回避するために、エニーキャストアドレスでのみポートを公開したい場合があります。

次のように指定すると、オプションになる可能性がありますか。

placement:
        constraints:
          - node.id ==

乾杯

+1

+1

+1

私自身のために私はこの問題を解決しました：

iptables -I DOCKER-USER -i eth0 -j DROP
iptables -I DOCKER-USER -m state --state RELATED,ESTABLISHED -j ACCEPT

Dockerはこれらのルールに触れません。 自分で追加するだけ
-A DOCKER-USER -j RETURN
その結果、ポートは0.0.0.0でリッスンしますが、外部インターフェイスeth0からはアクセスできません。

この動作は「デフォルトで安全」に違反しており、ドキュメントにメモを入れるだけでは不十分です。 今のところ、エラーが発生するはずです。

また、モード：ingress / hostにも関連しています（これらの2つの問題は議論で混乱しているようです）。 サービスがすべてのノードのローカルアドレスにバインドされるのを停止する必要があるが、外部アドレスにはバインドされない入力モードについては何もありません。 したがって、127.xxxを許可する必要があります。 （非スウォームモード（docker runを使用）では、127.0.0.2：80や127.0.0.3:80などにバインドします。開発中の複数のサーバーをローカルでテストします。）

もう1つの問題は、入力モードがデフォルトであるということです。 これは予期しないことであり、セキュリティの問題にもつながります。 127.0.0.3:80にバインドされたポートを使用して、ネットワークのプライベート部分にあるように制約されたノードでサービスを開始しようとしました。 次に、パブリックノードのパブリックインターフェイスにもバインドされました。 （これは、IPアドレスを黙って無視し、入力モードを黙って使用しているため、データが公開されています）。

ユースケース

• 私に影響を与えたユースケース（間違いなく本物）
  
  
  
  • 1ポートは他のノードで使用されているため、特定のノードのポートにバインドします。 これにはホストモードを使用できますが、デフォルトは驚きです。
  
  
  • 2他のノードにはパブリックインターフェイスがあるため、特定のノードのポートにバインドします。 これにはホストモードを使用できますが、デフォルトは「デフォルトで安全」に違反しています。
  
  
  • 3他のホストに表示したくないため、ローカルでバインドします。デフォルトは「デフォルトで安全」に違反しています
  
  
  • 4 127.0.0.3にバインドします。これは、開発マシンに多くのものがあり、このポートで127.0.0.1が使用されているためです。 また、 /etc/hostsを使用して、各ドメイン名が異なるコンテナに送信されるようにします。 これはdocker runで機能しますが、composeでは機能しません。
  
  
• その他のユースケース
  
  
  
  • これは内部ネットワークであるため、192.168.0.xなどの特定のインターフェイスにバインドします。 デフォルトは「デフォルトで安全」に違反しています
  
  
  • 特定の特定のノードにバインドしますが、このノードで実行するようにサービスを制限しません。 これは1または2と同様のユースケースですが、制約を使用していません。 トラフィックは群れを経由してルーティングされます。
  
  

要約すると

• IPアドレスを無視し、0.0.0.0にバインドすることと、デフォルトの入力モードは、どちらも「デフォルトで安全」に違反しています。 IPアドレスが指定され、ドキュメントが更新された場合、エラーが発行されます。 モードが指定されていない（デフォルトがない）場合、エラーが発行され、ドキュメントが更新されます。 （これにより、モードの問題が修正され、予期しないセキュリティの問題が停止します。）
• その後、ホストモードでIPアドレスのサポートを追加できます。
• ローカルアドレス127.xxxに制限されている入力モードでのIPアドレスのサポートを追加できます。 （異なるローカルアドレス（例：127.0.0.2と127.0.0.3）は異なるものとして扱われる必要があります（OSに渡されるだけです））。

ローカルアドレスへのバインドを許可すると、制約のあるノードに役立ちます。 特定のアドレスへのバインドを許可するか、制約されたノードで機能するか、スウォームを介してノードの1つにあるアドレスの1つにルーティングされます（入力モードのみの場合があります）。 このルーティングはすでに行われています

@ richard-delorenzi Mobyは現在、ホストIPを受け入れていません。 したがって、機能リクエスト以外では、これはクライアント側の問題のように聞こえます...具体的には、composeyamlがDockerCLIでどのように変換されるかです。

入力が機能する方法はかなりよく文書化されていますが、これはCLIでの動作が悪いことに同意します。

+1

+1

+1

私が使用する種類の回避策があります。 スタンドアロンコンテナを実行し、それらを「core」という名前のネットワークに接続します。このネットワークは、群れの中で実行されているすべてのバックエンドサービス（mongo、elasticsearch、influxdbなど）で使用されます。

作成ファイルでこれを行う方法がわからないため、次のようにスタンドアロンコンテナを実行しているだけです。

docker run --name kibana --rm -d -v /var/lib/kibana:/usr/share/kibana/config -p 127.0.0.1:5601:5601 --network core docker.elastic.co/kibana/kibana:6.1.2

docker run --name chronograf --rm -d -v /var/lib/chronograf:/var/lib/chronograf -p 127.0.0.1:8888:8888 --network core chronograf:1.4 chronograf --influxdb-url=http://influxdb:8086

これらを開始した後、dockerpsは新しいコンテナーが127.0.0.1にバインドされていることを示します。 アーメン。 次に、ローカルワークステーションからDockerホストにトンネリングして、次のように安全にアクセスできます。

ssh -i my_ssh_key.pem [email protected]  -L 8888:localhost:8888  -L 5601:localhost:5601 -N

ブラウザから、 http：// localhost ：8888またはhttp：// localhost ：5601に接続でき

私のために働きます。

UNIXソケットが127.0.0.1TCP / IPソケットを置き換えることができる場合、私がfluent-bitに対して実装した可能な回避策はここにあり

mode別のオプションを追加すると役立つかもしれません。 hostとingressに加えて、 localようなもの。

「ユーザビリティ：Mobyはユーザビリティを損なうことなく安全なデフォルトを提供します」という文言を削除してください。 mobyのreadmeファイル。 これは間違いなく虚偽の広告です。@ richard-delorenziのコメントを参照してください。

サービスはデフォルトでポートを公開しないため、ポートを公開するように指定しない限り、サービスにアクセスできません。 現在、特定のIPアドレスへのバインドはサポートされていません。 サービスにアクセスできない場合は、ポートを公開せず、内部（オーバーレイ）ネットワークを使用してサービスに接続します。

IPアドレスへのバインドのサポートの追加については、 https：//github.com/moby/moby/issues/26696で説明されてい

スタックをデプロイするときに警告が追加されました。

docker stack deploy -c- test <<'EOF'
version: '3'
services:
  web:
    image: nginx:alpine
    ports:
      - "127.0.0.1:8080:80"
EOF

WARN[0000] ignoring IP-address (127.0.0.1:8080:80/tcp) service will listen on '0.0.0.0' 
Creating network test_default
Creating service test_web

また、指定されたIPアドレスを使用してサービスをデプロイしようとすると、エラーが発生してデプロイに失敗します。

docker service create -p 127.0.0.1:9090:80 nginx:alpine
invalid argument "127.0.0.1:9090:80" for "-p, --publish" flag: hostip is not supported
See 'docker service create --help'.

@daluシステムがインターネットに公開されていて、Dockerにクラスター上のサービスを公開するように指示した場合、期待が他の何かになる理由が

確かに、開発と実際の展開を制限するこの構成形式には、いくつかの重大な妥協点があります。

@ cpuguy83

システムがインターネットに公開されていて、Dockerにクラスター上のサービスを公開するように指示した場合、期待が他の何かになる理由がわかりません。

いいえ。 誰かが127.0.0.1や10.0.0.0などの非パブリックIPにバインドした場合、なぜパブリックにアクセスできる必要があるのですか？ 実際、それは正解です。

特定のIPアドレスへのバインドは現在サポートされていません

@dalu

しかし、それは公にではなく、アクセス可能でなければなりません。 そして、それがここでのすべての取引です。
デフォルトでは安全ではなく、セマンティクスによる修正を回避しています。
この問題は、適切な解決策がないまま、ほぼ2年間開いています。

swarmが使用できないため、swarmからkubernetesに移行しています。 この移行には非常にコストがかかるものの、この決定には完全に満足しています。

@Bessonvそれは

問題は、作成フォーマットが開発環境向けに設計されており、クラスターのデプロイをサポートするようにプッシュされていることです。 「dockerstack」はエラーになるはずですが、1つの作成ファイルを使用してすべてをルール化できるようにしたいので、この混乱が発生します。

@ cpuguy83
この説明に満足できるかどうかはわかりません。 最後に、作成フォーマットは、目的の状態の単なる説明です。 1台のマシン（作成）とクラスター（群れ）の間にいくつかの違いがあることはまったく問題ありません。 私の見解では、作曲をサポートする意味はまったくありません。 特にスウォームモードのアクティブ化はとても簡単だからです。 しかし、これには群れを修正する必要があります。

問題はまったく群がっておらず、compose形式とdockercliでの実装で100％です。
現在、スタックは100％クライアント側の実装であることに注意してください。

スタック内では、データベース、redisなどの内部サービスのポートを明示的に公開する必要がないことがわかりました。内部サービスのports構成を省略し、名前で参照するだけで問題ありません。

スタック内のdbサービスの例

services:
  db:
    image: postgres:11-alpine
  networks:
    - backend

... Django appサービスは、デフォルトで次のようにポートを使用できます。

DATABASES = {
    'default': env.db(default='postgres://user:pass<strong i="13">@db</strong>:5432/catalog'),
}

したがって、この場合、パブリックサービスのみを明示的に公開すると、デフォルトでセキュアのように見え

問題はまったく群がっておらず、compose形式とdockercliでの実装で100％です。
現在、スタックは100％クライアント側の実装であることに注意してください。

何でも:(この問題のために）スタックの使用をやめ、もう気にしません。 図書館のせい、港湾労働者のせい、私の猫のせい。

dockerを直接使用する場合、またはcomposeを使用する場合、この問題は発生していません。

このアプローチが役立つように見えます（群れのすべてのノードで実行する必要があります）：

1. 群れを残す
2. ネットワークdocker_gwbridgeを削除します
3. 追加オプションcom.docker.network.bridge.host_binding_ipv4 = IPを使用してネットワークdocker_gwbridgeを再作成します
4. 群れに戻る
   モード「ホスト」で公開されたポートで機能します。 モードがない場合、「ホスト」入力ネットワークは他のドライバーおよびスコープ「スウォーム」とともに使用されます。

恐ろしい解決策：

$ mv /usr/bin/docker-proxy /usr/bin/docker-proxy-original
$ cat << 'EOF' > /usr/bin/docker-proxy
#!/bin/sh
exec /usr/bin/docker-proxy-original `echo $* | sed s/0.0.0.0/127.0.0.1/g`
EOF
$ chmod 755 /usr/bin/docker-proxy
$ service docker restart

@jsmouret最新のdockerリリースでdocker -proxyを見つけることすらできません。 それはいくつかの遺産ですか？ それとも名前が違うの？

状況によります...

$ apt-file search docker-proxy
docker-ce: /usr/bin/docker-proxy
docker.io: /usr/sbin/docker-proxy

この動作は、ドキュメントに何らかの形で文書化する必要があります。
現在、ショートポートマッピングからホストを無視するだけです。 そして静かに動作しません。

もう1つの奇妙なことは、長い構文スキーマでホストを設定できないことです。

この動作は、ドキュメントに何らかの形で文書化する必要があります。

同意する; そのページのどこかで言及されていると思いましたが、見つかりません。 ドキュメントリポジトリで問題を開いてください。 https://github.com/docker/docker.github.io/issues

現在、ショートポートマッピングからホストを無視するだけです。 そして静かに動作しません。

どのバージョンのDockerを使用していますか？ 警告（ docker stack deployを使用する場合）または_error _（ docker service createを使用する場合）を出力する必要があります。 https://github.com/moby/moby/issues/32299#issuecomment-472793444を参照して

どのバージョンのDockerを使用していますか？ 警告（docker stack deployを使用している場合）またはエラー（docker service createを使用している場合）を出力する必要があります。

うーん、それは私のせいのようです。 コンソールからスタックをデプロイしようとしたときに、実際にそれが行われます。
以前はportainerUIを介して実行しましたが、エラーや警告は表示されませんでした。

ほぼ2年間、Docker開発者の中には、その機能が必要な場合に1つの有効で

実行可能なクリーンなソリューションは、データベースと同じDockerネットワークに接続されている2番目のコンテナーでSSHサーバーを実行することです。 その後、SSHポートをホスト上で（もちろん22とは異なるポートに）公開できるため、SSHコンテナーを介してデータベースに転送できます。

@nartamonovプロトコル自体が安全でない限り、これを入力から安全に行う方法がわかりません。
安全にアクセスする方法は、暗号化されたデータプレーン（過度のネットワークの場合は--opt encrypted ）を使用し、そのネットワークに接続する必要のあるツールを使用してコンテナーを起動することです。

これにはおそらく他の無関係な副作用がありますが、 /etc/docker/daemon.json "iptables": falseを設定すると、回避策としてもうまくいきます。 それほど抜本的な解決策は、 @ helldwellerが提案したようなカスタムルールだけを追加することです。

いずれにせよ、私は3年後にこれに対するもう少しのサポートを見たいと思います。

このアプローチが役立つように見えます（群れのすべてのノードで実行する必要があります）：

1. leave swarm

2. remove network docker_gwbridge

3. recreate network docker_gwbridge with additional option com.docker.network.bridge.host_binding_ipv4=IP

4. join swarm back
   Works for ports published in mode "host". Without mode "host" ingress network is used with other driver and scope "swarm".

@ienovytskyi
私が間違っていない場合、これにより、公開されているすべてのポートが特定のデフォルトのIPアドレスにバインドされますか？ したがって、明確にするために、これは、一部のサービスの一部のポートのバインドされたインターフェイスのみを制約する場合、使用可能な回避策ではありません。

回避策を報告したいと思います。

使用事例：
群れの一部のサービスは、すべてのインターフェイス、または少なくともパブリックインターフェイスでリッスンする必要があります-私の例のこのコンテナはリバースプロキシです
これらのスウォームノードには、すべてのノードにデータベースインスタンスもあり、次のように定義されたスウォームネットワークを使用します。

docker network create --scope swarm NETWORK_NAME --attachable -d overlay

もちろん、データベース接続が必要なWebサービスはそのNETWORK_NAMEに参加する必要があります

管理目的で、データベースに直接接続する必要がある場合があります

解決：
すべてのネットワーク（私の例ではリバースプロキシ）で公開する必要があるサービスのみが、サービス定義にports: ['SOMEPORT:ANOTHERPORT']を含めることができます。

他のすべてのサービスでは、ホスト上にペアのDocker非スウォームコンテナーが必要です。
その非スウォームコンテナは、 NETWORK_NAME/nodeXYZ:portに存在するポートをlocalhostブリッジします

mongodbの例：

docker run --rm -it --net=NETWORK_NAME -d --name expose-mongo -p 127.0.0.1:27017:47017 alpine/socat tcp-listen:47017,fork,reuseaddr tcp-connect:mongo01:27017

欠点：すべてのスウォームノードに非スウォームコンテナが必要であるため、ansible / Heavyスクリプトを採用しない限り、多くのノードで本当に退屈です。

@ fer2d2が言及した「SSHトンネルを介して一部のサービスに接続している場合」の問題に対する私の回避策は、次のようなDockerfileを使用してsshサービスを追加することでした。

FROM alpine

RUN apk add --no-cache openssh
RUN mkdir ~/.ssh
RUN ssh-keygen -A
RUN echo "root:root" | chpasswd
RUN echo 'PasswordAuthentication no' >> /etc/ssh/sshd_config
RUN echo 'Port 22' >> /etc/ssh/sshd_config
RUN echo -e " \
Match User root \n\
  AllowTcpForwarding yes\n\
  X11Forwarding no\n\
  AllowAgentForwarding no\n\
  ForceCommand /bin/false\n\
" >> /etc/ssh/sshd_config

EXPOSE 22
CMD /usr/sbin/sshd -D -e "$@"

次に、docker-compose.ymlで：

...
  db:
    image: mysql:5.6
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD:?err}
      MYSQL_ROOT_HOST: '%'
    volumes:
      - "./mysql:/var/lib/mysql"
    deploy:
      placement:
        constraints: [node.role == manager]

  sshd:
    image: maxisme/sshd:latest
    volumes:
      - "~/.ssh:/root/.ssh"
    ports:
      - "2223:22"
    deploy:
      placement:
        constraints: [node.role == manager]

これにより、authorized_keysを~/.sshフォルダーに追加し、sshプロキシがポート2223を介してdbホスト名を使用してデータベースにジャンプできるようになります。

実行可能なクリーンなソリューションは、データベースと同じDockerネットワークに接続されている2番目のコンテナーでSSHサーバーを実行することです。 その後、SSHポートをホスト上で（もちろん22とは異なるポートに）公開できるため、SSHコンテナーを介してデータベースに転送できます。

有効

この機能が重要であるもう1つの例。
pleskがインストールされたサーバーがあり、pleskにはすでに構成がありますが、DockerSwarmサービスを指すように別の構成を追加できます。 このpleskサーバーはスウォームノードです。
pleskを使用してポートにproxy_passしたいと思います。 コンテナはオーバーレイネットワーク内にあるため、このポートは公開する必要がありますが、ワールドと通信するには外部ポートが必要です。

したがって、proxypassは127.0.0.1のようなローカルインターフェイスを指す必要があります：someport
群れのコンテナは、ローカルホストにのみポートを公開する必要があります。

このように、コンテナポートはプロキシパスによってのみアクセス可能であり、世界から直接アクセスすることはできません。

私はあなたの回避策@maxismeが好きですが、 authorized_keys所有権をどのように管理しますか？ OS Xでは動作しますが（マウントはroot属します）、本番Linuxマシンでは次のようになります。

Authentication refused: bad ownership or modes for file /root/.ssh/authorized_keys
Connection closed by authenticating user root 85.145.195.174 port 60535 [preauth]

ボリュームはホストユーザーのUIDに属しており、これはroot 、SSHDはそれを使用することを拒否します。 回避策に加えて回避策😬は、次のようにconfigsを使用することです。

services:
  sshd:
    image: [...]/sshd:${version}
    configs:
      # FIXME: It would be much better to use a bind volume for this, as it
      # would always be in sync with the host configuration. So revoking a key
      # in the host machine would automatically revoke it in the container. But
      # I can't figure out how to give the volume right ownership. It keeps UID
      # from the host which doesn't align with the container user.
      - source: authorized_keys
        target: /root/.ssh/authorized_keys
        mode: 0600

configs:
  authorized_keys:
    file: ~/.ssh/authorized_keys

コンテナがデプロイされるホストがわからないため、特定のホストIPアドレスにバインドするようにサービスに指示できないことを理解しています。

ただし、多くの場合、ホストには北と南の境界インターフェイスがあります。 スウォームポートをすべてのスウォームホストのノースバウンドインターフェイスにのみバインドすることができます。

サービスをバインドするすべてのインターフェイスのインターフェイス名が同じである場合（たとえば、eth0）、スウォームポートをバインドするインターフェイス名を指定するオプションを提供することをお勧めします（サービスポートセクション）。

    nginx:
      image: nvbeta/swarm_nginx
      networks:
        - demonet1
      ports:
        - "eth0:8088:80"

eth0がスウォームノードで使用できない場合、指定されたポートはどのインターフェイスにもバインドされません。

@ tad-lispyコンテナユーザーのuidとgidを、ホストのボリューム所有者と同じになるように変更できるはずです。
linuxserverの画像は（、https://hub.docker.com/r/linuxserver/openssh-serverを参照してください環境変数を設定することで、これをサポートしていますUser / Group Identifiers 、）