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 (e.g: *.my-internal-cf.cloud) that points the internal load-balancerinternal domain is main shared domaininternal load-balancer isn't accessible from the Internet, can be accessible only for apps from the Cloud Foundryinternal space has access to the backing-services (cf security-groups)public space:
public domain (e.g: *.my-pub-cf.cloud) that points the public load-balancerpublic load-balancer is accessible from the Internet and passing only traffic to the public domainspublic 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 (i.e. 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.