强化集群的安全性

本文档提供了有关如何提高 Google Kubernetes Engine (GKE) 环境安全性的最佳实践。负责定义、管理和实施政策和程序的安全专家可以使用这些最佳实践来保护组织的数据。

您应该已经熟悉以下内容：

默认情况下，新的 GKE 集群会实施本文档中的许多最佳实践。与 Standard 模式集群相比，Autopilot 模式集群的默认安全态势更为严格。

如需在整个组织中实施并强制执行本文档中的最佳实践，请考虑使用以下服务：

  • Security Command Center：自动检查您的集群是否实现了许多此类最佳实践，并检查其他常见的错误配置。
  • 组织政策服务：在组织、文件夹或项目中对 GKE 资源强制实施特定的最佳实践。本文档中的特定部分包含指向 Google Cloud 控制台的链接，您可以通过这些链接为相关建议应用受管理的限制。

Google Cloud 环境设计

以下部分介绍了在 Google Cloud中规划和设计资源时应考虑的安全措施。云架构师在规划和定义 Google Cloud 架构时应使用这些建议。

最佳实践

规划 Google Cloud 资源结构

建议：实施企业基础蓝图，该蓝图基于我们的最佳实践，可为您的企业环境提供完整的基础。

Google Cloud 组织、文件夹和项目的架构会影响您的安全状况。设计这些基础资源时，应确保能够在整个服务中大规模实现治理和安全控制。

规划多租户环境

推荐：为多租户企业平台实现 Google Cloud 和 GKE 最佳实践。

许多 GKE 客户管理着分布式团队，这些团队有各自的工程工作流和职责。这些多租户环境必须具有可供所有开发者使用的共享基础设施，同时根据角色和职责限制对组件的访问权限。企业应用蓝图以企业基础蓝图为基础，可帮助您在多租户环境中部署内部开发者平台。

有关详情，请参阅以下文档：

使用标记对 Google Cloud 资源进行分组

建议：使用标记来整理 GKE 资源，以便在团队中实现有条件的政策执行和提高责任分摊。

标记是您可以附加到组织、文件夹和项目中的资源的元数据，用于在Google Cloud 资源层次结构中标识业务维度。您可以将标记附加到 GKE 集群和节点池，然后使用这些标记按条件应用组织政策、IAM 政策或防火墙政策。

有关详情，请参阅以下文档：

规划 VPC 网络

推荐：实施 Google Cloud 和 GKE VPC 网络设计最佳实践。

您的 VPC 网络设计和所使用的功能会影响网络安全性。根据您的 Google Cloud资源层次结构和安全目标规划网络。如需了解详情，请参阅以下文档：

设计突发事件响应方案

建议：制定并维护符合您的安全性和可靠性目标的突发事件响应方案。

即使您实施了所有可能的安全控制措施，安全突发事件也可能会发生。突发事件响应计划有助于您发现安全控制措施中存在的潜在差距，快速有效地应对各种类型的突发事件，并减少中断期间的停机时间。如需了解详情，请参阅以下文档：

Google Cloud 网络安全

以下部分针对 VPC 网络提供了一些安全建议。网络架构师和网络管理员应应用这些建议，以减少网络级别的攻击面，并限制意外网络访问的影响。

最佳实践

使用最小权限防火墙规则

建议：创建防火墙规则时，请遵循最小权限原则以仅针对必需的目的提供访问权限。尽量确保防火墙规则不会与 GKE 默认防火墙规则冲突或覆盖后者。

GKE 会创建默认 VPC 防火墙规则以启用系统功能并实施良好的安全性实践。如果您创建的宽松防火墙规则的优先级高于默认防火墙规则（例如，允许所有入站流量的防火墙规则，用于调试），则集群会面临意外访问风险。

使用共享 VPC 实现跨项目流量

推荐：使用共享 VPC，让多个项目中的资源能够通过使用内部 IP 地址相互通信。

您组织中不同项目中的资源可能需要相互通信。例如，一个项目中的 GKE 集群中的前端服务可能需要与另一个项目中的后端 Compute Engine 实例进行通信。

有关详情，请参阅以下文档：

使用单独的网络来隔离环境

建议：为预演、测试和生产环境使用单独的共享 VPC 网络。

