3

Kubernetes 上的 Istio 注入 Envoy sidecar 与 Pod 一起运行并实现服务网格，但是 Istio 本身无法确保流量不会绕过此代理；如果发生这种情况，则不再应用 Istio 安全策略。

因此，我试图了解这种绕过可能发生的所有方式（假设 Envoy 本身没有受到损害）并找到阻止它们的方法，以便保证来自 Pod 的网络命名空间的 TCP 流量已经通过 Envoy（或至少更有可能做到）：

  1. 由于（在撰写本文时）Envoy 不支持 UDP（它几乎就在那里），因此不会代理 UDP 流量，因此使用NetworkPolicy确保只允许进出 Pod 的 TCP 流量（例如，避免 TCP 流量被隧道传输通过 UDP 上的 VPN 输出）
  2. 删除 NET_ADMIN 功能以防止 Pod 在其网络命名空间中重新配置捕获流量的 IPTables 规则
  3. 删除 NET_RAW 功能以防止 Pod 打开原始套接字并绕过 IPTables 使用的 netfilter 挂钩点

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

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

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

4

2 回答 2

1

Envoy 并非旨在用作防火墙。依赖它的服务网格（例如 Istio 或 Cilium）仅在您可以绕过接收端的策略时才将其视为错误。

例如，任何 pod 都可以通过终止其自己的 Envoycurl localhost:15000/quitquitquit并在端口 15001 上启动一个自定义代理来轻松绕过任何 Istio 或 Cilium 策略，该代理允许在 Envoy 重新启动之前执行所有操作。

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

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

于 2019-11-21T12:50:29.427 回答
-1

Envoy 绕过起来相对简单，Cilium 就像 Istio 一样使用 envoy。所以它将无法阻止绕过特使的上游。

Istio和Cilium都有列出有关安全漏洞的 CVE 的网站。

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

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

Calico 还提供与 Istio 的无缝集成，以在 Istio 服务网格中实施网络策略。

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

更新：

为了澄清，我建议将 calico 用于零信任网络模型。如果没有它，您可能会在应用程序 pod 中与 envoy 混淆，因为它们与管理界面位于同一网络上。因此，锁定应用程序 pod 和管理界面之间的通信是至关重要的漏洞修复。

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

于 2019-11-20T16:39:51.293 回答