[Starlingx-discuss] [Container] docker daemon proxy issue clarification

Wensley, Barton Barton.Wensley at windriver.com
Fri May 31 13:06:10 UTC 2019

Thanks for the explanation Mingyuan. Based on what you describe below, StarlingX does not support an https connection to the proxy server. StarlingX does not provide a mechanism for a user to install public keys - without that in place, an https connection to the proxy server is not possible. Please note that it is not an acceptable solution to have the user manually edit files on the StarlingX side to install the public key for the proxy. These edits would have to be done on multiple hosts and the edits would disappear if a host was re-installed.

We'll have to ensure our documentation for the proxy feature clearly explains this limitation.


From: Qi, Mingyuan [mailto:mingyuan.qi at intel.com]
Sent: May 30, 2019 10:33 PM
To: Ngo, Tee; Wensley, Barton; starlingx-discuss at lists.starlingx.io
Cc: Miller, Frank
Subject: RE: [Container] docker daemon proxy issue clarification


In most of the time, we use "http proxy server" as proxy to access both http and https requests. The header "http" of http://<proxy<http://%3cproxy> IP>:<proxy port> indicates that this proxy server is a "http proxy server", the connection through client and proxy server uses http request no matter what the target request type is. Usually proxy is used internally within a trusted organization and we trust the proxy server not being attacked by Man-in-the-Middle Attack.

However, there is also a more secure way to connect to a "https proxy server" that the header of proxy url is "https", each request is https between client and proxy server regardless the target request type. Consequently TLS/SSL handshake is needed and client needs the public key of proxy server as well for TLS/SSL authentication. That's why you face "TLS handshake timeouts" issue. I'm not sure whether Tinyproxy supports configuration as a https server. If it does, https://<proxy<https://%3cproxy> ip>:<proxy port> should work with a public key set at client side.


From: Ngo, Tee [mailto:Tee.Ngo at windriver.com]
Sent: Friday, May 31, 2019 0:32
To: Wensley, Barton <Barton.Wensley at windriver.com>; Qi, Mingyuan <mingyuan.qi at intel.com>; starlingx-discuss at lists.starlingx.io
Cc: Miller, Frank <Frank.Miller at windriver.com>
Subject: RE: [Container] docker daemon proxy issue clarification

Bart, Mingyuan,

We got derailed a bit but gained more knowledge in the process. I have reverted back to my original one line fix. With this change, the NO_PROXY IPs are automatically derived from the provided subnets. The user can also extend the default list by adding docker_no_proxy with additional IPs to the host override file.


From: Wensley, Barton
Sent: May-30-19 11:12 AM
To: Qi, Mingyuan; starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at lists.starlingx.io>; Ngo, Tee
Cc: Miller, Frank
Subject: RE: [Container] docker daemon proxy issue clarification

Thanks Mingyuan for looking into this.

I have done my own testing and can confirm your findings:

*        Configuring an http and https proxy at the same time is supported.

*        Configuring both proxies in the same config file is also OK.

Based on that, the only fix required in [0] is to configure the default NO_PROXY settings when they are not specified.

We are testing with Tinyproxy (https://tinyproxy.github.io) here in Ottawa, which acts as both an http and https proxy. Our config is different than what you specified below.

For http proxy only:
docker_http_proxy: http://<proxy<http://%3cproxy> IP>:<proxy port>

For https proxy only:
docker_https_proxy: http://<proxy<http://%3cproxy> IP>:<proxy port>

For http and https proxy:
docker_http_proxy: http://<proxy<http://%3cproxy> IP>:<proxy port>
docker_https_proxy: http://<proxy<http://%3cproxy> IP>:<proxy port>

The difference from your email below is that we never specify https to access our proxy - doing that causes TLS handshake timeouts. I suspect that is just a difference in the proxies we are using? In any case, I see that in many of the on-line articles (e.g. [3]), http is always used to access the proxy itself.


From: Qi, Mingyuan [mailto:mingyuan.qi at intel.com]
Sent: May 30, 2019 12:59 AM
To: starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at lists.starlingx.io>; Ngo, Tee; Wensley, Barton
Cc: Miller, Frank
Subject: [Container] docker daemon proxy issue clarification

Hi Bart and Tee,

To clarify the docker daemon proxy issue discussed in review comments[0], I move the discussion here for a clear view.

The question is, docker daemon proxy setting in starlingx is not the same as current docker doc[1]. The difference is we in starlingx only create http-proxy.conf for HTTP_PROXY, HTTPS_PROXY, NO_PROXY setting, while the document suggests http-proxy.conf for HTTP_PROXY and https-proxy for HTTPS_PROXY. Does it impact the docker daemon proxy setting?

That might be a little confused of the terminology of above file name and environment variable name. HTTP_PROXY means all the target url requests go via this proxy server if the request type is http, and the same meaning as HTTPS_PROXY, not the proxy server type itself is http or https.

Through my test of docker daemon proxy and golang net lib (used by docker daemon proxy connection) code[2] , the http-proxy.conf and https-proxy.conf have the same target just to set HTTP_PROXY/HTTPS_PROXY/NO_PROXY environment variables to golang net lib. The file name of the conf does not impact the proxy setting. I even renamed http-proxy.conf to test.conf and got a successful pulling from http registry and both https registry through proxy. So I don't think following current docker proxy setting doc is a must.

Moreover, as I said in the review comments[0], starlingx docker daemon proxy setting was the official approach(only one http-proxy.conf file) at some time in 2018, but it's disappeared. Some technical articles[3][4][5] indicates that this setting approach is valid. Therefore, I think current starlingx approach for docker daemon proxy setting is valid and no changes needed.

The remaining question from Tee to test https proxy is not the same as above. To use a https proxy server, the setting should be:
No matter these environment variables are set in http-proxy.conf or https-proxy.conf or test.conf.
If test team has a https proxy server, this can be tested by current config mechanism.

[0] https://review.opendev.org/#/c/661825/
[1] https://docs.docker.com/config/daemon/systemd/#httphttps-proxy
[2] https://github.com/golang/net/blob/master/http/httpproxy/proxy.go#L28
[3] https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.1.2/installing/install_proxy.html
[4] https://elegantinfrastructure.com/docker/ultimate-guide-to-docker-http-proxy-configuration/
[5] https://www.thegeekdiary.com/how-to-configure-docker-to-use-proxy/

Best Regards,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20190531/3935cb0f/attachment-0001.html>

More information about the Starlingx-discuss mailing list