Cloud Service Mesh 安全最佳实践

本文档介绍了确定和管理 Google Kubernetes Engine (GKE) 上运行的安全 Cloud Service Mesh 配置的最佳实践。本文档中的指导不仅介绍了用于配置和安装 Cloud Service Mesh 的设置，并且还介绍了如何将 Cloud Service Mesh 与其他 Google Cloud 产品和功能搭配使用，以应对网格中的应用可能面临的安全威胁。

本文档的目标受众群体包括在 Cloud Service Mesh 中管理政策的管理员，以及在 Cloud Service Mesh 中运行服务的用户。对于需要增强服务网格安全性以满足合规性要求的组织，此处介绍的安全措施也非常有用。

文档的结构如下：

• 简介
• 攻击途径和安全风险
  • 攻击途径
  • 安全风险
• 保护服务网格的措施
  • 安全架构
  • 集群安全
    • 启用严格的双向 TLS
    • 启用访问权限控制
      • 强制执行 Cloud Service Mesh 身份验证政策
      • JSON Web 令牌 (JWT)
      • Cloud Service Mesh 用户身份验证
      • 强制执行授权政策
      • 强制执行令牌交换来访问网格服务
    • 安全处理 Cloud Service Mesh 政策例外
      • 强制执行 Kubernetes 网络政策
    • 安全访问控制平面
    • 强制执行命名空间边界
      • 强制执行 Kubernetes RBAC 政策
  • 网格边缘安全
    • 集群入站流量访问权限控制
    • 监管集群出站流量
    • 使用专用集群或 VPC Service Controls 锁定外部访问
    • 防范外部 DDoS 攻击
  • 网格管理和自动化的安全性
    • 细分用于网格操作的角色
    • 自动验证政策配置
      • 将 GitOps 方法与 Config Sync 搭配使用以防止配置偏移
    • 强制执行审核日志记录和监控
    • 保护集群内证书的证书授权机构
  • 工作负载安全
    • 限制 Pod 权限
    • 保护容器映像
    • 抵御网格漏洞
    • 使用适用于 GKE 的工作负载身份联合安全地访问 Google 服务
    • 通过安全信息中心和遥测监控安全状态
  • 敏感的用户数据和凭据的安全性

简介

Cloud Service Mesh 提供的功能和工具可帮助您以统一的方式观察、管理和保护服务。它采用以应用为中心的方法并使用可信应用身份，而非基于网络 IP 的方法。您可以透明地部署服务网格，而无需修改现有的应用代码。Cloud Service Mesh 以声明方式控制网络行为，有助于将负责交付和发布应用功能的团队的工作与负责安全和网络的管理员的工作分离。

Cloud Service Mesh 基于开源 Istio 服务网格，可实现复杂的配置和拓扑。根据您的组织的结构，一个或多个团队或角色可能负责安装和配置网格。系统会选择默认的 Cloud Service Mesh 设置来保护应用（但在某些情况下，您可能需要使用自定义配置），或通过阻止某些应用、端口或 IP 地址参与网格来授予例外。制定管理网格配置和安全异常的控制措施非常重要。

攻击途径和安全风险

攻击途径

Cloud Service Mesh 安全遵循零信任安全模型，该模型假定安全威胁源自组织的安全边界的内部和外部。可能威胁服务网格中的应用的安全攻击类型示例包括：

• 数据渗漏攻击。例如，监听来自服务间流量的敏感数据或凭据的攻击。
• 中间人攻击。例如，伪装成合法服务来获得或修改服务之间的通信的恶意服务。
• 提升权限攻击。例如，通过非法使用提升的权限在网络中执行操作的攻击。
• 拒绝服务 (DoS) 攻击。
• 尝试入侵和操纵某些服务来对其他服务发起攻击的僵尸网络攻击。

您还可以根据攻击目标对攻击进行分类：

