In most solutions some apps should be public and some should be internal-only accessible.
Is there a proven configuration pattern of such a solution?
The simple way to do this may be to create two CF spaces (in the same CF organization):
internal space
internal domain
(eg: *.my-internal-cf.cloud) that points the internal load-balancer
internal domain
is main shared domain internal load-balancer
isn't accessible from the Internet, can be accessible only for apps from the Cloud Foundry internal space
has access to the backing-services (cf security-groups) public space
:
public domain
(eg: *.my-pub-cf.cloud) that points the public load-balancer
public load-balancer
is accessible from the Internet and passing only traffic to the public domains
public space
has limited access to the backing-services or even has only access to apps from the internal space
(cf security-groups) Is this configuration secure?
Can it be done more easily?
The use of orgs & spaces here is irrelevant to an app being public/private. Orgs & spaces are for internally organizing your apps and limiting access to those through the cf cli. You can use whatever structure makes sense for your team & company.
For making an app public/private, it all depends on the use of routes. If you want public access to an app, you bind a public route to the app (ie not an internal route). If you do not want an app to be public either bind an internal route or don't bind a route at all. If you bind an internal route, you can use the platform's DNS-based discovery or bring your own, like Eureka or Consul. If you don't bind a route you would communicate through a service, like a message broker.
You can even control the traffic between two apps on the container-to-container network via policies . This allows you to allow or restrict traffic based on type & port.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.