将开发环境彼此隔离，以减少未经授权的访问或破坏性 bug 带来的影响和风险。如需了解详情，请参阅多个宿主项目。

不可变的安全设置

以下部分提供了安全建议，您只能在创建集群或节点池时配置这些建议。您无法更新现有集群或节点池来更改这些设置。平台管理员应将这些建议应用于新集群和节点池。

使用最小权限 IAM 节点服务账号

建议：为 GKE 集群和节点池使用自定义 IAM 服务账号，而不是使用默认的 Compute Engine 服务账号。

GKE 使用关联到节点的 IAM 服务账号来运行日志记录和监控等系统任务。这些节点服务账号必须至少拥有项目的 Kubernetes Engine Default Node Service Account (roles/container.defaultNodeServiceAccount) 角色。默认情况下，GKE 会将 Compute Engine 默认服务账号（在您的项目中自动创建）用作节点服务账号。

如果您将 Compute Engine 默认服务账号用于项目或组织中的其他功能，则该服务账号可能具有超出 GKE 所需要的权限，从而使您面临安全风险。

关联到节点的服务账号应仅供执行日志记录和监控等任务的系统工作负载使用。对于您自己的工作负载，请使用 Workload Identity Federation for GKE 来预配身份。

如需在组织中强制执行此建议，请使用 constraints/container.managed.disallowDefaultComputeServiceAccount 受管理的组织政策限制条件。如需在 Google Cloud 控制台中查看此受管理的限制条件，请前往政策详情页面。

前往政策详情

使用 Container-Optimized OS 节点映像

建议：除非您有使用 Ubuntu 或 Windows 的特定要求，否则请为节点使用 Container-Optimized OS 节点映像。

Container-Optimized OS 专门针对运行容器而构建、优化和强化。Container-Optimized OS 是 Autopilot 模式下唯一受支持的节点映像，也是标准模式下的默认节点映像。

有关详情，请参阅以下文档：

节点安全配置

以下部分针对 GKE 节点配置提供了安全建议。平台管理员和安全工程师应应用这些建议，以提高 GKE 节点的完整性。

最佳实践

使用安全强化型 GKE 节点

建议：在所有集群和节点池中启用安全强化型 GKE 节点、安全启动和完整性监控。

安全强化型 GKE 节点提供可验证的身份和完整性检查，可提高节点的安全性。在 Autopilot 集群中，安全强化型 GKE 节点以及节点完整性监控和安全启动等功能始终处于启用状态。在 Standard 集群中，请执行以下操作：

  • 请勿在集群中停用安全强化型 GKE 节点。
  • 在所有节点池中启用安全启动。
  • 请勿在节点池中停用完整性监控。

如需详细了解如何启用这些功能，请参阅使用安全强化型 GKE 节点。

如需在组织中强制执行此建议，请使用 constraints/container.managed.enableShieldedNodes 受管理的组织政策限制条件。如需在 Google Cloud 控制台中查看此受管理的限制条件，请前往政策详情页面。

前往政策详情

停用不安全的 kubelet 只读端口

建议：停用 kubelet 只读端口，并将使用端口 10255 的所有工作负载切换为更安全的端口 10250。

节点上运行的 kubelet 进程会使用不安全的端口 10255 提供只读 API。Kubernetes 不会对此端口执行任何身份验证或授权检查。kubelet 会在经过身份验证的更安全端口 10250 上提供相同的端点。

如需了解详情，请参阅在 GKE 集群中停用 kubelet 只读端口。

如需在组织中强制执行此建议，请使用 constraints/container.managed.disableInsecureKubeletReadOnlyPort 受管理的组织政策限制条件。如需在 Google Cloud 控制台中查看此受管理的限制条件，请前往政策详情页面。

前往政策详情

访问权限控制

以下部分提供了有关限制集群中未经授权的访问的建议。安全工程师以及身份和账号管理员应应用这些建议，以缩小攻击面并限制未经授权的访问所带来的影响。

最佳实践

限制对集群 API 发现的访问权限

建议：限制从互联网对控制平面和节点的访问，以防止对集群 API 发现端点进行意外访问。

