Using Apache HttpComponents does not honor the JVM Proxy settings

[schulzh]

Spring-cloud-vault does not respect the http.proxyHost and http.proxyPort system parameters when connecting to vault, it always tries to connect directly. This makes it unusable behind a proxy like in many corporate environments.

[spencergibb]

It seems strange to me to connect to vault, the thing that stores secrets, via a proxy. Why exactly would you require it?

[schulzh]

Well, I cannot connect to vault, running on AWS, from my workplace behind the firewall. The proxy does not intercept SSL, so the connection is still secured end to end.
It is not that uncommon for enterprise networks to use proxy servers for all internet facing connections.

[mp911de]

Proxy support depends on the used HTTP client. Spring Vault supports Apache HttpComponents, OkHttp 2+3, Netty and the JDK client (in that order of dependencies available during runtime).

You can provide an own ClientFactoryWrapper bean that holds a configured ClientHttpRequestFactory configured with a client that either respects the system properties or is configured to use a proxy.

[spencergibb]

@schulzh so for development purposes? Vault is very easy to run locally, plus what @mp911de about configuring the http client.

[schulzh]

@spencergibb No, not for development. We have internal applications that need to access secrets on this vault, which is hosted outside of the corporate network, therefore we need to access it via the proxy. There is simply no other way to do that, and it works just fine with the command line client, Jenkins plugins, etc.; just not with Spring-cloud-vault.

Thanks @mp911de, I will look into that solution. Still, as vault is an HTTP application, it should honor the proxy settings of the JVM per default.

[mp911de]

From a technical perspective, if there is no external HTTP client, the JDK HTTP client is used which takes proxy system properties into account. As soon as an external HTTP client is on the class path, the JDK HTTP client is no longer used.

I think it would make sense to support HTTP proxy configuration because runtime environments can sometimes require a HTTP proxy. Any intercepting proxy is a threat for secrets and I assume that client certificate authentication stops working when using an intercepting proxy. We could provide proxy support for Apache HttpComponents, OkHttp 2 and 3 via system properties and configuration properties.Netty4ClientHttpRequestFactory does not support HTTP proxies. Proxy support requires a change in Spring Vault to configure the underlying HTTP client properly.

[spencergibb]

In other spring cloud uses of Apache and okhttp we support system properties, but not configuration properties.

[mp911de]

Ok, let's stick to that which requires only a change to Spring Vault. I created spring-projects/spring-vault#52 to do the actual change. I'll close this ticket once the change is in place.

[spencergibb]

Again, going over an HTTP proxy seems like a bad idea when you can use AWS VPN.

[mp911de]

That's fixed with spring-projects/spring-vault@d3af1d4. OkHttp 2 and 3 use the JVM proxy settings by default, only Apache HttpComponents was affected.