安全模型
本文档旨在描述 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 不同，这是一种 node-local 权限。
此权限的含义将在下文中讨论。
因为这将设置网络所需的提升权限整合到单个 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 服务账户请求证书。
Gateway 和 waypoint
Gateway 和 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）。
默认情况下，CA 允许根据以下任一选项对客户端进行身份验证：
- Kubernetes JWT 令牌，受众为
istio-ca，使用 KubernetesTokenReview进行验证。 这是 Kubernetes Pod 中的默认方法。 - 现有的双向 TLS 证书。
- 自定义 JWT 令牌，使用 OIDC 进行验证（需要配置）。
CA 只会颁发针对客户端已验证身份而请求的证书。
Istio 还可以与各种第三方 CA 集成；有关其行为方式的更多信息，请参阅其安全文档。
客户端 mTLS
在 Sidecar 模式下，客户端 Sidecar 在连接到检测到支持 mTLS 的服务时将自动使用 TLS。 这也可以显式配置。 请注意，此自动检测依赖于 Istio 将流量与服务关联。 不支持的流量类型或配置范围可能会阻止这种情况。
当连接到后端时， 允许的身份集是在服务级别基于所有后端身份的联合来计算的。
在 Ambient 模式下，Istio 将在连接到任何支持 mTLS 的后端时自动使用 mTLS， 并验证目标的身份是否与预期运行工作负载的身份相匹配。
这些属性与 Sidecar 模式的不同之处在于，它们是单个工作负载的属性，而不是服务的属性。 这样可以实现更细粒度的身份验证检查，并支持更多种类的工作负载。
服务器 mTLS
默认情况下，Istio 将接受 mTLS 和非 mTLS 流量（通常称为“宽容模式”）。
用户可以通过编写需要 mTLS 的 PeerAuthentication 或 AuthorizationPolicy 规则来选择严格执行。
建立 mTLS 连接后，将验证对等证书。此外，还将验证对等身份是否在同一信任域内。
要验证仅允许特定身份，可以使用 AuthorizationPolicy。
探索妥协类型
基于以上概述，我们将考虑系统各个部分受到攻击时对集群的影响。 在现实世界中，任何安全攻击都存在各种不同的变量：
- 执行起来有多容易
- 需要哪些先前权限
- 被利用的频率
- 影响是什么（完全远程执行、拒绝服务等）。
在本文中，我们将主要考虑最坏的情况：组件被破坏意味着攻击者拥有完整的远程代码执行能力。
工作负载妥协
在这种情况下，应用程序工作负载（Pod）受到影响。
Pod 可能有权访问其服务帐户令牌。 如果是这样，工作负载入侵可能会从单个 Pod 横向扩展到入侵整个服务帐户。
在 Sidecar 模型中，代理与 Pod 位于同一位置，并在同一信任边界内运行。 被入侵的应用程序可以通过管理 API 或其他界面篡改代理，包括泄露私钥材料， 从而允许另一个代理冒充工作负载。应该假设被入侵的工作负载还包括对 Sidecar 代理的入侵。
鉴于此，受损的工作负载可能会：
- 发送任意流量，无论是否使用双向 TLS。这些流量可能会绕过任何代理配置， 甚至完全绕过代理。请注意，Istio 不提供基于出口的授权策略，因此不会发生出口授权策略绕过。
- 接受已经发往应用程序的流量。它可能会绕过在 Sidecar 代理中配置的策略。
这里的关键点是，虽然受损的工作负载可能表现恶意，但这并不意味着它们能够绕过其他工作负载中的策略。
在 Ambient 模式下，节点代理不与 Pod 位于同一位置，而是作为独立 Pod 的一部分在另一个信任边界中运行。
受感染的应用程序可能会发送任意流量。但是，它们无法控制节点代理，而节点代理将选择如何处理传入和传出流量。
此外，由于 Pod 本身无法访问服务帐户令牌来请求相互 TLS 证书，因此横向移动的可能性降低了。
Istio 提供了多种功能来限制此类攻击的影响：
代理妥协 - Sidecars
在此场景中，Sidecar 代理被攻陷。由于 Sidecar 和应用程序位于同一信任域中， 因此这在功能上等同于工作负载攻陷。
代理妥协 - Waypoint
在这种情况下，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 是一个高权限组件，应受到强力保护。 遵循安全最佳实践对于维护安全集群至关重要。