安全模型

8 分钟阅读

本文档旨在描述 Istio 各个组件的安全态势，以及可能的攻击如何影响系统。

组件

Istio 带有一些可选组件，本文档将对此进行介绍。有关高级概述，请参阅 Istio 架构。请注意，Istio 部署非常灵活；在下文中，我们将主要假设最坏情况。

Istiod

Istiod 充当 Istio 的核心控制平面组件，通常充当 XDS 服务组件以及网格 mTLS 证书颁发机构。

Istiod 被认为是一个高度特权的组件，类似于 Kubernetes API 服务器本身。

它具有很高的 Kubernetes RBAC 权限，通常包括 Secret 读取访问权限和 webhook 写入访问权限。
当充当 CA 时，它可以配置任意证书。
当充当 XDS 控制平面时，它可以对代理进行编程以执行任意行为。

因此，集群的安全性与 Istiod 的安全性紧密相关。遵循围绕 Istiod 访问的 Kubernetes 安全最佳实践至关重要。

Istio CNI 插件

Istio 可以选择与 Istio CNI 插件 DaemonSet 一起部署。此 DaemonSet 负责在 Istio 中设置网络规则，以确保流量根据需要透明地重定向。这是对下面讨论的 istio-init 容器的替代方案。

由于 CNI DaemonSet 修改节点上的网络规则，因此需要提升的 securityContext。但是，与 Istiod 不同，这是一个节点本地权限。此权限的影响将在下面讨论。

由于这将设置网络所需的提升权限集中到单个 Pod 中，而不是每个 Pod 中，因此通常建议使用此选项。

Sidecar 代理

Istio 可以选择在应用程序旁边部署一个 Sidecar 代理。

Sidecar 代理需要网络被编程为将所有流量通过代理重定向。这可以通过 Istio CNI 插件或在 Pod 上部署 initContainer (istio-init) 来实现（如果未部署 CNI 插件，则会自动执行此操作）。istio-init 容器需要 NET_ADMIN 和 NET_RAW 功能。但是，这些功能仅在初始化期间存在 - 主 Sidecar 容器完全没有权限。

此外，Sidecar 代理根本不需要任何关联的 Kubernetes RBAC 权限。

每个 Sidecar 代理都获准为关联的 Pod 服务帐户请求证书。

网关和中继代理

网关和 Waypoint 充当独立代理部署。与 Sidecar 不同，它们不需要任何网络修改，因此也不需要任何权限。

这些组件使用其自己的服务帐户运行，与应用程序标识区分开来。

Ztunnel

Ztunnel 充当节点级代理。此任务需要 NET_ADMIN、SYS_ADMIN 和 NET_RAW 功能。与 Istio CNI 插件一样，这些仅是节点本地权限。Ztunnel 没有任何关联的 Kubernetes RBAC 权限。

Ztunnel 获准为在同一节点上运行的任何 Pod 的服务帐户请求证书。类似于 kubelet，这明确不允许请求任意证书。这再次确保这些权限仅限于节点本地。

流量捕获属性

当 Pod 注册到网格中时，所有传入的 TCP 流量将被重定向到代理。这包括 mTLS/HBONE 流量和明文流量。在将流量转发到工作负载之前，将执行工作负载的任何适用的策略。

但是，Istio 目前不能保证传出流量会重定向到代理。请参阅流量捕获限制。因此，如果需要出站策略，则必须注意遵循保护出站流量步骤。

双向 TLS 属性

双向 TLS 为 Istio 的大部分安全态势提供了基础。以下解释了双向 TLS 为 Istio 的安全态势提供的各种属性。

证书颁发机构

Istio 自带自己的证书颁发机构。

默认情况下，CA 允许根据以下任一选项对客户端进行身份验证

Kubernetes JWT 令牌，其受众为 istio-ca，并使用 Kubernetes TokenReview 进行验证。这是 Kubernetes Pod 中的默认方法。
现有的双向 TLS 证书。
自定义 JWT 令牌，使用 OIDC 进行验证（需要配置）。

CA 仅会为客户端已对其进行身份验证的标识请求的证书颁发证书。

Istio 还可以与各种第三方 CA 集成；有关它们的行为方式的更多信息，请参阅其任何安全文档。

客户端 mTLS

在 Sidecar 模式下，客户端 Sidecar 将在连接到检测到支持 mTLS 的服务时自动使用 TLS。这也可以显式配置。请注意，此自动检测依赖于 Istio 将流量关联到服务。不支持的流量类型或配置范围会阻止此操作。

