公布 Istio 首次安全评估结果

Istio 服务网格已在各种行业中得到广泛的生产应用。该项目的成功及其在基础设施中执行关键安全策略的关键作用，使得对与该项目相关的安全风险进行公开且中立的评估成为必要。

为了实现这一目标，Istio 社区去年委托NCC 集团对该项目进行第三方安全评估。审查的目标是“识别与 Istio 代码库相关的安全问题，突出管理员常用的高风险配置，并提供有关安全功能是否充分解决其旨在解决的问题的视角”。

NCC 集团在五周内完成了审查，并与 Istio 社区的主题专家进行了合作。在本篇博文中，我们将审查报告的主要发现、为实施各种修复和建议而采取的行动，以及我们持续安全评估和改进 Istio 项目的行动计划。您可以下载并阅读安全评估报告的完整版本。

范围和主要发现

评估全面评估了 Istio 的架构是否存在与安全相关的问题，重点关注 istiod（Pilot）、入口/出口网关以及 Istio 的整体 Envoy 用法（作为其数据平面代理）。此外，还对 Istio 文档（包括安全指南）进行了正确性和清晰度的审核。该报告是针对 Istio 1.6.5 版本编制的，从那时起，产品安全工作组已发布了多个安全版本，因为新漏洞被披露，并修复了新报告中提出的问题。

报告的一个重要结论是，审计人员在 Istio 项目中没有发现任何“严重”问题。这一发现证明了 Istio 产品安全工作组 (PSWG) 实施的持续且主动的安全审查和漏洞管理流程的有效性。对于报告中提出的其余问题，PSWG 致力于解决这些问题，我们很高兴地报告，所有标记为“高”的问题以及一些标记为“中/低”的问题已在报告发布后的版本中得到解决。

该报告还就创建强化指南提出了战略建议，该指南现已在我们的安全最佳实践指南中提供。这是一份综合性文档，汇集了 Istio 社区内安全专家以及在生产环境中运行 Istio 的行业领导者的建议。目前正在开展工作，为在安全环境中安装 Istio 创建一个有主见的强化安全配置文件，但在此期间，我们建议用户遵循安全最佳实践指南并配置 Istio 以满足其安全需求。有了这些，让我们看看对报告中提出的各种问题的分析和解决方案。

解决方案和经验教训

无法保护控制平面网络通信

该报告指出了 Istio 旧版本中提供的配置选项，用于控制如何保护与控制平面的通信。从 1.7 版本开始，Istio 默认情况下会保护所有控制平面通信，并且报告中提到的许多管理控制平面加密的配置选项不再需要。

报告中提到的调试端点默认情况下处于启用状态（从 Istio 1.10 开始），允许用户使用istioctl工具调试其 Istio 服务网格。如安全最佳实践指南中所述，可以通过将环境变量ENABLE_DEBUG_ON_HTTP设置为 false 来禁用它。此外，在即将发布的版本（1.11）中，此调试端点将默认情况下受到保护，并且需要有效的 Kubernetes 服务帐户令牌才能访问。

缺乏与安全相关的文档

该报告指出了 Istio 1.6 版本发布时发布的安全相关文档中的差距。从那时起，我们创建了一个详细的安全最佳实践指南，其中包含建议，以确保用户能够安全地部署 Istio 以满足其需求。展望未来，我们将继续使用更多强化建议来增强此文档。我们建议用户监控该指南以获取更新。

缺少 VirtualService 网关字段验证导致请求劫持

对于此问题，报告使用了一个有效但宽松的网关配置，这可能导致请求被错误路由。类似于 Kubernetes RBAC，Istio API（包括网关）可以根据您的需求进行调整以使其宽松或严格。但是，该报告揭示了我们的文档中缺少的链接，这些链接与最佳实践有关，并指导我们的用户保护其环境。为了解决这些问题，我们在安全最佳实践指南中添加了一个部分，其中包含安全运行网关的步骤。特别是，描述在网关资源的主机规范中使用命名空间前缀的部分强烈建议强化您的配置并防止此类请求劫持。

入口网关配置生成导致请求劫持

该报告在使用默认机制通过命名空间中的标签选择网关工作负载时提出了可能的请求劫持问题。选择此行为作为默认行为，因为它允许将管理网关和 VirtualService 资源的职责委派给应用程序团队，同时允许运营团队集中管理入口网关工作负载以满足其独特的安全需求，例如在专用节点上运行。如报告中所述，如果您的环境中不需要此部署拓扑，则强烈建议将网关资源与您的网关工作负载共置，并将环境变量PILOT_SCOPE_GATEWAY_TO_NAMESPACE设置为 true。

请参阅网关部署拓扑指南以了解 Istio 社区推荐的各种部署模型。此外，如安全最佳实践指南中所述，应使用 Kubernetes RBAC 或其他策略执行机制控制网关资源的创建权限，以确保只有授权实体才能创建它们。

其他中低严重性问题

有两个中级严重性问题报告与项目中各个级别公开的调试信息有关，这些信息可用于访问敏感信息或策划拒绝服务 (DOS) 攻击。虽然 Istio 默认情况下会启用这些调试接口以进行分析或启用“istioctl”等工具，但如上所述，可以通过将环境变量ENABLE_DEBUG_ON_HTTP设置为 false 来禁用它们。

该报告正确地指出，Istio 默认情况下提供的镜像中安装的各种实用程序（如sudo、tcpdump等）可能导致权限提升攻击。提供这些实用程序是为了帮助运行时调试流经网格的数据包，建议用户在生产环境中使用强化版本的这些镜像。

该报告还揭示了任何基于 sidecar 代理的服务网格实现（使用iptables拦截流量）的已知架构限制。此机制容易受到sidecar 代理绕过的影响，这对安全环境来说是一个合理的担忧。可以通过遵循安全最佳实践指南中的纵深防御建议来解决此问题。我们还在与 Kubernetes 社区合作研究更安全的选择。

实用性和安全性之间的权衡

您可能已经注意到评估结果和解决这些结果的建议中存在一种趋势。Istio 提供了各种配置选项，可以根据您的需求创建更安全的安装，并且我们为用户引入了全面的安全最佳实践指南。由于 Istio 在生产环境中被广泛采用，因此我们在切换到安全默认值和现有用户升级时可能遇到的迁移问题之间存在权衡。Istio 产品安全工作组会评估每个问题，并在为用户提供多个版本以选择安全配置并迁移其工作负载后，根据具体情况制定一个行动计划，以启用安全默认值。

最后，在进行中立的安全评估期间和之后，我们从中汲取了一些经验教训。主要的一点是确保我们的安全实践足够强大，以便能够快速响应发现的结果，更重要的是，在保持升级标准的同时进行安全增强，而不会造成中断。

为了继续这项工作，我们一直在寻求反馈并参与 Istio 产品安全工作组，因此加入我们的公开会议，提出问题或了解我们为保持 Istio 安全而采取的措施！