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

Question

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

因此，我试图理解发生这种旁路的所有方式（假设Envoy本身并未受到损害），并找到防止它们发生的方法，以确保源自Pod网络名称空间的TCP流量已通过Envoy （或者至少更有可能这样做）：

1. 由于（在撰写本文时）Envoy不支持UDP（它为nearly there），因此将不代理UDP流量，因此请使用NetworkPolicy确保仅允许TCP流量往返于Pod（例如，避免通过UDP上的VPN通过TCP隧道传输TCP流量）
2. 丢弃NET_ADMIN功能以防止Pod在其捕获流量的网络名称空间中重新配置IPTables规则
3. 丢弃NET_RAW功能以防止Pod打开原始套接字并绕过IPTables使用的netfilter挂钩点

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

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

Answer 1

Envoy相对容易绕开，Cilium像Istio一样使用Envoy。因此它将无法防止绕过特使的上游。

Istio和Cilium都具有有关安全漏洞的CVE。

在控制平面内，可以通过注释影响sidecar注入或iptables规则，因此一旦有人获得了群集管理员特权，就无法防御。

唯一有效的工具是使用calico来锁定通信，因此，唯一流动的流量就是您想要流动的流量。

Calico还提供了无缝的integration with Istio以在Istio服务网格内实施网络策略。

当然，在吊舱中的应用程序和服务当然也应考虑安全措施的最佳实践。