kubernetes - 在Kubernetes上使用Istio时，如何确保Envoy边车代理TCP流量？

Kubernetes上的Istio注入(inject)了一个Envoy边车来与Pods一起运行并实现服务网格，但是Istio本身为cannot ensure traffic does not bypass this proxy；如果发生这种情况，将不再应用Istio安全策略。

因此，我试图理解发生这种旁路的所有方式(假设Envoy本身并未受到损害)，并找到防止它们发生的方法，以确保源自Pod网络 namespace 的TCP流量已通过Envoy(或至少更有可能完成):

由于(在撰写本文时)Envoy不支持UDP(即nearly there)，因此不会代理UDP流量，因此请使用NetworkPolicy确保仅允许TCP流量往返Pod(例如，避免隧道传输TCP流量)通过UDP通过VPN断开连接)

删除NET_ADMIN功能以防止Pod在其网络 namespace 中重新配置IPTables规则以捕获流量

删除NET_RAW功能以防止Pod打开原始套接字并绕过IPTables使用

的netfilter挂钩点

我知道的唯一其他攻击媒介是内核漏洞-还有其他漏洞吗？也许还有IPTables无法识别或忽略的其他L3 / 4协议(protocol)？

我知道eBPF and Cilium可用于在套接字级别强制执行此拦截，但是我对在Kubernetes上使用 Vanilla Istio的情况感兴趣。

编辑:我还假设工作负载没有Kubernetes API服务器访问权限

最佳答案

Envoy并非旨在用作防火墙。如果可以绕过接收端的策略，则依赖它的服务网格(例如Istio或Cilium)只会将其视为错误。

例如，任何Pod都可以通过用curl localhost:15000/quitquitquit终止其自己的Envoy并在允许重新启动Envoy之前允许所有操作的端口15001上启动自定义代理，来略过任何Istio或Cilium策略。

您可以修补该特定漏洞，但是由于抵制此类攻击不是服务网格的设计目标，因此可能有数十种其他方法可以完成同一任务。后续版本中也可能会添加绕过这些策略的新方法。

如果要在发起连接的一端而不是仅在接收端实际实施安全策略，请考虑使用网络策略实现作为设计目标，例如Calico。

关于kubernetes - 在Kubernetes上使用Istio时，如何确保Envoy边车代理TCP流量？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/58952861/