小编点评

**10 大 K8s 安全风险和解决方案** **1. K8s SecretSecret** * 解决方案：使用密钥管理工具（例如 Keycloak 或 Vault）来管理 Secret。 * 建议：仅用于已信任来源的 Secret。 **2. 容器镜像安全** * 解决方案：使用安全镜像源（例如 Docker Hub 或 Azure Container Registry）获取镜像。 * 建议：定期扫描和更新镜像。 **3. 运行时威胁** * 解决方案：使用主机级别安全策略（例如 SecurityContext）来限制容器访问。 * 建议：对容器运行时环境进行严格的控制。 **4. 集群错误配置** * 解决方案：仔细阅读 K8s 文档并确保所有配置参数正确设置。 * 建议：使用 K8s 管理工具（例如 Helm）来自动化配置。 **5. RBAC 策略配置** * 解决方案：只为受信任角色分配 RBAC 权限。 * 建议：对 RBAC 策略进行定期审查和更新。 **6. 网络策略** * 解决方案：严格控制 pod、命名空间和 IP Blocks 的网络访问。 * 建议：使用 CNI (Container Network Interface) 来管理网络配置。 **7. 监控和审计** * 解决方案：监控应用程序部署过程和集群状态。 * 建议：使用 K8s 管理工具（例如 Prometheus 或 Grafana）来创建自定义监控图表。 **8. K8s APIK8s API** * 解决方案：使用最新的稳定版本的 K8s 并尽早修复集群。 * 建议：使用自动化工具进行版本控制。 **9. 资源限制** * 解决方案：设置资源请求和限制以确保安全和性能。 * 建议：仅为必需的容器设置资源限制。 **10. 数据加密** * 解决方案：对集群中的关键数据进行加密。 * 建议：使用 K8s 的存储插件（例如 PersistentVolume）来管理加密。

正文

Kubernetes （K8s）是现代云原生世界中的容器管理平台。它实现了灵活、可扩展地开发、部署和管理微服务。K8s 能够与各种云提供商、容器运行时接口、身份验证提供商和可扩展集成点一起工作。然而 K8s 的集成方法可以在任何基础设施上运行任何容器化应用程序，这使得围绕 K8s 和其上的应用程序堆栈创建整体安全性面临挑战。根据 Red Hat 的 2022 年 K8s 安全报告，在过去 12 个月的过程中，几乎所有参与研究的 K8s 用户都经历过至少一次安全事件。因此，可以说 K8s 环境在默认情况下并不安全，并且容易面临风险。
 

本文将讨论 10 大 K8s 安全风险，并就如何避免这些风险给出提示。
 

1. K8s Secret

Secret 是 K8s 的核心构建块之一，用于存储密码、证书或令牌等敏感数据，并在容器内使用它们。与 K8s Secret 相关的三个关键问题：

• Secrets 将敏感数据存储为 base-64 编码字符串，但默认情况下不加密。K8s 确实提供了存储资源的加密，但用户需要对其进行配置。此外，关于机密的最大威胁是同一命名空间中的任何 pod，以及在 pod 内运行的任何应用程序都可以访问和读取它们。
• 基于角色的访问控制（RBAC）控制谁有权访问 K8s 资源。用户需要正确配置 RBAC 规则，以便只有相关人员和应用程序才能访问机密。
• Secrets 和 ConfigMaps 是将数据传递给正在运行的容器的两种方法。如果有旧的和未使用的 Secrets 或 ConfigMap 资源，会造成混乱并泄漏易受攻击的数据。例如，如果用户删除了后端应用程序部署但忘记删除包含的数据库密码的机密，那么将来任何恶意 pod 都可以使用这些敏感数据。
   

2. 存在漏洞的容器镜像

K8s 是一个容器编排平台，在工作节点上分发和运行容器。但是它不会检查容器的内容是否存在安全漏洞或暴露。因此，需要在部署前对镜像进行扫描，以确保只有来自可信镜像仓库且没有严重漏洞（如远程代码执行）的镜像才会在集群上运行。容器镜像扫描也应该集成到 CI/CD 系统中，以实现自动化和更早地检测问题和缺陷。
 

3. 运行时威胁

K8s 工作负载（即容器）在工作节点上运行，容器在运行时由主机操作系统控制。如果存在宽松政策或存在漏洞的容器镜像，可能会为整个集群打开后门。因此，需要操作系统级别的运行时保护来加强运行时的安全性，而针对运行时威胁和漏洞的最重要的保护，在整个 K8s 中实现最小特权原则。
 

4. 集群错误配置和默认配置

K8s API 及其组件由一组复杂的资源定义和配置选项组成。因此，K8s 为其大部分配置参数提供了默认值，并试图消除创建长 YAML 文件的负担。但是，用户需要注意与集群和资源配置相关的三个关键问题：