默认情况下，Kubernetes 会创建一组宽松的默认 API 发现角色。这些默认角色允许各种默认群组（例如 system:authenticated）广泛访问有关集群 API 的信息。这些默认角色无法为 GKE 集群提供有意义的安全保障。 例如，system:authenticated 群组可以读取有关 CustomResources 等 API 的信息，该群组已分配给任何经过身份验证的用户（包括拥有 Google 账号的任何人）。

如需限制对集群发现 API 的访问权限，请执行以下操作：

  • 限制对控制平面的访问：仅使用基于 DNS 的端点访问控制平面。如果您使用基于 IP 的端点，请通过配置授权网络将访问权限限制为一组已知的地址范围。
  • 配置专用节点：停用节点的外部 IP 地址，以便网络外部的客户端无法访问这些节点。

如需了解详情，请参阅网络隔离简介。

如果您不启用这些网络隔离功能，则应将所有 API 发现信息（尤其是 CustomResources 的架构、APIService 定义以及由扩展程序 API 服务器托管的发现信息）视为公开泄露。

将团队和环境放在单独的命名空间或集群中

为每个团队和环境创建单独的命名空间或集群，从而为团队提供对 Kubernetes 的最低访问权限。为每个命名空间或集群分配成本中心和标签，以实现责任的明晰化和退款。

您可以将 IAM 和 RBAC 权限与命名空间结合使用，以限制用户与 Google Cloud 控制台上的集群资源的互动。如需了解详情，请参阅按命名空间启用访问权限和查看集群资源。

在访问权限政策中遵循最小权限原则

建议：仅为开发者提供部署和管理其命名空间中的应用所需的访问权限，尤其是在生产环境中。在设计访问权限控制政策时，请规划用户需要在集群中执行的任务，并仅向他们授予执行这些任务所需的权限。

在 GKE 中，您可以使用 IAM 和 Kubernetes 基于角色的访问控制 (RBAC) 来授予资源权限。这些访问权限控制机制协同运作。如需降低管理访问权限的复杂性，请执行以下操作：

  • 如需授予对项目或 Google Cloud 资源的访问权限，请使用 IAM 角色。

  • 如需授予对集群中 Kubernetes 资源（例如命名空间）的访问权限，请使用 RBAC。

如需详细了解如何规划和设计 IAM 和 RBAC 政策，请参阅以下文档：

使用 Workload Identity Federation for GKE 访问 Google Cloud API

推荐：如需从 GKE 工作负载访问 Google Cloud 资源，请使用适用于 GKE 的工作负载身份联合。

建议使用 Workload Identity Federation for GKE 向Google Cloud API 进行身份验证。您可以将各种资源的 IAM 角色授予集群中的主账号，例如特定的 Kubernetes ServiceAccount 或 Pod。Workload Identity Federation for GKE 还可以保护节点上的敏感元数据，并提供比静态令牌文件等替代方案更安全的身份验证工作流。

Autopilot 集群中会始终启用适用于 GKE 的工作负载身份联合。在 Standard 集群中，为所有集群和节点池启用 Workload Identity Federation for GKE。此外，请遵循以下建议：

  • 如果您在应用代码中使用 Google Cloud 客户端库，请勿将 Google Cloud 凭证分发给工作负载。使用客户端库的代码会自动检索适用于 GKE 的工作负载身份联合的凭证。
  • 为需要不同身份的每个工作负载使用单独的命名空间和 ServiceAccount。向特定服务账号授予 IAM 权限。

如需了解详情，请参阅从 GKE 工作负载向 Google Cloud API 进行身份验证。

如需在组织中强制执行此建议，请使用 constraints/container.managed.enableWorkloadIdentityFederation 受管理的组织政策限制条件。如需在 Google Cloud 控制台中查看此受管理的限制条件，请前往政策详情页面。

前往政策详情

使用群组管理访问权限

建议：在访问权限政策中，向用户群组授予权限，而不是向个人授予权限。

当您在群组中管理用户时，身份管理系统和身份管理员可以通过修改用户在各个群组中的成员资格来集中控制身份。这种管理方式可让您无需在特定用户需要更新权限时更新 RBAC 或 IAM 政策。

您可以在 IAM 或 RBAC 政策中指定 Google 群组。有关详情，请参阅以下文档：

如需在组织中强制执行此建议，请使用constraints/container.managed.enableGoogleGroupsRBAC 受管理的组织政策限制条件。如需在 Google Cloud 控制台中查看此受管理的限制条件，请前往政策详情页面。

