在Kubernetes上使用Istio时，如何确保TCP流量由特使侧车代理？

Kubernetes上的Istio注入一个特使侧车，与吊舱一起运行，并实现一个服务网格，然而Istio本身；如果发生这种情况，将不再应用Istio安全策略

因此，我试图了解这种绕过可能发生的所有方式（假设特使本身没有受到损害），并找到防止它们发生的方法，从而确保来自Pod网络名称空间的TCP流量通过特使（或者至少更有可能通过）：

由于（在撰写本文时）Environment不支持UDP（它的），UDP流量将不会被代理，因此使用确保只允许TCP流量进出Pod（例如，避免TCP流量通过UDP上的VPN隧道传输）

放弃NET_管理功能，以防止Pod重新配置其网络命名空间中捕获流量的IPTables规则

放弃NET_原始功能，以防止Pod打开原始套接字并绕过IPTables使用的netfilter挂钩点

<> P>唯一的其他攻击向量是内核漏洞，还有其他攻击吗？也许还有其他IPTables无法识别或忽略的L3/4协议

我知道它可以用于在套接字级别强制执行此拦截，但我对在Kubernetes上使用vanilla Istio的情况感兴趣

---

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

特使相对容易绕过，Cilium使用的特使与Istio一样。所以它无法阻止绕过特使的上游

两者都有列出CVE关于安全漏洞的网站

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

您可以使用来锁定通信，以便唯一流动的流量是您想要流动的流量

Calico还提供无缝连接，以在Istio服务网格内实施网络策略

当然，pods中的应用程序和服务的设计也应该考虑安全措施的最佳实践

---

更新：

为了澄清，我建议calico采用零信任网络模型。如果没有它，你可以从应用程序盒与特使弄乱，因为他们是在同一个网络作为管理界面。所以锁定应用程序盒和管理界面之间的通信是修复漏洞的关键

---

即使没有集群管理员权限，您也可以通过curl命令从应用程序pod影响特使。

特使不是设计用来作为防火墙的。依赖于它的服务网格，例如ISTIO或纤毛，只考虑它可以是一个bug，如果你可以绕过接收端的策略。 例如，任何pod都可以通过使用

curl localhost:15000/quitquitquit

终止其自己的特使，并在端口15001上启动一个自定义代理来绕过任何Istio或Cilium策略，该代理允许在特使重新启动之前执行所有操作

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

---

如果您希望安全策略实际上在启动连接时结束，而不仅仅是在接收端上，请考虑使用它作为设计目标的网络策略实现，例如Calico。

我不认为这一切都是正确的或相关的1）Cilium的CNI插件通过拦截TCP套接字创建，确实有助于防止绕过使用eBPF和sockmaps（参见链接视频）2）您引用的CVE已被修复3）如果您没有权限，并且没有严重的k8s漏洞，则无法将权限提升到群集管理（无论如何，在这种情况下，您会遇到更严重的问题）-我指的是没有API服务器访问权限的正常工作负载（本应澄清，但从列出的攻击中可以清楚看出）4）Calico不是唯一的网络策略实施Afaik您可以使用Cilium来实施Kubernetes网络策略，该策略可以将允许的流量白名单到特定的POD，限制到特定的端口，与服务网格的操作无关。（）您链接的示例可能有效，因为策略是在连接的接收端强制执行的。我不是百分之百确定纤毛，但有了Istio，你绝对不能依靠你的吊舱使者来执行任何事情。（来源：我和一位Istio开发人员谈过这个问题）。这很好

curl-X POST 127.0.0.1:15000/quitQuit

为我禁用代理。我觉得这一点/可能性应该在文档中明确（至少我以前没有遇到过）。