7 步保障 Kubernetes 集群安全

随着 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 进行未经授权的访问 , 请执行以下步骤: