Date
1 - 3 of 3
Internal/external domains
|
Krannich, Bernd <bernd.krannich@...>
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@...>
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, -- Matthew Sykes matthew.sykes(a)gmail.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. |
|
|