当连接到后端时，允许的标识集将在服务级别计算，基于所有后端标识的并集。

服务器 mTLS

默认情况下，Istio 将接受 mTLS 和非 mTLS 流量（通常称为“宽松模式”）。用户可以通过编写要求 mTLS 的 PeerAuthentication 或 AuthorizationPolicy 规则选择加入严格执行。

建立 mTLS 连接后，将验证对等方证书。此外，将验证对等方标识是否在同一信任域内。要验证仅允许特定标识，可以使用 AuthorizationPolicy。

探讨的受损类型

基于以上概述，我们将考虑如果系统的各个部分受到损害，对集群的影响。在现实世界中，任何安全攻击都存在各种不同的变量

执行的难易程度
需要哪些先前的权限
可以利用的频率
影响是什么（完全远程执行、拒绝服务等）。

在本文档中，我们将主要考虑最坏情况：受损组件意味着攻击者具有完全的远程代码执行能力。

工作负载受损

在这种情况下，应用程序工作负载（Pod）受到损害。

Pod 可能可以访问其服务帐户令牌。如果是这样，工作负载损害可以从单个 Pod 横向移动到损害整个服务帐户。

在 Sidecar 模型中，代理与 Pod 位于同一位置，并在相同的信任边界内运行。受损的应用程序可以通过 admin API 或其他界面（包括私钥材料的泄露）篡改代理，从而允许另一个代理模拟工作负载。应该假设受损的工作负载也包括 Sidecar 代理的损害。

鉴于此，受损的工作负载可能会

发送任意流量，无论是否使用双向 TLS。这些可能会绕过任何代理配置，甚至完全绕过代理。请注意，Istio 不提供基于出站的授权策略，因此不会发生出站授权策略绕过。
接受已发送到应用程序的流量。它可能会绕过在 Sidecar 代理中配置的策略。

这里的关键要点是，虽然受损的工作负载可能会恶意运行，但这并不会赋予它们绕过其他工作负载中的策略的能力。

Istio 提供了各种可以限制此类损害影响的功能

可观察性功能可用于识别攻击。
策略可用于限制工作负载可以发送或接收的流量类型。

代理受损 - Sidecar

在这种情况下，Sidecar 代理受到损害。由于 Sidecar 和应用程序位于同一信任域中，因此这在功能上等同于工作负载损害。

代理受损 - 中继代理

在这种情况下，Waypoint 代理受到损害。虽然 Waypoint 对黑客来说没有任何可利用的权限，但它们确实为许多不同的服务和工作负载提供服务（可能）。受损的 Waypoint 将接收所有这些流量，它可以查看、修改或丢弃这些流量。

Istio 提供了配置 Waypoint 部署粒度的灵活性。如果用户需要更强的隔离，可以考虑部署更多隔离的 Waypoint。

由于 Waypoint 使用与其服务应用程序不同的标识运行，因此受损的 Waypoint 并不意味着可以模拟用户的应用程序。

代理受损 - Ztunnel

在这种情况下，Ztunnel 代理受到损害。

受损的 Ztunnel 使攻击者能够控制节点的网络。

Ztunnel 可以访问其节点上每个正在运行的应用程序的私钥材料。受损的 Ztunnel 可以将这些材料泄露并用于其他地方。但是，无法横向移动到位于同一位置的工作负载之外的标识；每个 Ztunnel 仅被授权访问其节点上正在运行的工作负载的证书，从而限制了受损 Ztunnel 的影响范围。

节点受损

在此场景中，Kubernetes 节点遭到入侵。Kubernetes 和 Istio 都旨在限制单个节点入侵的爆炸半径，以确保单个节点的入侵不会导致集群范围的入侵。

但是，攻击者确实可以完全控制在该节点上运行的任何工作负载。例如，它可以入侵任何共置的Waypoint、本地Ztunnel、任何Sidecar、任何共置的Istiod 实例等。

集群（API 服务器）受损

Kubernetes API 服务器遭到入侵实际上意味着整个集群和网格都遭到入侵。与大多数其他攻击媒介不同，Istio 在控制此类攻击的爆炸半径方面能做的事情不多。被入侵的 API 服务器使黑客可以完全控制集群，包括在任意 Pod 上运行 kubectl exec、删除任何 Istio AuthorizationPolicies 甚至完全卸载 Istio 等操作。

Istiod 受损

Istiod 遭到入侵通常会导致与API 服务器入侵相同的结果。Istiod 是一个特权组件，应受到严格保护。遵循安全最佳实践对于维护安全集群至关重要。