• 网格内部网络攻击。针对篡改、窃听或仿冒网格内部服务到服务或服务到控制平面通信的攻击。
• 控制平面攻击。针对导致控制平面故障（例如 DoS 攻击）或渗漏控制平面的敏感数据的攻击。
• 网格边缘攻击。针对篡改、窃听或仿冒网格入站流量或出站流量的通信的攻击。
• 网格操作攻击。针对网格操作的攻击。攻击者可能会尝试获取提升的权限以在网格中执行恶意操作，例如修改其安全政策和工作负载映像。

安全风险

除安全攻击外，网格还会面临其他安全风险。以下列表介绍了一些可能的安全风险：

• 安全保护不完整。服务网格未配置身份验证和授权政策来保护其安全性。例如，没有为网格中的服务定义身份验证或授权政策。
• 安全政策例外。为了适应特定的使用场景，用户可能会为某些流量（内部或外部）创建安全政策例外，以便从 Cloud Service Mesh 安全政策中排除。如需安全处理此类场景，请参阅安全处理政策例外部分。
• 忽视映像升级。可能会发现网格中使用的映像存在漏洞。您需要确保网格组件和工作负载映像始终使用最新的漏洞修复程序。
• 缺少维护（无专业知识或资源）。网格软件和政策配置需要定期维护，以利用最新的安全保护机制。
• 缺少可见性。配置错误或不安全的网格政策配置以及异常网格流量/操作未受到网格管理员的注意。
• 配置偏移。网格中的政策配置不符合可靠来源。

保护服务网格的措施

本部分提供了保护服务网格的操作手册。

安全架构

服务网格的安全性取决于网格系统及其应用中不同层的组件的安全性。建议的 Cloud Service Mesh 安全状况的总体意图是通过集成不同层的多个安全机制来保护服务网格，这些机制在零信任安全模型下共同实现整体系统安全性。下图展示了建议的 Cloud Service Mesh 的安全状况。

Cloud Service Mesh 在多个层提供安全性，包括：

• 网格边缘安全
  • Cloud Service Mesh 入站流量安全可为外部流量提供访问权限控制，并保护对网格中服务公开的 API 的外部访问权限。
  • Cloud Service Mesh 出站流量安全可监管来自内部工作负载的出站流量。
  • Cloud Service Mesh 用户身份验证与 Google 基础架构集成，可对网络浏览器到运行 Web 应用的服务的外部调用进行身份验证。
  • Cloud Service Mesh 网关证书管理通过 Certificate Authority Service 来保护并轮替 Cloud Service Mesh 入站和出站流量网关使用的私钥和 X.509 证书。
  • Cloud Armor 可以防范外部分布式拒绝服务 (DDoS) 攻击和第 7 层攻击。它可充当 Web 应用防火墙 (WAF) 来保护网格免受网络攻击。例如，注入和远程代码执行攻击。
  • VPC 和 VPC Service Controls 通过专用网络访问权限控制来保护网格边缘。
• 集群安全
  • Cloud Service Mesh 双向 TLS (mTLS) 会强制执行工作负载到工作负载的流量加密和身份验证。
  • 代管式 CA（例如 Cloud Service Mesh 证书授权机构和 Certificate Authority Service）可安全地预配和管理工作负载使用的证书。
  • Cloud Service Mesh 授权会根据网格服务的身份和其他特性对其强制执行访问权限控制。
  • GKE Enterprise 安全信息中心可监控工作负载的安全政策和 Kubernetes 网络政策的配置。
  • Kubernetes 网络政策会根据 IP 地址、Pod 标签、命名空间等强制执行 Pod 访问权限控制。
  • 控制平面安全可防范对控制平面的攻击。此保护可防止攻击者修改、利用或泄露服务和网格配置数据。
• 工作负载安全
  • 及时了解 Cloud Service Mesh 安全版本，以确保网格中运行的 Cloud Service Mesh 二进制文件不存在公开已知的漏洞。
  • 适用于 GKE 的工作负载身份联合可让工作负载获取凭据以安全地调用 Google 服务。
  • Cloud Key Management Service (Cloud KMS) 通过硬件安全模块 (HSM) 来保护敏感数据或凭据。例如，工作负载可以使用 Cloud KMS 存储凭据或其他敏感数据。CA 服务（用于为网格工作负载颁发证书）支持由 Cloud KMS 管理的每个客户受 HSM 支持的签名密钥。
  • Kubernetes CNI（容器网络接口）通过消除对特权 Cloud Service Mesh init 容器的需求来防止提升权限攻击。
