GKE 安全的基本概述
GKE 在许多层中保护您的工作负载，包括容器映像、运行时、集群网络以及对集群 API 服务器的访问。
因此，Google 建议采用分层的方法来保护您的集群和工作负载。为组织启用适当级别的灵活性和安全性以部署和维护工作负载可能需要一定程度的权衡，因为某些设置可能过于严格。
GKE 安全最关键的方面包括以下内容：
身份验证和授权;
控制平面安全性，包括组件和配置;
节点安全;
网络安全。
这些元素也反映在CIS基准中，这有助于围绕Kubernetes的安全配置构建工作。
为什么CIS基准对GKE安全至关重要？
处理 K8s 安全配置并不像是在公园里散步。
红帽 2022 年 Kubernetes 和容器安全现状发现，几乎四分之一的严重问题是可以修复的漏洞。近 70% 的事件是由于配置错误而发生的。
自互联网安全中心（CIS）发布以来，基准已成为全球公认的实施和管理网络安全机制的最佳实践。
CIS Kubernetes 基准测试涉及支持强大安全态势的 K8s 配置建议。它是为开源的 Kubernetes 发行版编写的，并且基本普遍适用。
独联体GKE基准测试实践
使用像 GKE 这样的托管服务，并非所有 CIS 基准上的项目都在您的控制之下。
这就是为什么有些建议不能直接自行审核或修改的原因。这些涉及：
控制平面;
Kubernetes 发行版;
节点的操作系统。
但是，您仍然需要注意升级运行工作负载的节点，当然还有工作负载本身。需要审核和修正对这些组件的任何建议。
您可以手动执行此操作，也可以使用处理 CIS 基准测试的工具。例如，使用 CAST AI 的容器安全模块，您可以在连接集群后的几分钟内大致了解基准差异。
该平台还会优先处理它识别的问题，以便您知道哪些项目需要优先修复。扫描集群时，您还可以根据行业最佳实践进行检查，以便更好地评估整体安全状况并计划进一步的 GKE 强化。
确保 GKE 安全的十大策略
1. 应用最小特权原则
此基本安全原则是指仅授予用户帐户执行预期功能所必需的权限。
它包含在 CIS GKE 基准 6.2.1 中：不希望使用计算引擎默认服务帐户运行 GKE 集群。
默认情况下，您的节点可以访问计算引擎服务帐户。它的广泛访问权限使其对多个应用程序有用，但它也具有比运行 GKE 集群所需的更多权限。这就是为什么您必须创建和使用最低特权服务帐户而不是默认帐户的原因。
2. 使用 RBAC 加强身份验证和授权
GKE 支持多个选项，用于通过基于角色的访问控制 （RBAC） 管理对集群的访问。
RBAC 支持在群集和命名空间级别更精细地访问 Kubernetes 资源，但它也允许你创建详细的权限策略。
CIS GKE 基准 6.8.4 强调需要优先使用 RBAC，而不是传统的基于属性的访问控制 （ABAC）。
另一个 CIS GKE 基准 （6.8.3） 建议使用组来管理用户，因为它简化了对身份和权限的控制。它还消除了在组中添加或删除用户时更新 RBAC 配置的需要。
3. 增强控制平面的安全性
在责任共担模式下，Google 会为您管理 GKE 控制平面组件。但是，您仍负责保护节点、容器和 Pod。
默认情况下，Kubernetes API 服务器使用公共 IP 地址。可以使用授权网络和专用群集来保护它，这使您能够分配专用 IP 地址。
您还可以通过执行常规凭据轮换来增强控制平面的安全性。启动该过程时，TLS 证书和群集证书颁发机构将自动轮换。
4. 定期升级您的 GKE 基础设施
Kubernetes 经常发布新的安全功能和补丁，因此让您的 K8s 保持最新状态是改善安全状况的最简单方法之一。
GKE 会自动为您修补和升级控制平面。节点自动升级也会自动升级集群中的节点。CIS GKE 基准 6.5.3 建议保持该设置。
如果出于任何原因，您需要禁用自动升级，Google 建议每月执行一次升级，并按照 GKE 安全公告了解关键补丁。
5. 保护节点元数据
CIS GKE 基准 6.4.1 和 6.4.2 提到了影响节点安全性的两个关键因素，这仍然是您的责任。
v0.1 和 v1beta1 计算引擎元数据服务器终结点在 2020 年被弃用并关闭，因为它们没有强制实施元数据查询标头。
一些针对 Kubernetes 的攻击依赖于访问虚拟机的元数据服务器来提取凭据。可以使用工作负载标识或元数据隐藏来防止这些攻击。
6. 禁用 Kubernetes 仪表板
几年前，攻击者获得特斯拉云资源并使用它们来挖掘加密货币的消息使世界感到震惊。在这种情况下，攻击媒介是一个 Kubernetes 仪表板，它向公众公开，没有身份验证或提升的权限。
如果您想避免跟随特斯拉的困境，建议遵守 CIS GKE 基准 6.10.1。该标准清楚地概述了在 GKE 上运行时应禁用 Kubernetes Web UI。
默认情况下，GKE 1.10 及更高版本禁用 K8s 仪表板。您还可以使用以下代码：
gcloud container clusters update CLUSTER_NAME \
--update-addons=KubernetesDashboard=DISABLED
7. 遵循 NSA-CISA 框架
CIS Kubernetes Benchmark 为构建安全的运营环境提供了坚实的基础。但是，如果您想走得更远，请在安全程序中为 NSA-CISA Kubernetes 强化指南腾出空间。
NSA-CISA 报告概述了 Kubernetes 生态系统中的漏洞，并推荐了配置集群安全性的最佳实践。
它提供了有关漏洞扫描、识别错误配置、日志审核和身份验证的建议，帮助您确保适当解决常见的安全挑战。
8. 提高您的网络安全
在 GKE 中运行的大多数工作负载都需要与集群内外运行的其他服务进行通信。但是，您可以控制允许流经集群的流量。
首先，您可以使用网络策略来限制容器到容器的通信。默认情况下，可以通过网络访问所有群集 Pod IP 地址。您可以通过定义流经 Pod 的流量并为与配置的标签不匹配的流量停止它来锁定命名空间中的连接。
其次，您可以使用网络负载均衡器来平衡 Kubernetes Pod。为此，您需要创建与容器标签匹配的负载均衡器服务。您将拥有一个面向外部的 IP 映射到 Kubernetes Pod 上的端口，并且您将能够使用 kube-proxy 在节点级别过滤授权流量。
9. 保护容器对谷歌云资源的访问
您的容器和容器可能需要访问 Google Cloud 中的其他资源。有三种方法可以执行此操作：使用工作负载标识、节点服务帐户和服务帐户 JSON 密钥。
访问 Google Cloud 资源的最简单、最安全的选项是使用工作负载标识。此方法允许您在 GKE 上运行的 Pod 获取对 Google Cloud 服务帐户的权限。
您应该使用特定于应用的 Google Cloud 服务帐号来提供凭据，以便应用拥有在发生泄露时可以撤销的最低必要权限。
10. 获取 GKE 配置的密钥管理器
独联体 GKE 基准 6.3.1.建议使用云 KMS 中管理的密钥加密 Kubernetes 密钥。
Google Kubernetes Engine 为您提供了多种秘密管理选项。您可以在 GKE 中原生使用 Kubernetes 机密，但您也可以使用您管理的密钥和应用层机密加密在应用程序层保护这些机密。
还有像Hashicorp Vault这样的机密管理器，它们提供了一种一致的、生产就绪的方式来管理GKE中的机密。确保检查您的选项并选择最佳解决方案。
在几分钟内评估 GKE 的安全性
Kubernetes 生态系统不断增长，但其安全配置挑战也在不断增长。如果您想掌握 GKE 容器安全性，您需要能够识别潜在威胁并有效地跟踪它们。
借助 Kubernetes 安全报告，您可以根据 CIS 基准、NSA-CISA 框架和其他容器安全最佳实践扫描 GKE 集群，以识别漏洞、发现错误配置并确定其优先级。只需几分钟即可全面了解集群的安全状况。
