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
communication.

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>
wrote:

Hi all,

Dr. Nic’s blog post [1] 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 [1] 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” [2] (what’s the status on this one, actually?)
and “Context Path Routing” [3] (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,
Bernd

[1]
https://blog.starkandwayne.com/2014/10/31/public-and-private-microservices-on-the-same-cloud-foundry
[2]
https://docs.google.com/document/d/1zQJqIEk4ldHH5iE5zat_oKIK8Ejogkgd_lySpg_oV_s/edit?usp=sharing
[3]
http://berlin2015.cfsummit.com/sites/berlin2015.cfsummit.com/files//pages/files/summit-berlin.pdf

Bernd Krannich
Products & Innovation Technology
SAP SE
Dietmar-Hopp-Allee 16
69190 Walldorf Germany
mailto:bernd.krannich(a)sap.com
www.sap.com

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(a)gmail.com