Jun 17, 2015 Securing Private Domains on a Public Cloud Foundry
If you're interested in hosting both public and private apps/microservices on the same Cloud Foundry, you aren't alone. Unfortunately, at the time of the writing of that article, there weren't many good options out there to accomplish it all. The haproxy job included with cf-release didnt (and still doesn't) have any built-in support for blocking requests to specific Hosts. On top of that, it opens up port 4443 using tcp mode + SSL to the same backend servers. This means that even if there were support for blocking requests to internal domains on
tcp/443, malicious users could work around that by issuing the requests to
Never fear, cf-haproxy-boshrelease is here!
Originally based off of the HAProxy job in cf-release, this custom HAProxy bosh release makes use of HAProxy's
timeout tunnel <integer>ms directive to support customizable timeouts for tunnelled/websocket HTTP connections. Because of this, websocket connections can remain established for much longer than regular HTTP(S) connections while using the same port(s). The upside here is that we no longer need to use
mode tcp on
tcp/4443 for websocket connections, and can instead use
mode http, enabling all the ports to perform ACL checks based on Host headers.
When using cf-haproxy-boshrelease to implement the architecture laid out in Dr Nic's previous post on this topic, you'll end up adding two discrete deployments of HAProxy to the environment - one for public access, one for internal access:
Why not just disable port 4443, and have cf-release support ACLs in HAProxy?
The main reason for having support for
tcp/4443 is that AWS Elastic LoadBalancers do not support websocket traffic when using layer 7/HTTP(S) based load balancing. To work around that,
tcp/4443 was added, so that ELB can use HTTP(S) mode on
tcp/443, and TCP mode on
tcp/4443. With cf-haproxy-boshrelease sitting behind ELB, you can continue to do this, and still gain the benefits of the ACLs. However, depending on your setup, you may even be able to stop using
Hold on! I'm using sslproxy-boshrelease - what about that?
However, there currently is no built-in support in sslproxy-boshrelease for customizable timeouts on websocket or tunneled connections. Additionally, it does not currently have support to listen on
tcp/4443. So, if you use websockets, you might prefer cf-haproxy-boshrelease.
Gee, thanks ProxyMan! But how do I implement cf-haproxy-boshrelease?
Tune in next week, same blog time, same blog channel to see our caped crusader cf-haproxy-boshrelease get itself added to an existing infrastructure!