Sponsored

Kubelet Authentication & Authorization

Kubelet Authentication

From the docss:

By default, requests to the kubelet's HTTPS endpoint that are not rejected by other configured authentication methods are treated as anonymous requests, and given a username of system:anonymous and a group of system:unauthenticated.[1]

The 3 authentication methods are:[1]

  • Anonymous (default): Use set setting the param --anonymous-auth=true or the config:[1][4]
"authentication": {
    "anonymous": {
      "enabled": true
    },
  • Webhook: This will enable the kubectl API bearer tokens as authorization (any valid token will be valid). Allow it with:[1][4][7]
    • ensure the authentication.k8s.io/v1beta1 API group is enabled in the API server[7]
    • start the kubelet with the --authentication-token-webhook and --kubeconfig flags or use the following setting:[1][4][7]
"authentication": {
    "webhook": {
      "cacheTTL": "2m0s",
      "enabled": true
    },

[!NOTE] The kubelet calls the TokenReview API on the configured API server to determine user information from bearer tokens[1]

  • X509 client certificates: Allow to authenticate via X509 client certs[1][5] 
"authentication": {
    "x509": {
      "clientCAFile": "/etc/kubernetes/pki/ca.crt"
    }
}

Kubelet Authorization

Any request that is successfully authenticated (including an anonymous request) is then authorized. The default authorization mode is AlwaysAllow, which allows all requests.[1]

However, the other possible value is webhook (which is what you will be mostly finding out there). This mode will check the permissions of the authenticated user to allow or disallow an action.[1]

[!WARNING] Note that even if the anonymous authentication is enabled the anonymous access might not have any permissions to perform any action.[1]

The authorization via webhook can be configured using the param --authorization-mode=Webhook or via the config file with:[1][4]

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

The kubelet calls the SubjectAccessReview API on the configured API server to determine whether each request is authorized.[1]

The kubelet authorizes API requests using the same request attributes approach as the apiserver:[1][6]

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)
  • The resource talking to the Kubelet api is always nodes and subresource is determined from the incoming request's path:[1]
Kubelet APIresourcesubresource
/stats/*nodesstats
/metrics/*nodesmetrics
/logs/*nodeslog
/spec/*nodesspec
/checkpoint/*nodescheckpoint
all othersnodesproxy

In modern clusters, fine-grained kubelet authorization is enabled by default. Kubernetes v1.36 made this stable: kubelet first checks more specific subresources for paths such as /pods, /runningPods, /healthz, and /configz before falling back to nodes/proxy for backward compatibility.[1]

Kubelet APIpreferred subresourcefallback
/podsnodes/podsnodes/proxy
/runningPods/nodes/podsnodes/proxy
/healthznodes/healthznodes/proxy
/configznodes/configznodes/proxy

Use these narrower subresources for monitoring and diagnostics when possible. Avoid granting broad nodes/proxy for ordinary metrics, stats, health, pod-listing, or config review because nodes/proxy still covers higher-impact kubelet APIs.[1]

[!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.[1][3]

The kubelet Checkpoint API (POST /checkpoint/<namespace>/<pod>/<container>) is another sensitive kubelet surface. Kubernetes v1.30 made container checkpointing beta and enabled by default, but a request still depends on kubelet authorization and runtime support such as CRI-O or containerd with checkpoint/CRIU capability. Successful checkpoints are written below the kubelet root directory, by default /var/lib/kubelet/checkpoints, and can contain process memory with tokens, keys, or application secrets. Restrict nodes/checkpoint, disable the old read-only port, limit direct kubelet network reachability, and monitor or clean checkpoint archives if the feature is intentionally used.[1][2][4][8]

For example, the following request tried to access the pods info of kubelet without permission:

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)
  • We got a Forbidden, so the request passed the Authentication check. If not, we would have got just an Unauthorised message.[1]
  • We can see the username (in this case from the token)[1]
  • Check how the resource was nodes and the subresource proxy (which makes sense with the previous information)[1]

References

[!TIP] Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)
Browse the full HackTricks Training catalog.

Support HackTricks
Sponsored