随着 Kubernetes 的发展和改进，新的安全威胁和风险也逐渐向 K8s 转移，因此 K8s 安全性变得越来越重要，而保护 K8s 集群已成为 DevOps 团队不容忽视的重要任务。K8s 有多种实现类型（本地、云管理、混合等）、众多开源支持工具和各种配置设置，且保护运行容器工作负载的任何安全敏感架构的需求也在增长。
根据 CNCF 的 K8s 安全审计调查，攻击者可以通过利用各种 K8s 漏洞和几种标准配置进行非法行为。今天，我们将探讨一些实施保障 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 集群是一项艰巨的任务，密切关注并尽可能检测系统漏洞或恶意攻击行为至关重要。