• 运维人员安全
  • Kubernetes 基于角色的访问权限控制 (RBAC) 会限制对 Kubernetes 资源的访问权限并限制运维人员权限，以抵御恶意运维人员或运维人员冒充别人的攻击。
  • GKE Enterprise Policy Controller 会验证并审核网格中的政策配置，以防止配置错误。
  • Google Cloud Binary Authorization 可确保网格中的工作负载映像是由管理员授权的映像。
  • Google Cloud Audit Logging 可审核网格操作。

下图展示了使用 Cloud Service Mesh 中的集成式安全解决方案的通信和配置流程。

集群安全

启用严格的双向 TLS

中间人 (MitM) 攻击会尝试在两个通信方之间插入恶意实体，以监听或操纵通信。Cloud Service Mesh 通过对所有通信方强制执行 mTLS 身份验证和加密来防范 MitM 和数据渗漏攻击。宽松模式在双方都支持 mTLS 时使用 mTLS，但允许不使用 mTLS 的连接。相比之下，严格的 mTLS 要求使用 mTLS 对流量进行加密和身份验证，并且不允许纯文本流量。

借助 Cloud Service Mesh，您可以为工作负载中的 TLS 连接配置满足安全性及合规性要求所需的最低 TLS 版本。

如需了解详情，请参阅 Cloud Service Mesh 示例：mTLS | 强制执行网格级 mTLS。

启用访问权限控制

除非有强有力的理由从 Cloud Service Mesh 安全政策中排除服务或 Pod，否则应对进出网格的所有流量都强制执行 Cloud Service Mesh 安全政策（例如身份验证和授权政策）。在某些情况下，用户可能有合法的理由对某些端口和 IP 范围绕过 Cloud Service Mesh 安全政策。例如，与非 Cloud Service Mesh 管理的服务建立原生连接。如需在此类使用场景下保护 Cloud Service Mesh，请参阅安全处理 Cloud Service Mesh 政策例外。

服务访问权限控制对于防止未经授权访问服务至关重要。强制执行 mTLS 会对请求进行加密和身份验证，但网格仍然需要 Cloud Service Mesh 授权政策才能对服务强制执行访问权限控制。例如，拒绝来自经过身份验证的客户端的未经授权请求。

Cloud Service Mesh 授权政策提供了一种灵活的访问权限控制配置方法，可保护您的服务免遭未经授权的访问。应根据从身份验证结果派生的经过身份验证的身份强制执行 Cloud Service Mesh 授权政策，而基于 mTLS 或 JSON Web 令牌 (JWT) 的身份验证应作为 Cloud Service Mesh 授权政策的一部分结合使用。

强制执行 Cloud Service Mesh 身份验证政策

JSON Web 令牌 (JWT)

除了 mTLS 身份验证外，网格管理员还可以要求服务根据 JWT 对请求进行身份验证和授权。Cloud Service Mesh 不充当 JWT 提供方，但会根据配置的 JSON Web 密钥集 (JWKS) 端点对 JWT 进行身份验证。JWT 身份验证可应用于外部流量的入站网关或应用于网格内流量的内部服务。当 JWT 用作凭据来代表最终调用方并且请求的服务需要证明其代表最终调用方进行调用时，JWT 身份验证可与 mTLS 身份验证结合使用。强制执行 JWT 身份验证可以防范没有有效凭据并代表实际最终用户访问服务的攻击。

Cloud Service Mesh 用户身份验证

Cloud Service Mesh 用户身份验证是一种集成式解决方案，用于基于浏览器的最终用户身份验证和对工作负载的访问权限控制。它将服务网格与现有身份提供方 (IdP) 集成以实现标准基于 Web 的 OpenID Connect (OIDC) 登录和同意流程，并使用 Cloud Service Mesh 授权政策进行访问权限控制。

强制执行授权政策

Cloud Service Mesh 授权政策控制：

