Kubelet 认证与授权

Tip

学习并练习 AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
学习并练习 GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
学习并练习 Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

Kubelet 认证

来自官方文档：

默认情况下，发送到 kubelet 的 HTTPS 端点的请求（若未被其他配置的认证方法拒绝）将被视为匿名请求，并被赋予 用户名为 system:anonymous 和 组为 system:unauthenticated。

以下是 3 种认证 方法：

  • 匿名 (默认): 通过设置参数 --anonymous-auth=true 或在配置中：
"authentication": {
"anonymous": {
"enabled": true
},
  • Webhook：这将启用 kubectl 的 API bearer tokens 作为授权（任何有效的 token 都会被视为有效）。通过以下方式允许：
  • 确保在 API 服务器中启用了 authentication.k8s.io/v1beta1 API 组
  • 使用 --authentication-token-webhook 和 --kubeconfig 标志启动 kubelet，或使用以下设置：
"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},

Note

kubelet 在配置的 API server 上调用 TokenReview API，从 bearer tokens 确定用户信息

  • X509 client certificates: 允许通过 X509 客户端证书进行认证
  • 参见 apiserver authentication documentation 获取更多详情
  • 使用 --client-ca-file 参数启动 kubelet，提供一个 CA bundle 用于验证客户端证书。或者使用配置：
"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}

Kubelet 授权

任何被成功认证的请求（包括匿名请求）随后会被授权。默认的授权模式是 AlwaysAllow，它允许所有请求。

然而，另一个可能的值是 webhook（这也是你在实际环境中最常看到的）。该模式会检查已认证用户的权限以决定是否允许某个操作。

Warning

注意，即使匿名认证已启用，匿名访问也可能没有任何权限来执行任何操作。

通过 webhook 进行的授权可以通过**参数 --authorization-mode=Webhook**或通过配置文件来配置：

"authorization": {
"mode": "Webhook",
"webhook": {
"cacheAuthorizedTTL": "5m0s",
"cacheUnauthorizedTTL": "30s"
}
},

kubelet 在配置的 API server 上调用 SubjectAccessReview API 以 确定 每个请求是否被 授权。

kubelet 使用与 apiserver 相同的 request attributes 方法来授权 API 请求：

  • 操作
HTTP verbrequest verb
POSTcreate
GET, HEADget (for individual resources), list (for collections, including full object content), watch (for watching an individual resource or collection of resources)
PUTupdate
PATCHpatch
DELETEdelete (for individual resources), deletecollection (for collections)
  • 与 Kubelet API 通信的 resource 始终是 nodes，subresource 根据传入请求的路径 确定：
Kubelet APIresourcesubresource
/stats/*nodesstats
/metrics/*nodesmetrics
/logs/*nodeslog
/spec/*nodesspec
all othersnodesproxy

Note

WebSocket-based /exec, /run, /attach, and /portforward fall into the default proxy subresource and are authorized using the initial HTTP GET handshake. A principal with only nodes/proxy GET can still exec containers if it connects directly to https://<node_ip>:10250 over WebSockets. See the nodes/proxy GET -> Kubelet /exec verb confusion abuse for details.

例如，下面的请求尝试在没有权限的情况下访问 kubelet 的 pods 信息：

curl -k --header "Authorization: Bearer ${TOKEN}" 'https://172.31.28.172:10250/pods'
Forbidden (user=system:node:ip-172-31-28-172.ec2.internal, verb=get, resource=nodes, subresource=proxy)
  • 我们收到了一个 Forbidden，所以该请求通过了认证检查。如果没有，我们只会收到一个 Unauthorised 消息。
  • 我们可以看到用户名（在本例中来自 token）
  • 注意 resource 为 nodes，subresource 为 proxy（这与之前的信息一致）

参考

Tip

学习并练习 AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
学习并练习 GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
学习并练习 Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks