Security Cloud Foundry后端和公共应用程序

在大多数解决方案中，有些应用程序应该是公共的，有些应用程序应该只能在内部访问

这种解决方案是否有经过验证的配置模式

执行此操作的简单方法可能是在同一CF组织中创建两个CF空间：

内部空间 此空间中的应用程序绑定到内部域，例如：*.my-internal-cf.cloud，指向内部负载平衡器 内部域是主共享域 内部负载平衡器无法从互联网访问，只能从云计算应用程序访问 内部空间可以访问备份服务cf安全组 公共空间： 此空间中的应用程序绑定到公共域，例如：*.my-pub-cf.cloud，指向公共负载平衡器 公共负载平衡器可以从Internet访问，并且只将流量传递到公共域 公共空间对支持服务的访问受限，甚至只能访问内部空间cf安全组的应用程序 这个配置安全吗

---

能更容易地完成吗？

这里使用orgs&spaces与公共/私人应用程序无关。Orgs&spaces用于内部组织您的应用程序，并通过cf cli限制对这些应用程序的访问。您可以使用对您的团队和公司有意义的任何结构

对于公开/私有应用程序，这完全取决于路由的使用。如果您想公开访问某个应用程序，请将公共路由绑定到该应用程序，即不是内部路由。如果您不希望某个应用程序是公共的，请绑定或根本不绑定路由。如果您绑定了内部路线，您可以使用或携带自己的路线，如Eureka或Consor。如果不绑定路由，您将通过服务（如消息代理）进行通信

---

您甚至可以通过控制容器到容器网络上两个应用程序之间的流量。这允许您根据类型和端口允许或限制流量。

谢谢@Daniel。此处组织和空间的使用与公共/私有应用程序无关-通常是的，但在所述配置中，来自内部空间的应用程序只有内部域/路由可用，因此只能成为内部应用程序。我知道这不是一个完美的解决方案，但它是稳定的。内部路由是我需要的功能，但它目前是实验性的。我可以在生产中使用它吗？什么时候会变得稳定？如果不使用内部路由功能，它就不是真正的内部路由。你可以添加一个像my-internal-cf.cloud这样的域，限制它可以解析的位置，甚至限制对你空间中的域的访问，但最终在该域上有路由的应用程序仍会将路由发布到Gorouter。只要有人知道内部路由，curl&一个伪造的主机头就可以欺骗Gorouter向您的准内部路由发送请求。使用内部路由功能会更好，因为Gorouter永远不会路由到仅内部的域。使用该域的唯一方法是从容器到容器的网络。如果安全和隔离是一个主要问题，那么使用内部路由功能就是一条出路。从PCF2.2开始，默认情况下会启用内部路由，因此它应该非常稳定。