• 允许谁或什么访问服务。
• 可以访问哪些资源。
• 可对允许的资源执行哪些操作。

授权政策是一种根据服务运行采用的实际身份、流量应用层（第 7 层）属性（例如请求标头）和网络层（第 3 层和第 4 层）属性（例如 IP 范围和端口）配置访问权限控制的通用方法。

应根据从身份验证结果派生的经过身份验证的身份强制执行 Cloud Service Mesh 授权政策，以防范未经授权访问服务或数据。

默认情况下，除非明确定义了授权政策来允许访问服务，否则应拒绝访问服务。如需查看拒绝访问请求的授权政策示例，请参阅授权政策最佳做法。

授权政策应尽可能限制信任。例如，可以根据服务公开的个别网址路径定义对服务的访问权限，以便只有服务 A 可以访问服务 B 的路径 /admin。

授权政策可与 Kubernetes 网络政策结合使用，后者仅在网络层（第 3 层和第 4 层）运行，并控制 Kubernetes Pod 和 Kubernetes 命名空间中的 IP 地址和端口的网络访问权限。

强制执行令牌交换来访问网格服务

为了防范令牌重放攻击，即窃取令牌并重复使用被盗的令牌来访问网格服务，来自网格外部的请求中的令牌应交换为网格边缘处短期有效的网格内部令牌。

从网格外部访问网格服务的请求需要包含 JWT 或 Cookie 等令牌，以便通过网格服务进行身份验证和授权。来自网格外部的令牌可能是长期有效的令牌。为了防范令牌重放攻击，来自网格外部的令牌应交换为网格入站处范围受限的短期有效的网格内部令牌。网格服务会对网格内部令牌进行身份验证，并根据网格内部令牌授权访问请求。

Cloud Service Mesh 支持与 Identity-Aware Proxy (IAP) 集成，后者会生成在 Cloud Service Mesh 中用于授权的 RequestContextToken（从外部令牌交换的短期有效的网格内部令牌）。通过令牌交换，攻击者无法在网格中使用被盗的令牌来访问服务。交换后的令牌的范围和生命周期有限可以大大降低令牌重放的可能性。

安全处理 Cloud Service Mesh 政策例外情况

您的服务网格可能有特殊使用场景。例如，您可能需要向纯文本流量公开某个网络端口。为了适应特定使用场景，有时您可能需要创建例外，以允许从 Cloud Service Mesh 安全政策中排除某些内部或外部流量，这会带来安全问题。

您可能有合法的理由对某些端口和 IP 范围绕过 Cloud Service Mesh 安全政策。您可以为 Pod 添加annotations（例如 excludeInboundPorts、excludeOutboundPorts、excludeOutboundIPRanges），以阻止 Envoy Sidecar 处理流量。除了用于排除流量的注解之外，您还可以通过部署停用了 Sidecar 注入功能的应用来完全绕过网格。例如，为应用 Pod 添加标签 sidecar.istio.io/inject="false"。

绕过 Cloud Service Mesh 安全政策会对整体系统安全性产生负面影响。例如，如果通过注解对网络端口绕过 Cloud Service Mesh mTLS 和授权政策，则不会对端口上的流量进行访问权限控制，并且可能造成窃听或流量修改。此外，绕过 Cloud Service Mesh 政策也会影响网络政策等非安全政策。

当对端口或 IP 绕过 Cloud Service Mesh 安全政策（无论是有意还是无意）时，应采取其他安全措施来保护网格并监控安全异常、潜在的安全漏洞以及整体安全机制强制执行状态。在这种情况下，如需保护网格，您可以执行以下操作：

• 确保绕过 Sidecar 的流量采用原生方式进行加密和身份验证，以防止 MitM 攻击。
• 强制执行 Kubernetes 网络政策，以限制具有政策例外的端口的连接性（例如，限制具有政策例外的端口，仅允许来自同一命名空间中的其他服务的流量），或仅允许流量通过强制执行了 Cloud Service Mesh 安全政策的端口。
• 强制执行 GKE Enterprise Policy Controller，以自动验证 Cloud Service Mesh 政策。例如，强制要求 Cloud Service Mesh Sidecar 始终注入工作负载。

