Kubernetes API 服务器绕过风险
Kubernetes API 服务器是外部方（用户和服务）与集群交互的主要入口点。
作为这一角色的一部分，API 服务器内置了几个关键的安全控制措施，例如审计日志和准入控制器。然而，存在一些可以绕过这些控制措施的方式来修改集群配置或内容。
本页面描述了绕过 Kubernetes API 服务器内置安全控制措施的方式，以便集群管理员和安全架构师能够确保这些绕过方式受到适当的限制。
Static Pods （静态 Pod）
每个节点上的 kubelet 加载并直接管理存储在指定目录中或从特定 URL 获取的清单，作为集群中的static Pods（静态 Pod）。API 服务器不管理这些静态 Pod。具有对此位置写访问权的攻击者可以修改从该源加载的静态 Pod 的配置，或者引入新的静态 Pod。
静态 Pod 受到限制，无法访问 Kubernetes API 中的其他对象。例如，你不能将静态 Pod 配置为挂载集群中的 Secret。然而，这些 Pod 可以执行其他安全敏感的操作，例如使用来自底层节点的 hostPath 挂载。
默认情况下，kubelet 会创建一个镜像 Pod，以便静态 Pod 在 Kubernetes API 中可见。然而，如果攻击者在创建 Pod 时使用无效的命名空间名称，它将不会在 Kubernetes API 中可见，并且只能通过访问受影响主机(s) 的工具来发现。
如果静态 Pod 未通过准入控制，kubelet 不会将 Pod 注册到 API 服务器。然而，该 Pod 仍然在节点上运行。更多信息，请参阅 kubeadm issue #1541。
缓解措施
- 仅当节点需要时才启用 kubelet 静态 Pod 清单功能。
- 如果节点使用静态 Pod 功能，则将静态 Pod 清单目录或 URL 的文件系统访问限制给需要访问的用户。
- 限制对 kubelet 配置参数和文件的访问，以防止攻击者设置静态 Pod 路径或 URL。
- 定期审计和集中报告对托管静态 Pod 清单和 kubelet 配置文件的目录或 Web 存储位置的所有访问。
kubelet API
kubelet 提供了一个 HTTP API，该 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 等机制限制对
nodesAPI 对象子资源的访问。仅在需要时才授予此访问权限，例如监控服务。 - 限制对 kubelet 端口的访问。只允许指定的和受信任的 IP 地址范围访问该端口。
- 确保kubelet 认证设置为 webhook 或证书模式。
- 确保集群上未启用未认证的“只读”Kubelet 端口。
etcd API
Kubernetes 集群使用 etcd 作为数据存储。etcd 服务在 TCP 端口 2379 上监听。唯一需要访问的客户端是 Kubernetes API 服务器以及你使用的任何备份工具。直接访问此 API 允许泄露或修改集群中保存的任何数据。
对 etcd API 的访问通常通过客户端证书认证来管理。etcd 信任的任何证书颁发机构颁发的证书都允许完全访问 etcd 中存储的数据。
直接访问 etcd 不受 Kubernetes 准入控制的影响，也不会被 Kubernetes 审计日志记录。拥有 API 服务器 etcd 客户端证书私钥读访问权（或可以创建新的受信任客户端证书）的攻击者可以通过访问集群 Secret 或修改访问规则来获取集群管理员权限。即使不提升其 Kubernetes RBAC 权限，能够修改 etcd 的攻击者也可以检索任何 API 对象或在集群内创建新的工作负载。
许多 Kubernetes 提供商将 etcd 配置为使用双向 TLS（客户端和服务器都验证对方证书进行认证）。尽管 etcd API 的授权功能存在，但目前没有被广泛接受的实现。由于没有授权模型，任何拥有 etcd 客户端访问权限的证书都可以用来获取对 etcd 的完全访问权限。通常，仅用于健康检查的 etcd 客户端证书也可以授予完全的读写访问权限。
缓解措施
- 确保 etcd 信任的证书颁发机构仅用于该服务的认证目的。
- 控制对 etcd 服务器证书私钥以及 API 服务器客户端证书和密钥的访问。
- 考虑在网络层面限制对 etcd 端口的访问，仅允许指定的和受信任的 IP 地址范围访问。
容器运行时套接字
在 Kubernetes 集群的每个节点上，与容器交互的访问由容器运行时（如果你配置了多个运行时）控制。通常，容器运行时会暴露一个 Unix 套接字，kubelet 可以访问该套接字。有权访问此套接字的攻击者可以启动新的容器或与正在运行的容器交互。
在集群级别，此访问的影响取决于在受攻击节点上运行的容器是否可以访问 Secrets 或攻击者可以用来升级权限以访问其他工作节点或控制平面组件的其他机密数据。
缓解措施
- 确保你严格控制对容器运行时套接字的 文件系统访问。在可能的情况下，将此访问限制给
root用户。 - 使用 Linux 内核命名空间等机制将 kubelet 与节点上运行的其他组件隔离开。
- 确保你限制或禁止使用包含容器运行时套接字（无论是直接包含还是通过挂载父目录包含）的
hostPath挂载。此外，hostPath挂载必须设置为只读，以减轻攻击者绕过目录限制的风险。 - 限制用户对节点的访问，特别是限制超级用户对节点的访问。