将内部网络上的端口暴露给 Internet 的安全考虑
Security considerations exposing ports on internal network to internet
我们目前设置了带有内部网络和 DMZ 网络的 VM 环境。从历史上看，我们在这些环境之间没有开放端口，但需要在互联网和我们内部服务器上的 services/APIs 运行 之间进行通信。
我们决定将我们的 DMZ 网络用作 proxy/gateway，我们专门使用 Kong 网关，将端口 80/443 暴露给互联网，然后 proxying/forwarding 通过打开的不同端口发出请求在 DMZ 服务器和需要处理此通信的特定内部服务器之间。 DMZ 服务器和我们内部网络之间的 all 请求使用了一个随机的、非标准的高端口，然后我们在内部服务器上使用反向代理来路由特定请求内部服务器上特定 APIs/services 的主机名。
现在，我们正在将内部环境转换为 k8s 集群，我很想知道如果我们放弃 DMZ，安全性是否会有任何“真正的”差异代理，并将端口 80/443 直接从互联网公开到我们的内部 k8s 集群，并通过我们集群上的入口控制器处理所有 security/authentication/authorization。
没有这个 DMZ 代理 运行。
根据我的理解，DMZ 代理的目的是如果链中发生漏洞，如果漏洞仅在 DMZ 服务器上，进一步渗透我们的内部网络将更加困难。但我的网络和安全知识不足以判断这是否真的是真的，它只是提供了一种额外安全的错误感觉，在这种情况下，我们将拥有与直接公开这些相同端口完全相同的安全级别我们内部的 k8s 集群，同时简化了整体基础设施。
if there'd be any "real" difference to security, if we were to forego the DMZ proxy, and exposing ports 80/443 directly from the internet to our internal k8s cluster, and handle all the security/authentication/authorization through the ingress controller on our cluster.
It would simplify our infrastructure a decent bit, to not have this DMZ proxy running.
您可能需要集群外部的“网关”，具有静态 IP 地址。集群中的节点比较动态，你想在升级时扔掉旧的并创建新的，例如linux 内核。
From my understanding the purpose of the DMZ proxy was that if a breach were to happen in the chain, it would be much harder to further penetrate our internal network, if the breach was only on the DMZ server.
本书Zero Trust Networks is good about this. Things has changed, the older way of using "DMZ" to protect internal networks, called "perimeter security" is now replaced with a "Zero Trust Networking" model. Now every host (or Pod) should be responsible for its security, on Kubernetes, to get this hardened, you can use a "Service Mesh" to implement mutual TLS between all services, see e.g. istio。
我们目前设置了带有内部网络和 DMZ 网络的 VM 环境。从历史上看，我们在这些环境之间没有开放端口，但需要在互联网和我们内部服务器上的 services/APIs 运行 之间进行通信。
我们决定将我们的 DMZ 网络用作 proxy/gateway，我们专门使用 Kong 网关，将端口 80/443 暴露给互联网，然后 proxying/forwarding 通过打开的不同端口发出请求在 DMZ 服务器和需要处理此通信的特定内部服务器之间。 DMZ 服务器和我们内部网络之间的 all 请求使用了一个随机的、非标准的高端口，然后我们在内部服务器上使用反向代理来路由特定请求内部服务器上特定 APIs/services 的主机名。
现在，我们正在将内部环境转换为 k8s 集群，我很想知道如果我们放弃 DMZ，安全性是否会有任何“真正的”差异代理，并将端口 80/443 直接从互联网公开到我们的内部 k8s 集群，并通过我们集群上的入口控制器处理所有 security/authentication/authorization。
没有这个 DMZ 代理 运行。
根据我的理解，DMZ 代理的目的是如果链中发生漏洞，如果漏洞仅在 DMZ 服务器上，进一步渗透我们的内部网络将更加困难。但我的网络和安全知识不足以判断这是否真的是真的，它只是提供了一种额外安全的错误感觉，在这种情况下，我们将拥有与直接公开这些相同端口完全相同的安全级别我们内部的 k8s 集群，同时简化了整体基础设施。
if there'd be any "real" difference to security, if we were to forego the DMZ proxy, and exposing ports 80/443 directly from the internet to our internal k8s cluster, and handle all the security/authentication/authorization through the ingress controller on our cluster.
It would simplify our infrastructure a decent bit, to not have this DMZ proxy running.
您可能需要集群外部的“网关”，具有静态 IP 地址。集群中的节点比较动态，你想在升级时扔掉旧的并创建新的，例如linux 内核。
From my understanding the purpose of the DMZ proxy was that if a breach were to happen in the chain, it would be much harder to further penetrate our internal network, if the breach was only on the DMZ server.
本书Zero Trust Networks is good about this. Things has changed, the older way of using "DMZ" to protect internal networks, called "perimeter security" is now replaced with a "Zero Trust Networking" model. Now every host (or Pod) should be responsible for its security, on Kubernetes, to get this hardened, you can use a "Service Mesh" to implement mutual TLS between all services, see e.g. istio。