强制执行 Kubernetes 网络政策

Cloud Service Mesh 基于底层平台（例如 Kubernetes）构建。因此，Cloud Service Mesh 的安全性取决于底层平台的安全性。例如，如果不控制谁可以更新 Kubernetes 资源，则用户可能会更改服务的 Kubernetes 部署来绕过该服务的 Sidecar。

为了形成可靠的服务网格安全状况，应强制实施底层平台的安全机制，以便与 Cloud Service Mesh 安全政策协同工作。

Kubernetes 网络政策在 Kubernetes Pod 和命名空间中的 IP 地址和端口的网络层（L3 和 L4）运行。您可以将 Kubernetes 网络政策与 Cloud Service Mesh 政策结合强制执行，以增强网格的安全性。

例如，网格管理员可以将 Kubernetes 网络政策配置为仅允许流量使用强制执行了 Cloud Service Mesh 安全政策的端口。如果必须使用 Cloud Service Mesh mTLS 强制执行所有流量，则管理员可以将 Kubernetes 网络政策配置为仅允许配置了 Cloud Service Mesh mTLS 政策的端口上的流量。网格管理员还可以将 Kubernetes 网络政策配置为限制使用政策例外的端口的连接。例如，将此类端口的连接限制在命名空间内。

安全访问控制平面

Cloud Service Mesh 控制平面会对连接的任何客户端进行身份验证。因此，只有拥有有效凭据（Kubernetes JWT 或允许的 CA 颁发的 X.509 证书）的调用方才能访问 Cloud Service Mesh 控制平面。TLS 会对工作负载与 Cloud Service Mesh 控制平面之间的连接进行加密。

除了身份验证机制之外，对于集群内 Cloud Service Mesh，还可以部署 Kubernetes 网络政策，以将 Cloud Service Mesh 系统命名空间（默认为 istio-system）与未管理的命名空间和服务网格外部的客户端隔离，同时允许数据平面访问控制平面。VPC 防火墙规则可以阻止集群外部的流量到达 Istiod。采用此类网络隔离措施时，即使攻击者拥有有效的凭据，网格外部的攻击者也无法访问控制平面。对于代管式控制平面，Google 会处理控制平面的安全性，因此不需要将此类网络隔离政策用于控制平面。

强制执行命名空间边界

为防止一个命名空间的用户访问/更新未经授权的命名空间中的资源，请执行以下操作：

• 强制执行访问权限控制。
• 强制执行 Kubernetes 网络政策。如果命名空间中的服务没有该命名空间之外的流量，则网格管理员应部署一个仅允许该命名空间内的流量的 Kubernetes 网络政策：没有来自该命名空间的入站流量或出站流量。
• 强制执行 Kubernetes RBAC 政策
  • 应用管理员的角色应绑定到命名空间。
  • 仅允许网格管理员具有 ClusterRole。

强制执行 Kubernetes RBAC 政策

网格管理员应强制执行 Kubernetes RBAC 政策，以控制谁可以访问和更新 Kubernetes 资源。Kubernetes 访问权限控制可以抵御网格中的安全风险。例如，未经授权的用户不应能够更改 Kubernetes 部署并绕过强制执行 Cloud Service Mesh 政策。用户的角色应绑定到命名空间，因此不允许用户访问的命名空间数量超出其需要访问的数量。如需查看配置 RBAC 的详细指南和示例，请参阅配置基于角色的访问权限控制。启用适用于 GKE 的工作负载身份联合后，您还可以允许 Kubernetes 服务账号充当 IAM 服务账号。

网格边缘安全

由于大多数攻击也可能源自集群外部，因此确保网格边缘的安全性至关重要。

集群入站流量访问权限控制

Cloud Service Mesh 通过入站流量网关接收传入的外部流量。入站流量网关公开的服务可能会面临来自外部来源的攻击。安全管理员应始终确保通过入站流量网关向外部流量公开的服务足够安全，可防范攻击。

Ingress 应对向外部调用方公开的服务强制执行身份验证和授权。

