【问题标题】:Cloud Foundry back-end and public appsCloud Foundry 后端和公共应用程序
【发布时间】:2018-07-19 12:31:59
【问题描述】:

在大多数解决方案中,一些应用程序应该是公开的,而一些应用程序应该仅供内部访问。

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

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

  • internal space
    • 此空间中的应用程序绑定到指向internal load-balancerinternal domain(例如:*.my-internal-cf.cloud)
    • internal domain 是主要共享域
    • internal load-balancer 无法从 Internet 访问,只能通过 Cloud Foundry 的应用访问
    • internal space 可以访问支持服务(参见安全组)
  • public space:
    • 此空间中的应用程序绑定到指向public load-balancerpublic domain(例如:*.my-pub-cf.cloud)
    • public load-balancer 可从 Internet 访问,并且仅将流量传递到 public domains
    • public space 对支持服务的访问权限有限,甚至只能访问来自internal space 的应用程序(参见安全组)

此配置安全吗?

可以更轻松地完成吗?

【问题讨论】:

    标签: security microservices cloud-foundry 12factor


    【解决方案1】:

    此处对组织和空间的使用与应用的公开/私有无关。组织和空间用于在内部组织您的应用程序并通过 cf cli 限制对这些应用程序的访问。您可以使用对您的团队和公司有意义的任何结构。

    要使应用程序公开/私有,这完全取决于路由的使用。如果您想公开访问应用程序,则将公共路由绑定到应用程序(即不是内部路由)。如果您不希望应用程序公开,请绑定internal route 或根本不绑定路由。如果绑定内部路由,可以使用the platform's DNS-based discovery,也可以自带,比如Eureka或者Consul。如果您不绑定路由,您将通过服务进行通信,例如消息代理。

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

    【讨论】:

    • 谢谢@Daniel。 “这里的组织和空间的使用与应用程序的公共/私有无关” - 通常是的,但在描述的配置中来自内部空间的应用程序只有内部域/路由可用,因此仅限内部。我知道这不是一个完美的解决方案,但很稳定。 “内部路由”是我需要的功能,但它目前是实验性的。我可以在生产中使用它吗?什么时候稳定?
    • 如果您不使用内部路由功能,它就不是真正的内部路由。您可以添加像my-internal-cf.cloud 这样的域,限制可以解析的位置,甚至限制对空间中域的访问,但最终在该域上具有路由的应用程序仍会将路由发布到 Gorouter。只需有人知道内部路由,curl 和伪造的Host 标头即可欺骗 Gorouter 向您的准内部路由之一发送请求。
    • 使用内部路由功能会更好,因为 Gorouter 永远不会路由到仅限内部的域。使用该域的唯一方法是从容器到容器网络。如果安全和隔离是首要考虑的问题,那么使用内部路由功能就是要走的路。从 PCF 2.2 开始,默认启用内部路由,因此它应该相当稳定。
    猜你喜欢
    • 2016-06-04
    • 2012-09-20
    • 1970-01-01
    • 1970-01-01
    • 2019-10-19
    • 1970-01-01
    • 2013-03-24
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多