前往政策详情

限制对集群端点的匿名访问

推荐：在所有 Autopilot 集群和 Standard 集群中，阻止向除健康检查端点之外的所有集群端点发送匿名请求。

默认情况下，Kubernetes 会将 system:anonymous 用户和 system:unauthenticated 群组分配给对集群端点的匿名请求。如果您的 RBAC 政策向该用户或群组授予了其他权限，则匿名用户可能能够危及服务或集群本身的安全。

在 GKE 1.32.2-gke.1234000 版及更高版本中，您可以将匿名请求可访问的端点集限制为仅包含 /healthz、/livez 和 /readyz Kubernetes API 服务器健康检查端点。需要对这些健康检查端点进行匿名访问，以验证集群是否正常运行。

如需限制对集群端点的匿名访问，请在使用 gcloud CLI 或 GKE API 创建或更新标准集群和 Autopilot 集群时，为 --anonymous-authentication-config 标志指定 LIMITED。在身份验证期间，GKE 会拒绝向非健康检查端点的集群端点发出的匿名请求。即使您的 RBAC 政策向匿名用户和群组授予了访问权限，匿名请求也无法到达端点。被拒请求将返回 HTTP 状态 401。

如需使用组织政策在组织、文件夹或项目中强制执行此建议，请创建具有 resource.anonymousAuthenticationConfig.mode 条件的自定义限制条件。如需了解详情和查看限制条件示例，请参阅使用自定义组织政策限制对 GKE 资源的操作。

请勿仅依赖此功能来保护集群。请采取如下额外的安全措施：

GKE 网络安全

以下部分提供了有关如何提高集群网络安全性的建议。网络管理员和安全工程师应应用这些建议，以保护工作负载和基础设施免受意外的外部或内部访问。

最佳实践

限制对控制平面的访问

推荐：启用基于 DNS 的端点以访问控制平面，并停用所有基于 IP 的控制平面端点。

默认情况下，外部实体（例如互联网上的客户端）可以访问您的控制平面。您可以配置网络隔离，以限制哪些人可以访问控制平面。

如需隔离控制平面，请执行以下某项操作：

  • 仅使用基于 DNS 的端点（推荐）：为控制平面启用基于 DNS 的端点，并停用基于 IP 的内部和外部端点。所有控制平面访问都必须使用基于 DNS 的端点。 您可以使用 VPC Service Controls 来控制哪些人可以访问基于 DNS 的端点。

    如需在组织中强制执行此建议，请使用 constraints/container.managed.enableControlPlaneDNSOnlyAccess 受管理的组织政策限制条件。如需在 Google Cloud 控制台中查看此受管理的限制条件，请前往政策详情页面。

    前往“政策详细信息”

  • 停用基于外部 IP 的端点：移除控制平面的外部 IP 地址。VPC 网络外部的客户端无法使用外部 IP 地址访问控制平面。

    如果您使用 Cloud Interconnect 和 Cloud VPN 等技术将公司网络连接到 VPC 网络，那么此选项非常适合。

  • 将已获授权的网络与基于外部 IP 的端点搭配使用：将对基于外部 IP 的端点的访问权限限制为仅允许可信的源 IP 地址范围。

    如果您还没有 VPN 基础架构，或者您的远程用户或分支办公室通过公共互联网访问集群，那么此选项非常适合。

在大多数情况下，仅使用基于 DNS 的端点访问控制平面。如果您必须启用基于 IP 的端点，请使用授权网络将控制平面访问权限限制为以下实体：

  • 您指定的 IP 地址范围。
  • 与集群位于同一 VPC 网络中的 GKE 节点。
  • 用于管理集群的 Google 预留的 IP 地址。

将节点与互联网隔离

默认情况下，所有 GKE 节点都具有外部 IP 地址，互联网上的客户端可以访问这些地址。如需移除此外部 IP 地址，请启用专用节点。

如需在组织中强制执行此建议，请使用 constraints/container.managed.enablePrivateNodes 受管理的组织政策限制条件。如需在 Google Cloud 控制台中查看此受管理的限制条件，请前往政策详情页面。

前往“政策详细信息”

限制 Pod 之间的网络流量

推荐：使用 NetworkPolicy、服务网格或同时使用这两者来控制 Pod 到 Pod 的网络流量。

