将内部网络上的端口暴露给internet的安全性考虑
我们目前有一个内部网络和DMZ网络的VM环境设置。历史上，我们在这些环境之间没有开放的端口，但是需要在internet和运行在我们内部服务器上的服务/API之间进行通信。
我们决定使用DMZ网络作为代理/网关，具体使用Kong网关，将端口80/443暴露在互联网上，然后通过DMZ服务器和需要处理此通信的特定内部服务器之间打开的不同端口代理/转发请求。DMZ服务器和内部网络之间的所有请求都使用一个随机、非标准的高端口，然后我们在内部服务器上使用反向代理将特定请求通过主机名路由到内部服务器上的特定API/服务。
现在，我们正在将我们的内部环境转换为一个k8s集群，我想知道安全性是否有“真正的”区别，我们是否要放弃DMZ代理，直接将端口80/443从互联网公开到我们的内部k8s集群，并通过集群上的入口控制器处理所有的安全/身份验证/授权。
如果不运行这个DMZ代理，这将简化我们的基础设施。
根据我的理解，DMZ代理的目的是，如果要在链中发生漏洞，那么要进一步渗透我们的内部网络就会困难得多，如果该漏洞只发生在DMZ服务器上。但我的网络和安全知识还不足以说明这是否真的是真的，它只是提供了一种虚假的额外安全感，在这种情况下，我们将有完全相同的安全级别，直接暴露在我们的内部k8s集群中，同时简化了整个基础设施。
回答 1
Stack Overflow用户
发布于 2021-05-06 20:38:51
如果安全性有任何“真正的”区别，如果我们放弃DMZ代理，直接将端口80/443从internet公开到我们的内部k8s集群，并通过集群上的入口控制器处理所有安全/身份验证/授权。如果不运行这个DMZ代理，这将简化我们的基础设施。
您可能需要集群外的“网关”，具有静态IP地址。集群中的节点更动态，您希望在升级时丢弃旧节点并创建新节点，例如linux内核。
根据我的理解，DMZ代理的目的是，如果要在链中发生漏洞，那么要进一步渗透我们的内部网络就会困难得多，如果该漏洞只发生在DMZ服务器上。
这本书零信任网络对此很在行。事情变了，用"DMZ“来保护内部网络的旧方式，称为”周边安全“，现在被”零信任网络“模式所取代。现在，每个主机(或者Pod)都应该对其安全性负责，在Kubernetes上，为了增强这种安全性，您可以使用一个“服务网格”来实现所有服务之间的互TLS，例如伊蒂奥。
https://stackoverflow.com/questions/67425309
复制相似问题
腾讯云开发者
