Krannich, Bernd <bernd.krannich@...>
Dr. Nic’s blog post  addresses a requirement that we keep hearing frequently: To have certain applications that can only be accessed from other apps running in the same Cloud Foundry deployment.
I wanted to check with the community here to see if anybody has come across this requirement as well. Is this something one should actually be advocating in terms of architecture?
Also, the solution suggested in  in our opinion is prone to bypassing if implemented in the described way (see top-most comment in the same blog post). Of course, one could work around that by terminating SSL at the two load balancers, introspecting the header fields there. On the other hand, this requires a much more complex “internal/external” DNS setup.
A logical next step would be to extend the requirement to only allow calls from apps being deployed into certain orgs and spaces. This can no longer be achieved by a setup “external” to CF given that apps from all types of orgs and spaces are usually deployed on the very same runners with calls being “indistinguishable” once a call has left the runner.
As alternatives, we came up with the following potential options:
1. Avoiding the notion of “private” services altogether, making sure that each application is secured by - for example - a JWT token carrying a shared secret.
2. Using messaging via a backing service instead of HTTP-based communication.
3. Recently suggested/implemented CF functionality like “container networking for applications”  (what’s the status on this one, actually?) and “Context Path Routing”  (this was discussed on the mailing list some time back, even though I’m not sure how you would actually use it to solve the above scenario). Is any of that allowing to implement the above requirement?
Any thoughts, opinions, suggestions are welcome.
Thanks in advance,
Products & Innovation Technology
69190 Walldorf Germany
Pflichtangaben/Mandatory Disclosure Statements: http://www.sap.com/company/legal/impressum.epx
Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.
This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.
Matthew Sykes <matthew.sykes@...>
Container networking is aimed at your requirement. Once it's ready, you
would deploy your apps without external routes and rely on the private
network for communication.
We expect we'll have facilities in place to find apps via a DNS
implementation using app names or services names but we''re beginning to
move in a direction where apps are associated with explicit service names
that are orthogonal to the app name. We may also adopt a VIP pattern for
services to remove the need name resolution entirely.
For status, we have containers talking via n overlay with guardian and
we're in the process of integrating with diego. We hope to demonstrate what
we have at summit. It will be a while before things are "baked" but the
project exists and we're moving forward.
Finally, there are plans to implement several policy controls around
endpoint communication that enable users to express a supported
connectivity graph without relying on apps living in the same space for
Hope that helps. Let us know if you have more questions.
On Thu, Apr 7, 2016 at 1:28 AM, Krannich, Bernd <bernd.krannich(a)sap.com>
Geoff Franks <geoff@...>
We built the cf-haproxy-boshrelease for this (https://github.com/cloudfoundry-community/cf-haproxy-boshrelease). Check out https://blog.starkandwayne.com/2015/06/17/securing-private-domains-on-a-public-cloudfoundry/ for more details. The feature-set has been updated quite a bit since that post. It now supports enough features that should allow it to work behind tcp or http-mode load balancers (you can force x-forwarded-proto if behind a tcp-only loadbalancer that does ssl termination), handle websockets on standard http ports, serve multiple ssl certs, and do generic tcp proxying for things like app-ssh.
My ideal setup would be a set of http-mode load balancers in front of the 'public_haproxy_z*' nodes, which would filter out non-allowed domains, and send the remaining requests to the gorouters. For internal-only requests, I'd use a non-public http-mode load balancer directly in front of the gorouters.