默认情况下，集群中的每个 Pod 都可以与其他每个 Pod 进行通信。 限制服务之间的网络访问权限可以大大增加攻击者在集群中横向移动的难度。您的服务还可以获得一定的保护，免遭意外的或故意的拒绝服务事件的影响。您可以根据自己的需求，采用以下任一方法或两种方法并用，来限制 Pod 到 Pod 的流量：

Sensitive Data Protection

以下部分提供了有关加密数据和保护凭证等敏感信息的建议。安全工程师和平台管理员应应用这些建议，以降低对关键数据进行意外访问的风险。

最佳实践

加密使用中的工作负载数据

使用机密 GKE 节点，通过基于硬件的内存加密来保护工作负载使用中的数据。您可以根据自己的需求选择机密计算技术。如需了解详情，请参阅通过机密 GKE 节点加密使用中的工作负载数据。

将 Secret 存储在集群外部

建议：使用 Secret Manager 等外部 Secret 管理器将 API 密钥等敏感数据存储在集群外部。

在 Kubernetes 中，您可以将敏感数据存储在集群中的 Secret 中。您可以使用 Secret 向应用提供机密数据，而无需在应用代码中包含该数据。不过，在集群中存储此类数据存在以下风险：

  • 任何可以在命名空间中创建 Pod 的人都可以读取该命名空间中任何 Secret 的数据。
  • 如果用户拥有读取所有 Kubernetes API 对象的 RBAC 或 IAM 访问权限，则可以读取 Secret。

鉴于这些风险，只有在无法以任何其他方式向工作负载提供相应数据时，才应在集群中创建 Secret。我们建议您按优先顺序采用以下方法来存储和访问敏感数据：

  • Secret Manager 客户端库：通过将 Secret Manager API 与 Workload Identity Federation for GKE 搭配使用，以程序化方式从应用代码中访问密文。如需了解详情，请参阅使用客户端库访问存储在 GKE 集群外部的 Secret。
  • 将 Secret Manager 数据作为装载的卷：使用适用于 GKE 的 Secret Manager 插件，以装载的卷的形式向 Pod 提供敏感数据。如果您无法修改应用代码以使用 Secret Manager 客户端库，此方法会很有用。如需了解详情，请参阅将 Secret Manager 加载项与 Google Kubernetes Engine 搭配使用。

  • 第三方 Secret 管理工具：HashiCorp Vault 等第三方工具可为 Kubernetes 工作负载提供 Secret 管理功能。与 Secret Manager 相比，这些工具需要进行更多的初始配置，但与在集群中创建 Secret 相比，它们是更安全的选择。如需配置第三方 Secret 管理工具，请参阅相应提供商的文档。此外，请考虑以下建议：

    • 如果第三方工具在集群中运行，请使用与运行工作负载的集群不同的集群。
    • 使用 Cloud Storage 或 Spanner 存储该工具的数据。
    • 使用内部直通式网络负载均衡器将第三方 Secret 管理工具公开给在 VPC 网络中运行的 Pod。

  • 使用 Kubernetes Secret（不推荐）：如果上述选项均不适合您的使用情形，您可以将数据存储为 Kubernetes Secret。Google Cloud 默认情况下在存储层对数据进行加密。 此默认存储层加密包括用于存储集群状态的数据库，该数据库基于 etcd 或 Spanner。 此外，您还可以使用自己管理的密钥在应用层对这些 Secret 进行加密。如需了解详情，请参阅在应用层对 Secret 加密。

工作负载安全

以下部分提供了相关建议，可帮助您提高集群的安全性，防范工作负载问题。安全工程师和平台管理员应应用这些建议，以提高 GKE 基础设施免受工作负载侵害的保护能力。

最佳实践

使用 GKE Sandbox 隔离工作负载

推荐：使用 GKE Sandbox 可防止恶意代码影响集群节点上的主机内核。

您可以在沙盒环境中运行容器，以缓解大多数容器逃逸攻击，也称为本地提权攻击。如 GKE 安全公告中所述，此类攻击可让攻击者访问容器的主机虚拟机。攻击者可以利用此主机访问权限来访问同一虚拟机上的其他容器。GKE Sandbox 有助于限制这些攻击的影响。