• 强制执行集群入站流量安全政策。当集群需要接收外部流量时，网格管理员应强制执行入站安全政策，包括 Cloud Service Mesh 网关 TLS、身份验证和授权政策，以对外部请求进行身份验证，并验证外部请求是否有权访问入站网关公开的服务。强制执行入站流量安全政策可防范网格外尝试在没有有效凭据或权限的情况下访问服务的攻击。
• 使用 Cloud Armor 充当 Web 应用防火墙 (WAF)，以防范基于 Web 的攻击（例如注入攻击和远程执行攻击）。如需了解详情，请参阅从边缘到网格：通过 GKE Ingress 公开服务网格应用。

监管集群出站流量

集群出站流量安全对于网格安全至关重要，因为出站流量安全政策可以防范数据渗漏攻击，强制执行出站流量过滤，以及对出站流量强制执行 TLS 发源。安全管理员应监管和审核集群出站流量。

除了使用 VPC 防火墙防火墙来限制出站流量之外，网格管理员还应对集群强制执行出站流量安全政策，并将其出站流量配置为通过出站流量网关。

出站流量政策可以抵御以下攻击：

• 数据渗漏攻击。
• 未修补服务 Pod 的 CVE 时服务 Pod 可能被攻击者利用。被入侵的 Pod 可能会成为攻击者控制的僵尸网络，用来发送垃圾邮件或发起 DoS 攻击。

应用于出站流量网关的授权政策可确保仅允许已获授权的服务将流量发送到网格外的特定主机。同时，对于离开网格的流量，可以在出站流量网关发起 TLS，而不是在个别 Sidecar 处理 TLS 发源。这提供了一种统一、更安全的方式来发起 TLS 流量，因为 mTLS 的客户端证书可以与应用在其中运行的命名空间隔离开来。

使用专用集群或 VPC Service Controls 锁定外部访问

除了强制执行入站和出站流量安全政策之外，请尽可能使用专用集群或 VPC Service Controls 锁定外部访问。虽然安全政策由网格安全管理员控制，但专用集群配置或 VPC Service Controls 可由组织安全管理员强制执行。

可以强制实施 VPC Service Controls 以便为服务定义安全边界，从而达到以下目的：

• 限制服务访问外部资源。
• 限制外部人员访问安全边界内的服务。

VPC Service Controls 有助于防范数据渗漏攻击，并防止外部攻击者访问网格内的服务。

防范外部 DDoS 攻击

外部 DDoS 攻击可能会使入站网关和后端服务过载，导致无法处理合法请求。可使用 Cloud Armor 来防范 DDoS 攻击。Cloud Armor 不仅能够防范网络层（L3 和 L4）DDoS 攻击，还可以防范应用层 (L7) DDoS 攻击。

网格管理和自动化的安全性

请务必考虑管理操作以及围绕网格构建的任何自动化功能（例如 CI/CD）的安全性。以下做法旨在确保网格能够安全运行，而不会造成服务受到额外攻击的风险。

细分用于网格操作的角色

遵循与基于角色的访问控制相同的原则，网格的用户应根据其角色进行分类。每个角色应被授予该角色所需的一组最低权限。

例如，进行服务部署的一组用户不应具有更新身份验证和授权政策的权限。

运维人员分为不同类别。例如，集群运维人员和命名空间运维人员。请务必防止运维人员提升权限，以免导致非法访问未经授权的资源。

Kubernetes RBAC 政策可让网格管理员仅将资源访问权限授予已获授权的用户。

自动验证政策配置

运维人员可能会意外错误配置 Cloud Service Mesh 政策，这可能会导致严重的安全突发事件。为防止配置错误并自动验证 Cloud Service Mesh 政策，网格管理员可以使用 Policy Controller 对政策配置强制执行限制条件。

为避免过度信任有权更新 Cloud Service Mesh 安全政策的个人并自动验证 Cloud Service Mesh 政策，网格管理员应使用 Policy Controller 对 Cloud Service Mesh 政策实施限制条件。

