随着 Kubernetes 的发展和改进，新的安全威胁和风险也逐渐向 K8s 转移，因此 K8s 安全性变得越来越重要，而保护 K8s 集群已成为 DevOps 团队不容忽视的重要任务。K8s 有多种实现类型（本地、云管理、混合等）、众多开源支持工具和各种配置设置，且保护运行容器工作负载的任何安全敏感架构的需求也在增长。
根据 CNCF 的 K8s 安全审计调查，攻击者可以通过利用各种 K8s 漏洞和几种标准配置进行非法行为。今天，我们将探讨一些实施保障 K8s 安全的最佳实践。
K8s 是一个用于管理容器（容器化应用程序）的系统，容器则可以理解为是一个轻量级的虚拟机。要创建应用程序，就需要先创建一些容器并使用 K8s 来管理这些容器。这确实是一个庞大且快速扩展的生态系统，并且 K8s 的设施、支持和工具相对比较容易获得。K8s 可以立即生成和扩展容器，并跨所有容器管理存储。
K8s 集群是包含所有 K8s 组件的K8s 系统。集群可以在物理机（如 PC 或笔记本电脑）或虚拟机上运行。如果你有一台机器运行完整的 K8s 系统，则该机器托管您的 K8s 集群；假设你有两台机器运行 K8s，这两台机器都会组织你的 K8s 集群。集群可以在物理机和虚拟机的任意组合上运行。
7步保护 K8s 集群安全
接下来我们一起看看企业应该实施哪些安全最佳实践来确保其 K8s 集群的安全性。
1. 将 K8s 升级到最新版本
最基本且经常被忽视的安全最佳实践是将 K8s 生态系统保持最新状态。企业将受益于新的安全功能和错误跟踪更新以及变体版本。此外，在启动到生产集群之前，请在测试环境中使用最新的完整版本。
2. 验证 Kubernetes API 服务器
Kubernetes API 服务器，也被称为 Kube-API 服务器，是 K8s 集群的核心。K8s API 是 K8s 集群的主要访问点。管理员或服务帐户可以通过命令行实用程序 kubectl、REST API 调用或其他客户端 SDK 访问 API。服务器提供访问并保证集群是可操作的。所有在集群内部调用的 API 尝试都应该使用加密的传输层安全性。建议采用完全符合访问控制规则的 API 服务器的 API 身份验证方法。
3. 启用 RBAC 授权机制
RBAC 即基于角色的访问控制机制，允许多个应用程序基于最小权限执行具体操作，并且仅授予执行必要的权限。管理员应遵循以下 K8s RBAC 最佳实践：
- 使用
–authorization-mode=RBAC参数在 API 服务器中启用 RBAC，强制 RBAC 作为集群安全的标准配置。 - 为每个应用程序使用专用的用户服务帐户，而不是 K8s 创建的默认服务帐户。专用服务帐户允许管理员对每个应用程序强制执行 RBAC，并更好地控制提供给每个应用程序资源的细粒度权限。
- 减少可选 API 服务器标志的数量，以减少 API 服务器的攻击面。每个标志都有助于集群管理的特定方面，这可能会也可能不会暴露 API 服务器。减少以下可选标志的使用：例如匿名身份验证， 不安全的绑定地址，和不安全端口。
- 定期调整和更新 RBAC 政策。首先删除不再需要的任何权限，这个动作可能很耗时，但能有效保障安全。
- 强制执行最低权限以使 RBAC 系统生效。当集群管理员遵循 Pareto 原则时，只将所需的权限分配给用户或应用程序。不应授予额外权限，应避免使用通配符
[“*”]或一揽子访问。
4. 提高节点安全性
首先加强运行 pod 节点安全性：
- 配置的标准和基准。根据安全建议配置主机。使用与特定 K8s 版本相关的 Internet 安全中心基准验证集群。
- 最小化管理访问。通过限制管理访问来减少 K8s 节点上的攻击面。
- 节点上进行隔离和约束。在特定节点上执行特定的 pod，这样可以确保 pod 在具有特定隔离和安全设置的节点上运行。
向节点对象添加标签以允许 pod 专门针对节点，从而控制 pod 可以访问哪些节点。应用节点标签后，将节点选择器添加到 pod 部署中，以便 pod 对所选节点进行显着更改。
5. 控制 kubelet 访问权限
kubelet 发挥着在每个集群节点上持续运行的操作员的作用。它通过 API 与用户通信，这些 API 管理试图在节点上运行并执行特定任务的 pod。未经授权向 kubelet 披露为攻击者提供了 API 访问权限，并可能危及节点或集群的安全。
要减少攻击面并防止通过 kubelet 对 API 进行未经授权的访问，请执行以下步骤：
- 在启动 kubelet 之前，将
-anonymous-auth标志设置为false以禁用匿名访问：-anonymous-auth=false。 - 使用
-kubelet-client-certificate和-kubelet-client-key标志开始 Kube-Episerver 命令。这可确保 API 服务器对 kubelet 进行身份验证并防止匿名请求。 - kubelet 提供了一个只读 API，管理员无需登录即可使用。这样可能会暴露潜在的敏感集群信息，管理员应使用以下命令关闭只读端口：
—read-only-port=0。
6. 配置命名空间和网络策略
命名空间将敏感工作负载与非敏感工作负载区分开来。处理多个命名空间可能会有些困难，但这使得实现安全控制变得更简单，例如管理性能的网络策略以调节进出 pod 的流量。
7. 启用审计日志
启用 K8s 审计日志并监督它们是否存在非法行为和可疑的 API 调用。K8s 可以保存集群活动的详细记录，所以我们可以立即在审核日志中检测到可能的安全问题。例如，攻击者试图暴力破解密码可能会创建身份验证和授权日志。如果这些行为反复出现，则可能存在安全问题。
要启用审计日志，需使用 K8s 审计策略，允许管理员根据情况配置审计级别：
-
None– 与此规则匹配的事件将不会被记录。 -
Metadata– 记录请求的元数据，例如请求用户、时间戳、资源和动词。 -
Request– 记录事件的元数据以及请求正文，但不记录响应正文。这不适用于对非资源的请求。 -
RequestResponse– 跟踪事件元数据、请求和响应正文。这不适用于对非资源的请求。
这些信息的大部分由 K8s 审计日志记录，并且与集群 API 的简单结合允许您将这些日志发送到外部日志记录和存储解决方案。同时还可以生成仪表板、可疑行为警报和事件调查报告。
总结
依赖 K8s 作为后端的 DevOps 团队必须意识到集群和可以在其中运行的 Docker 容器可能面临的所有风险和攻击。由于可用的攻击向量种类繁多、技术的不断进步以及该工具的一致、广泛采用，恶意攻击者发现渗透集群能够有效发起攻击并获得利益。保护 K8s 集群是一项艰巨的任务，密切关注并尽可能检测系统漏洞或恶意攻击行为至关重要。