在以下场景中使用 GKE Sandbox：

  • 您有运行不受信任代码的工作负载。
  • 您希望在攻击者破坏工作负载中的容器的情况下限制影响。

如需了解详情，请参阅利用 GKE Sandbox 强化工作负载隔离。

限制工作负载自行修改的能力

建议：使用准入控制器来防止工作负载自行修改，或防止修改有风险的工作负载属性（例如 ServiceAccount）。

某些 Kubernetes 工作负载（尤其是系统工作负载）有权执行自行修改。例如，某些工作负载会自行纵向自动扩缩。虽然很方便，但自行修改会使得已入侵节点的攻击者能够在集群中执行进一步的操作。例如，攻击者可能会使命名空间中的工作负载自行更改，以将其作为在同一命名空间内具有更高权限的 ServiceAccount 运行。

除非必要，否则请勿向 Pod 授予自我修改权限。如果某些 Pod 必须进行自我修改，请使用政策控制器来限制工作负载可以更改的内容。例如，您可以使用 NoUpdateServiceAccount 限制条件模板来防止 Pod 更改其 ServiceAccount。创建政策时，请从限制条件中排除任何集群管理组件，如以下示例所示：

parameters:
  allowedGroups:
  - system:masters
  allowedUsers:
  - system:addon-manager

基于政策的强制执行

以下部分提供了有关使用政策跨多个资源强制执行安全限制的建议。身份和账号管理员以及安全工程师应应用这些建议，以确保集群和工作负载符合组织的安全要求。

最佳实践

在整个 Google Cloud 资源层次结构中强制执行政策

建议：如需在组织、文件夹或项目中强制执行安全实践，请使用组织政策服务。

借助组织政策，您可以集中定义限制条件，并在资源层次结构的各个层级强制执行这些限制条件。各种 Google Cloud 产品发布受管理的限制，让您可以应用针对相应产品的最佳实践建议。例如，GKE 会针对本文档中的许多最佳实践发布受管理的限制条件。

如需详细了解如何启用组织政策，请参阅创建和管理组织政策。

在工作负载准入期间强制执行政策

推荐：使用 Policy Controller 或 PodSecurity 准入控制器等准入控制器来审核传入的 API 请求，并对这些请求强制执行政策。

准入控制器会拦截经过身份验证和授权的 Kubernetes API 请求，以在允许资源保留在 API 中之前执行验证或更改任务。

您可以在 GKE 集群中使用以下方法进行准入控制：

集群管理

以下部分提供了有关如何随时间推移管理集群的建议，例如升级、监控和配置日志。安全工程师、平台管理员和 SRE 应使用这些建议来维护 GKE 平台的安全状况。

最佳实践

定期升级 GKE 基础设施

推荐：保持 GKE 版本为最新版本，以便使用新的安全功能并应用安全补丁。使用发布渠道、加速补丁自动升级和自动节点升级。

Kubernetes 和 GKE 经常发布包含安全改进和漏洞修复的新补丁版本。对于所有集群，GKE 会自动将控制平面升级到更稳定的次要版本和补丁版本。

为确保 GKE 集群运行的是最新版本，请执行以下操作：

  • 在发布渠道中注册集群。Autopilot 集群始终在发布渠道中注册。
  • 对于位于发布渠道中的集群，请启用加速补丁自动升级，以便在安全补丁版本在您的发布渠道中可用时立即获取这些版本。
  • 对于未加入发布渠道的标准集群，请启用自动节点升级。对于从 2019 年 6 月开始使用Google Cloud 控制台创建的集群，以及从 2019 年 11 月 11 日开始使用 GKE API 创建的集群，系统默认启用节点自动升级。
  • 如果您使用维护政策，请使用维护窗口，以便 GKE 每月至少自动升级一次节点。
  • 对于不使用节点自动升级的节点池，请至少每月按照自己的时间安排升级一次节点池。
  • 请关注 GKE 安全公告和 GKE 版本说明，了解安全补丁的相关信息。

启用安全公告通知

推荐：配置有关影响集群的新安全公告的通知。

在有与您的集群相关的安全公告时，GKE 会以消息的形式，将这些事件的通知发布到您配置的 Pub/Sub 主题。您可以在 Pub/Sub 订阅上接收这些通知，与第三方服务集成，并且在 Cloud Logging 中接收通知。

