保障 Istio 安全：解决关键安全漏洞及最佳实践

本文为 Jimmy Song 原创。转载请注明来源： https://jimmysong.io/blog/securing-istio-addressing-critical-security-gaps-and-best-practices/

查看本文大纲

引言

近期，Wiz 研究团队发布了博客，揭示了 AI 服务中的租户隔离漏洞，引起了广泛关注。该研究详细阐述了多个 AI 服务供应商存在的安全缺陷，特别是 SAP AI Core 平台。通过合法的 AI 训练过程，研究人员能够绕过 Istio 服务网格中的流量劫持，进而横向移动并接管服务，获取客户的私人文件和云环境凭证。这些发现凸显了当今云服务和管理平台在确保隔离和沙盒环境方面面临的挑战。

关于 UID 1337

Istio 选择 UID 1337（leet 的变体）作为 istio-proxy 容器中的用户 ID 是为了便于配置并避免权限冲突。这个数字在技术和游戏文化中象征“精英”（elite），有助于防止与其他常规用户 ID 冲突，确保流量管理操作不受权限问题干扰。

在这个背景下，Istio 作为一个重要的服务网格解决方案，同样面临着类似的安全问题，尤其是在 sidecar 注入和流量管理等关键功能上。这篇博客旨在探讨如何保护 Istio 服务网格的安全，并提供一套全面的缓解措施。我们还将讨论多层安全策略如何有效增强 Istio 的安全性，以应对类似 Wiz 报告中提到的挑战。

概述

Istio 主要用于管理 Kubernetes 中的东西向流量，提供详细的流量管理功能，如请求路由、负载均衡和故障恢复策略。虽然 Istio 提供了流量加密、认证和授权等安全功能，但它本身不应被视为防火墙。为了确保 Istio 网格中的服务安全，除了使用 Istio 自身的安全功能，还需要结合底层网络和基础设施的安全措施，比如 CNI 和安全容器。此外，微分段技术可以用来实现更细粒度的隔离，提高安全性。

不论是 Sidecar 模式还是 Ambient 模式，都是通过劫持应用程序 Pod 的流量到数据平面代理中进行处理和转发的。如果没有成功拦截到应用程序流量或者被仿冒程序冒充了 Istio 而执行操作，就会有安全漏洞出现。

下图展示了通过绕过或仿冒 Istio 系统用户而造成的安全漏洞存在的位置。

接下来，我们将探讨“安全漏洞”产生的具体情况及应对策略。

绕过 Istio Sidecar 注入

在命名空间级别禁用注入

场景：应用团队滥用命名空间标签，在命名空间级别禁用 Istio Sidecar 注入。
缓解策略：平台团队抽象化应用部署，限制对原始 Kubernetes 命名空间资源的访问。
监控：使用策略引擎（如 OPA Gatekeeper）来确保命名空间标签的合规性，定期审查命名空间的配置。

在 Pod 级别禁用注入

场景：应用团队滥用 Pod 标签，在 Pod 级别禁用 Istio Sidecar 注入。
缓解策略：平台团队抽象化应用部署，限制对原始 Kubernetes Pod 资源的访问。
监控：使用 Admission Webhook 强制启用 Sidecar 注入，禁止使用排除标签，定期扫描和审计所有 Pod，确保所有需要的 Pod 都注入了 Sidecar。

绕过流量重定向到 Istio Sidecar

滥用流量重定向注解

场景：应用团队滥用 Pod 注解，排除特定的入站或出站端口或 IP 地址，从而绕过流量重定向。
缓解策略：平台团队抽象化应用部署，限制对原始 Kubernetes Pod 资源的访问。
监控：使用策略引擎来检测和警告不合规的注解使用，定期审查 Pod 注解。

滥用 Pod 的 UID

场景：应用团队滥用 UID 1337（sidecar 代理的 ID），绕过 Istio Iptables 重定向规则。
缓解策略：
- 强制所有 Pod 指定非 1337 的 UID。
- 检查所有容器镜像以检查 UID 1337 并拒绝这些镜像。此检查可以使用准入 Webhook 或由管理镜像注册表的中央团队来执行。
监控：禁用或限制 UID 1337 的使用，定期审计 Pod 的 UID 配置，确保没有绕过行为。

