Kubernetes API 服务器绕过风险

与 API 服务器和其他组件相关的安全架构信息

Kubernetes API 服务器是外部方(用户和服务)与集群交互的主要入口点。

作为此角色的一部分,API 服务器具有几个关键的内置安全控制,例如审计日志记录和准入控制器。但是,有些方法可以修改集群的配置或内容,从而绕过这些控制。

此页面描述了可以绕过 Kubernetes API 服务器中内置的安全控制的方法,以便集群操作员和安全架构师可以确保对这些绕过进行适当的限制。

静态 Pod

每个节点上的 kubelet 加载并直接管理存储在命名目录中或从特定 URL 获取的任何清单,作为集群中的静态 Pod。API 服务器不管理这些静态 Pod。具有此位置写权限的攻击者可以修改从该源加载的静态 Pod 的配置,或者可以引入新的静态 Pod。

静态 Pod 被限制访问 Kubernetes API 中的其他对象。例如,您不能配置静态 Pod 从集群挂载 Secret。但是,这些 Pod 可以执行其他安全敏感的操作,例如使用来自底层节点的 hostPath 挂载。

默认情况下,kubelet 创建一个 镜像 Pod,以便静态 Pod 在 Kubernetes API 中可见。但是,如果攻击者在创建 Pod 时使用无效的命名空间名称,则它在 Kubernetes API 中将不可见,并且只能通过有权访问受影响主机工具来发现。

如果静态 Pod 未通过准入控制,kubelet 将不会向 API 服务器注册该 Pod。但是,该 Pod 仍然在节点上运行。有关更多信息,请参阅 kubeadm 问题 #1541

缓解措施

  • 仅在节点需要时启用 kubelet 静态 Pod 清单功能
  • 如果节点使用静态 Pod 功能,请将对静态 Pod 清单目录或 URL 的文件系统访问限制为需要访问的用户。
  • 限制对 kubelet 配置参数和文件的访问,以防止攻击者设置静态 Pod 路径或 URL。
  • 定期审计并集中报告对托管静态 Pod 清单和 kubelet 配置文件的目录或 Web 存储位置的所有访问。

kubelet API

kubelet 提供一个 HTTP API,通常在集群工作节点的 TCP 端口 10250 上公开。根据使用的 Kubernetes 发行版,API 也可能在控制平面节点上公开。直接访问 API 可以泄露有关在节点上运行的 Pod 的信息、来自这些 Pod 的日志以及在节点上运行的每个容器中执行的命令。

当 Kubernetes 集群用户具有对 Node 对象子资源的 RBAC 访问权限时,该访问权限可用作与 kubelet API 交互的授权。确切的访问权限取决于已授予哪个子资源访问权限,如kubelet 授权中所详述。

直接访问 kubelet API 不受准入控制,并且不会被 Kubernetes 审计日志记录。可以直接访问此 API 的攻击者可能能够绕过检测或阻止某些操作的控制。

可以配置 kubelet API 以多种方式验证请求。默认情况下,kubelet 配置允许匿名访问。大多数 Kubernetes 提供商将默认值更改为使用 Webhook 和证书身份验证。这使控制平面可以确保调用者被授权访问 nodes API 资源或子资源。默认的匿名访问不会向控制平面发出此断言。

缓解措施

  • 使用诸如 RBAC之类的机制限制对 nodes API 对象子资源的访问。仅在需要时才授予此访问权限,例如监控服务。
  • 限制对 kubelet 端口的访问。仅允许指定的和受信任的 IP 地址范围访问该端口。
  • 确保将kubelet 身份验证设置为 Webhook 或证书模式。
  • 确保未在集群上启用未经身份验证的“只读”Kubelet 端口。

etcd API

Kubernetes 集群使用 etcd 作为数据存储。etcd 服务在 TCP 端口 2379 上监听。唯一需要访问的客户端是 Kubernetes API 服务器和您使用的任何备份工具。直接访问此 API 可以泄露或修改集群中持有的任何数据。

对 etcd API 的访问通常由客户端证书身份验证管理。由 etcd 信任的证书颁发机构颁发的任何证书都可以完全访问存储在 etcd 中的数据。

直接访问 etcd 不受 Kubernetes 准入控制,并且不会被 Kubernetes 审计日志记录。具有 API 服务器的 etcd 客户端证书私钥读取访问权限(或可以创建新的受信任客户端证书)的攻击者可以通过访问集群机密或修改访问规则来获得集群管理员权限。即使没有提升其 Kubernetes RBAC 权限,可以修改 etcd 的攻击者也可以检索任何 API 对象或在集群内创建新的工作负载。

许多 Kubernetes 提供商将 etcd 配置为使用相互 TLS(客户端和服务器都验证彼此的证书以进行身份验证)。尽管该功能存在,但对于 etcd API 的授权没有广泛接受的实现。由于没有授权模型,因此可以使用任何具有对 etcd 客户端访问权限的证书来获得对 etcd 的完全访问权限。通常,仅用于运行状况检查的 etcd 客户端证书也可以授予完全的读取和写入访问权限。

缓解措施

  • 确保 etcd 信任的证书颁发机构仅用于对该服务进行身份验证的目的。
  • 控制对 etcd 服务器证书的私钥以及对 API 服务器的客户端证书和密钥的访问。
  • 考虑在网络级别限制对 etcd 端口的访问,以仅允许来自指定的和受信任的 IP 地址范围的访问。

容器运行时套接字

在 Kubernetes 集群中的每个节点上,与容器交互的访问由容器运行时(或运行时,如果您配置了多个)控制。通常,容器运行时公开 kubelet 可以访问的 Unix 套接字。具有此套接字访问权限的攻击者可以启动新容器或与正在运行的容器进行交互。

在集群级别,这种访问的影响取决于在受损节点上运行的容器是否有权访问机密或其他机密数据,攻击者可以使用这些数据将权限提升到其他工作节点或控制平面组件。

缓解措施

  • 确保您严格控制对容器运行时套接字的文件系统访问。如果可能,请将此访问限制为 root 用户。
  • 使用诸如 Linux 内核命名空间之类的机制,将 kubelet 与节点上运行的其他组件隔离。
  • 确保限制或禁止使用包含容器运行时套接字的 hostPath 挂载,无论是直接挂载还是挂载父目录。此外,必须将 hostPath 挂载设置为只读,以降低攻击者绕过目录限制的风险。
  • 限制用户对节点的访问,特别是限制超级用户对节点的访问。
上次修改时间为 2023 年 2 月 6 日上午 9:55 PST: 清理 api-server-bypass-risks.md (42e746a379)