如需在组织中强制执行此建议，请使用 constraints/container.managed.enableSecurityBulletinNotifications 受管理的组织政策限制条件。如需在 Google Cloud 控制台中查看此受管理的限制条件，请前往政策详情页面。

前往政策详情

配置日志收集

建议：为了减少运营开销并维护日志的统一视图，请在集群中实施一致的日志记录策略。请勿在标准集群中停用日志收集。

GKE 集群会将特定日志发送到 Google Cloud Observability。您可以选择配置其他类型的日志收集。 除了系统日志和工作负载日志之外，所有 GKE 集群还会将以下审核日志发送到 Logging：

  • Kubernetes 审核日志：按时间顺序记录对 Kubernetes API 服务器进行的调用。Kubernetes 审核日志条目适合用于调查可疑 API 请求、收集统计信息，或针对不当 API 调用创建监控提醒。
  • GKE 审核日志：GKE API 的管理和访问活动记录。

有关详情，请参阅以下文档：

如需在组织中强制执行此建议，请使用constraints/container.managed.enableCloudLogging 受管理的组织政策限制条件。如需在 Google Cloud 控制台中查看此受管理的限制条件，请前往政策详情页面。

前往政策详情

监控资源是否存在安全问题

使用 GKE 安全状况信息中心和 Security Command Center 监控集群和工作负载是否存在潜在问题。您可以使用这些服务来检查影响 GKE 基础架构的有效漏洞、威胁和安全公告。

默认安全配置

以下部分介绍了在新集群中默认配置的选项，这些选项可缓解特定的安全问题，例如漏洞或风险。安全工程师和平台管理员应验证现有集群是否使用这些设置。

最佳实践

停用旧的客户端身份验证方法

建议：停用旧版 API 服务器身份验证方法，例如静态证书和密码。

向 Kubernetes API 服务器进行身份验证的方法有多种。在 GKE 中，受支持的方法包括服务账号不记名令牌、OAuth 令牌和 X.509 客户端证书。gcloud CLI 使用 OAuth 令牌对 GKE 用户进行身份验证。

旧版身份验证方法（例如静态密码）已被停用，因为这些方法会扩大集群遭到入侵的攻击面。在 Autopilot 集群中，您无法启用或使用这些身份验证方法。

您可以使用以下方法之一向 Kubernetes API 服务器进行身份验证：

  • 用户：使用 gcloud CLI 让 GKE 对用户进行身份验证，为集群生成 OAuth 访问令牌，并保持令牌为最新。
  • 应用：使用工作负载身份联合，让Google Cloud 或其他环境中的应用向您的集群进行身份验证。

如需详细了解如何进行身份验证以及如何停用旧版身份验证方法，请参阅向 Kubernetes API 服务器进行身份验证。

如需在组织中强制执行此建议，请使用 constraints/container.managed.disableLegacyClientCertificateIssuance 受管理的组织政策限制条件。如需在 Google Cloud 控制台中查看此受管理的限制条件，请前往政策详情页面。

前往政策详情

停用 ABAC

建议：使用 IAM 和 RBAC 来控制 GKE 中的访问权限。请勿启用基于属性的访问权限控制 (ABAC)。

ABAC 是一种旧版授权方法，在所有 GKE 集群中默认处于停用状态，并且无法在 Autopilot 集群中启用。

如需在组织中强制执行此建议，请使用 constraints/container.managed.disableABAC 受管理的组织政策限制条件。如需在 Google Cloud 控制台中查看此受管理的限制条件，请前往政策详情页面。

前往政策详情

将 DenyServiceExternalIPs 准入控制器保持启用状态

建议：请勿停用 DenyServiceExternalIPs 准入控制器。

此准入控制器会阻止服务使用 ExternalIP，并缓解 GCP-2020-015。在基于 GKE 1.21 版及更高版本创建的集群中，此准入控制器默认处于启用状态。对于最初在较低 GKE 版本上创建的集群，请启用准入控制器：

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --no-enable-service-externalips
如需在组织中强制执行此建议，请使用constraints/container.managed.denyServiceExternalIPs 受管理的组织政策限制条件。 如需在 Google Cloud 控制台中查看此受管理的限制条件，请前往政策详情页面。

前往政策详情

后续步骤