• 虽然默认的 K8s 配置很实用，因为可以提高使用的灵活性和敏捷性，但它们并不总是最安全的选择。
• K8s 资源的在线示例有助于入门，但在参考时需要检查这些示例资源定义将部署到集群的内容。
• 在集群上工作时，通常使用“kubectl edit”命令更改 K8s 资源。但如果用户忘记更新源文件，更改将在下一次部署中被覆盖，并且未跟踪的修改可能会埋下安全隐患。
   

5. K8s 中的 RBAC 策略

RBAC 管理和控制 K8s 资源授权方式。因此，配置和维护 RBAC 策略对于保护集群避免不必要的访问至关重要。使用 RBAC 策略时需要考虑两个关键点。首先，一些 RBAC 策略过于宽松，比如 cluster_admin 角色，它基本拥有集群中的所有权限。这些角色被分配给一般开发人员，使他们能够敏捷完成开发人。但如果出现安全漏洞，攻击者可以使用 cluster_admin 快速获得对集群的高级访问权限。为避免这种情况，用户需要为特定资源配置 RBAC 策略并将全线分配给特定的用户组。
 

另外，软件开发生命周期中存在各种环境，如开发、测试、预发布和生产。此外，还有开发人员、测试人员、运营人员和云管理员等多个侧重点不同的团队。应为每个组和每个环境正确分配 RBAC 策略。
 

6. 网络接入

在 K8s 中，一个 pod 可以连接到集群外部的其他 pod 和外部地址；默认情况下，其他人可以从集群内部连接到此 pod。网络策略用于管理和限制 pod、命名空间和 IP Blocks 之间的网络访问。网络策略可以与 pod 上的标签一起使用，而标签的不当使用可能会导致不必要的访问。此外，当集群位于云提供商处时，集群网络应该与虚拟私有云 (VPC) 的其余部分隔离。
 

7. 整体监控和审计日志

当用户将应用程序部署到 K8s 集群时，仅依靠监控应用程序指标是不够的。还必须观察 K8s 集群的状态、云基础设施和云控制器，以全面了解整个堆栈。监视漏洞和检测异常也很重要，因为恶意攻击者会测试从每个可能的开口来访问集群。K8s 为集群中与安全相关的事件提供开箱即用的审计日志。即便如此，用户依旧需要从各种应用程序收集记录并在一个中心位置监控集群健康状况。
 

8. K8s API

K8s API 是整个系统的核心，所有内部和外部客户端都与 K8s 进行连接和通信。如果用户在内部部署和管理 K8s 组件则需要更加小心，因为** K8s API 服务器及其组件是具有潜在和实际漏洞的开源工具**。因此用户应该使用最新的稳定版本的 K8s 并尽早修复集群。
 

如果使用云提供商，K8s 控制面板由提供商控制，云基础设施会自动更新和打补丁。但是在大多数情况下用户需要自行负责升级工作节点。因此，用户可以使用自动化和资源供应工具轻松升级节点或更换新节点。
 

9. K8s 资源请求和限制

除了调度和运行容器，K8s 还可以在 CPU 和内存方面限制容器的资源使用。资源请求和限制至关重要，原因有两点：

• 安全性：当 pod 和命名空间不受限制时，即使是具有安全漏洞的单个容器也可以访问集群内的敏感数据。
• 成本：当请求的资源超过实际使用量时，节点将耗尽可用资源。如果启用自动缩放，这将导致节点池增加，新节点将不可避免地增加您的云费用。
   

当资源请求被正确计算和分配时，整个集群在 CPU 和内存方面高效工作。此外，当设置资源限制时，故障应用程序和恶意攻击者都将在资源使用方面受到限制。如果没有资源限制，恶意容器可能会消耗节点中几乎所有的资源并使应用程序无法使用。
 

10. 数据与存储

K8s 让有状态的容器化应用程序可扩展且可靠地运行成为可能。借助 StatefulSet 资源，用户可以快速将数据库、数据分析工具和机器学习应用程序部署到 K8s 中。这些数据将作为连接到容器的卷供 Pod 访问。

通过策略和标签限制访问来避免集群中其他 pod 进行不必要的访问至关重要。此外，K8s 中的存储是由外部系统提供的，因此用户应该考虑对集群中的关键数据进行加密。如果用户管理存储插件，还应该检查安全参数以确保它们已启用。
 

参考链接：
https://www.darkreading.com/dr-tech/top-10-K8s-security-risks-every-devsecops-needs-to-know
https://www.redhat.com/en/blog/state-K8s-security-2022-1
https://K8s.io/docs/concepts/workloads/controllers/statefulset/