Policy Controller 基于开源 Gatekeeper 项目，可作为 Kubernetes 准入控制器运行以拒绝应用无效资源，也可以在审核模式下运行，以便管理员收到违规提醒。Policy Controller 可以自动验证网格中的资源部署，例如验证部署上的注解是否会绕过 Cloud Service Mesh 政策、验证 Cloud Service Mesh 政策是否按预期运行，以及验证部署是否不包含 root 功能（例如 NET_ADMIN 和 NET_RAW）。

Policy Controller 还可以根据限制条件审核现有的 Cloud Service Mesh 资源，以检测政策配置错误。

以下是 GKE Enterprise Policy Controller 强制执行安全政策的一些示例：

• 阻止 Pod 运行特权容器。
• 仅允许使用特定代码库中的映像，以防止运行未经授权的容器映像。
• 禁止为 Istio DestinationRule 中的所有主机和主机子集停用 TLS。
• 禁止 Istio AuthorizationPolicy 规则中的主账号和命名空间具有指定列表中的前缀。
• 禁止创建将工作负载公开给外部 IP 的已知资源。
• 要求 Ingress 资源仅限于 HTTPS。
• 要求在容器中使用只读根文件系统。

Policy Controller 随附的限制条件模板库包含一组限制条件模板，可与开箱即用的 Cloud Service Mesh 安全限制条件软件包搭配使用，以强制执行特定的 Cloud Service Mesh 安全最佳实践，例如身份验证、授权和流量政策。以下是该包中包含的一些示例限制条件：

• 强制执行网格级层的严格 mTLS PeerAuthentication。
• 强制要求所有 PeerAuthentication 均不能覆盖严格 mTLS。
• 强制执行网格级层的默认拒绝 AuthorizationPolicy。
• 强制执行 AuthorizationPolicy 安全模式。
• 强制要求 Cloud Service Mesh Sidecar 始终注入工作负载。

如需处理异常和紧急访问权限状况，网格管理员可以执行以下操作：

• 从强制执行 Policy Controller 的准入网络钩子中排除命名空间，但任何违规行为仍会在审核中报告。
• 将限制条件 spec.enforcementAction 设置为 dryrun。准入网络钩子不会阻止更改，但任何违规行为仍会在审核中报告。
• 将豁免逻辑添加到限制条件模板（示例）中。

将 GitOps 方法与 Config Sync 搭配使用以防止配置偏移

当网格中的政策配置不符合其真实来源时，会发生配置偏移。可使用 Config Sync 来防止配置偏移。

强制执行审核日志记录和监控

网格管理员应监控以下资源：

• Cloud Audit Logs
• Cloud Service Mesh 审核日志记录
• 政策限制条件审核日志记录
• Anthos Config Sync
• 访问日志
• 服务等级指标
• 访问跟踪记录

这些可观测性资源可用于验证安全配置是否按预期工作，并监控是否存在任何安全政策强制执行例外。例如，未通过 Sidecar 的访问、没有有效凭据但到达服务的访问。

虽然开源可观测性软件（例如 Prometheus）可与 Cloud Service Mesh 搭配使用，但我们强烈建议您使用 Google Cloud 的运维套件（原 Stackdriver）。Google Cloud 的内置可观测性解决方案为全代管式且易于使用，可提供日志记录、指标收集、监控和提醒功能。

保护集群内证书的证书授权机构

默认情况下，Cloud Service Mesh 使用 Google 管理的证书授权机构 (CA)，称为 Cloud Service Mesh 证书授权机构。

如果您使用的是作为 Istiod 的一部分托管的非代管式 Istio 证书授权机构 (CA)，则 CA 签名密钥存储在 Kubernetes Secret 中，并且可供有权访问 istio-system 命名空间中的 Secret 资源的运维人员使用。这样做存在风险，因为运维人员可能可以独立于 Istiod 的 CA 来使用 CA 密钥，并且可能会独立为工作负载证书签名。还存在一种风险是，自行管理的 CA 签名密钥可能会因操作错误而意外泄露。