滥用 Pod 能力（NET_ADMIN、NET_RAW）

场景：应用团队滥用 NET_ADMIN 和 NET_RAW 能力，移除 Istio Iptables 规则。
缓解策略：平台团队启用 Istio CNI（以避免授予应用团队提升的权限），并限制对原始 Kubernetes Pod 资源的访问。
监控：定期审查和监控 Pod 的权限配置，确保没有越权行为。

绕过入站流量约束

滥用 PeerAuthentication

场景：应用团队创建一个针对每个命名空间/每个工作负载的 PeerAuthentication 资源，启用 PERMISSIVE 认证模式。
缓解策略：平台团队限制对原始 Istio PeerAuthentication 资源的访问。
监控：定期审查 PeerAuthentication 配置，确保所有入站流量都按照要求加密。

绕过出站流量约束

滥用 ServiceEntry

场景：应用团队创建一个 ServiceEntry，直接访问外部服务，而无需经过 Egress 网关。
缓解策略：平台团队限制对原始 Istio ServiceEntry 资源的访问。
监控：定期审查 ServiceEntry 配置，确保没有绕过行为。

滥用 ExternalName 服务

场景：应用团队创建一个类型为 ExternalName 的 Kubernetes Service，直接访问外部服务，而无需经过 Egress 网关。
缓解策略：平台团队限制对原始 Kubernetes Service 资源的访问。
监控：定期审查 Kubernetes Service 的类型配置，确保没有绕过行为。

无法控制地更改 Istio Sidecar 配置

滥用 Sidecar 资源

场景：应用团队创建一个针对每个工作负载的 Istio Sidecar 资源，并将 outboundTrafficPolicy 字段设置为 ALLOW_ANY（覆盖可能的全局值 REGISTRY_ONLY）。
缓解策略：平台团队限制对原始 Istio Sidecar 资源的访问。
监控：定期审查 Sidecar 资源配置，确保没有覆盖全局设置的行为。

滥用 EnvoyFilter

场景：应用团队创建 EnvoyFilter，导致与现有 Istio 对象冲突，从而引发 DoS 攻击或违反安全策略。
缓解策略：平台团队限制对原始 Istio EnvoyFilter 资源的访问。
监控：定期审查 EnvoyFilter 配置，确保没有不当使用行为。

服务网格应作为分层防御的一部分

服务网格被描述为现有安全模型的一个补充层，通过在传统安全控制之上添加更细粒度的安全策略来增强微服务的安全性。然而，文章强调了服务网格无法独立保障微服务的全面安全，而是应当作为整体安全策略的一部分。

服务网格主要通过在每个服务实例旁部署一个轻量级的代理（sidecar），来管理和控制网络流量。这使得它能够在网络层面上实现精细的流量控制和策略执行，如流量加密、身份认证和授权。尽管服务网格能够提供诸如流量控制、服务发现和断路器等功能，这些功能本质上是对网络流量的管理，无法解决所有安全问题。例如，它不能替代应用层防火墙、入侵检测系统和数据安全等更传统的安全措施。

此外，服务网格依赖于正确的配置和管理，配置不当可能导致安全漏洞。因此，尽管服务网格是现代微服务架构中不可或缺的一部分，它应该与传统的安全措施相结合，共同构成一个全面的、多层次的安全策略框架。参考如何通过服务网格增强微服务的安全性以进一步了解如何加强服务网格的安全。

长期解决方案和社区合作

Istio 社区每年都会进行一次安全审计，见 2021 年、2022 年的安全审计结果。从结果中我们可以看到，Istio 的安全态势有了很大的提升。确保你的 Istio 服务网格符合安全最佳实践。另外，你还需要关注 Istio CVE 公告栏，或者使用如 Tetrate Istio Subscription 这类工具来扫描 Istio 服务网格的各种 CVE，部署符合 FIPS 并经过 FIPS 验证的 Istio 发行版。

结论

服务网格通过在应用程序外部管理控制流，为微服务架构提供了额外的安全层。这允许在不影响应用程序性能的前提下，加强服务之间的通信安全。在部署服务网格时，推荐使用 Istio 的 Egress Gateway 来管理出口流量，结合 Kubernetes 的 NetworkPolicy，确保所有出口流量都必须经过网关，从而防止潜在的数据泄露和其他安全威胁。