为了保护 CA 签名密钥，网格管理员可以升级网格，以使用由 Google 保护和管理的 Cloud Service Mesh 证书授权机构或 Certificate Authority Service (CA Service)。与 Cloud Service Mesh 证书颁发机构相比，CA Service 通过基于 Cloud HSM 的 Cloud KMS 支持每个客户的签名密钥。CA Service 还支持受监管的工作负载，而 Cloud Service Mesh 证书授权机构不支持。

工作负载安全

工作负载安全可防止发生以下攻击：入侵工作负载 Pod，然后使用被入侵的 Pod 对集群发起攻击（例如僵尸网络攻击）。

限制 Pod 权限

Kubernetes Pod 可能具有影响节点或集群上的其他 Pod 的权限。对工作负载 Pod 强制实施安全限制非常重要，可以防止被入侵的 Pod 针对集群发起攻击。

对 Pod 上的工作负载强制执行最小权限原则：

• 网格中部署的服务应以尽可能少的权限运行。
• 以特权模式运行的 Kubernetes Pod 可以操控主机上的网络栈和其他内核功能。GKE Enterprise Policy Controller 可用于阻止 Pod 运行特权容器。
• Cloud Service Mesh 可以配置为使用 init 容器来配置指向 Sidecar 的 iptables 流量重定向。这要求执行工作负载部署的用户具有使用 NET_ADMIN 和 NET_RAW 功能部署容器的权限。为避免以提升的权限运行容器的风险，网格管理员可以改为启用 Istio CNI 插件以配置指向 Sidecar 的流量重定向。

保护容器映像

攻击者可能会利用易受攻击的容器映像来发起攻击。管理员应强制执行 Binary Authorization 以验证容器映像的完整性，并确保仅在网格中部署受信任的容器映像。

抵御网格漏洞

• Container Analysis。Container Analysis 可以扫描和发现 GKE 工作负载上的漏洞。
• CVE（常见漏洞和披露）处理。在容器映像中发现漏洞后，网格管理员应尽快修复漏洞。对于具有代管式数据平面的代管式 Cloud Service Mesh，Google 会自动处理影响网格映像的修补 CVE。

使用适用于 GKE 的工作负载身份联合安全地访问 Google 服务

对于网格工作负载，建议使用 适用于 GKE 的工作负载身份联合安全地访问 Google 服务。由于存在凭据泄露、提升权限、信息泄露和不可否认的风险，因此将服务账号密钥存储在 Kubernetes Secret 中并使用服务账号密钥来访问 Google 服务的替代方法并不那么安全。

通过安全信息中心和遥测监控安全状态

服务网格可能存在安全异常和潜在的漏洞。呈现和监控网格的安全状态至关重要，其中包括强制执行的安全政策、安全异常以及网格中潜在的安全漏洞。GKE Enterprise 安全信息中心和遥测可用于呈现和监控网格安全状态。

遥测会监控网格中服务的健康状况和性能，使网格管理员能够观察服务的行为（例如 SLO、异常流量、服务中断和拓扑）。

GKE Enterprise 安全信息中心会分析并直观呈现应用于服务网格中工作负载的安全政策，包括访问权限控制政策（Kubernetes 网络政策、Binary Authorization 政策和服务访问权限控制政策）以及身份验证政策 (mTLS)。

敏感的用户数据和凭据的安全性

如果敏感的用户数据或凭据存储在集群永久性存储空间中（例如使用 Kubernetes Secret 或直接在 Pod 中），则可能会很容易受到源自 Pod 或恶意操作的攻击。如果它们通过网络传输以对服务进行身份验证，则也很容易受到网络攻击。

• 如果可能，将敏感的用户数据和凭据存储在 Secret Manager 和 Cloud KMS 等受保护的存储空间中。
• 为访问敏感数据的 Kubernetes Pod 指定单独的命名空间并定义 Kubernetes 政策，以使其无法从其他命名空间进行访问。细分用于操作的角色并强制执行命名空间边界。
• 强制执行令牌交换，以防止渗漏长期有效的高特权令牌。

后续步骤

• 查看在 GKE 集群上使用 Cloud Service Mesh 出站流量网关的最佳实践
• 配置传输安全
• 更新授权政策