Quiz Report Card: Kubelet API Rights

Date: 2026-03-09 | Qwen 3.6 Plus added: 2026-04-20 | DeepSeek V4 Pro added: 2026-04-24 | DeepSeek V4 Flash added: 2026-04-24 | GPT 5.5 added: 2026-04-25 | Kimi K2.6 added: 2026-04-26 | Qwen3.6-35b-a3b (Local) added: 2026-05-03 | Gemma 4 31B (Local) added: 2026-05-03 | Claude Opus 4.8 added: 2026-05-31 Question: When communicating directly with the Kubelet API on 10250/TCP using a valid client certificate and using webhook authorization, what RBAC rights to the main Kubernetes API are needed to allow a user to get pod lists, metrics and log information from the Kubelet? Additionally what rights are needed to execute a command in a pod running on that host via the Kubelet API?

Reference Answer

Per the Kubernetes documentation on kubelet authorization, when webhook authorization is enabled, the kubelet sends SubjectAccessReview requests to the API server. The kubelet maps its endpoints to node subresources, not standard API resources:

Kubelet API	Resource	Subresource
`/stats/*`	nodes	stats
`/metrics/*`	nodes	metrics
`/logs/*`	nodes	log
`/spec/*`	nodes	spec
`/checkpoint/*`	nodes	checkpoint
all others (including `/pods`, `/exec`, `/run`)	nodes	proxy

Read operations (pod lists, metrics, logs)

Pod lists (/pods): get on nodes/proxy
Metrics (/metrics/*): get on nodes/metrics
Stats (/stats/*): get on nodes/stats
Logs (/logs/*): get on nodes/log

Exec (tricky)

Exec/run: Maps to nodes/proxy — and critically, the verb is get, not create. The documentation explicitly warns: “nodes/proxy with get permission is NOT read-only. It authorizes executing commands in any container running on the node, since some endpoints support Websocket protocols via HTTP GET requests.”

Fine-grained authorization (bonus)

Available from Kubernetes 1.33 (beta), the KubeletFineGrainedAuthz feature gate adds dedicated subresources (e.g., nodes/pods, nodes/healthz, nodes/configz) so that not everything falls through to the overly-broad nodes/proxy.

Scoring Criteria

Node subresource model: Does the response understand that kubelet webhook authorization checks node subresources (nodes/proxy, nodes/metrics, nodes/stats, nodes/log), not standard API resources (pods, pods/log, pods/exec)?
Correct read mappings: Are the specific subresources and verbs correct for each read operation?
Exec mapping: Does it identify nodes/proxy as the resource? Bonus: does it identify get (not create) as the sufficient verb?
Fine-grained authorization: Any mention of K8s 1.33 fine-grained kubelet authorization is a bonus.
Accuracy: Are there fabricated or incorrect claims?

Results Summary

Model	Score	Node Subresource Model	Read Mappings	Exec Resource	Exec Verb (GET)	Fine-Grained Auth	Major Errors
anthropic/claude-opus-4.7	6/10	Correct	Correct	Correct	No (says create)	No	nodes/pods confusion
openai/gpt-5.4	7/10	Correct	Correct	Correct	No (says create)	No	None
google/gemini-3-flash-preview	7/10	Mostly correct	Correct	Correct	No (says create+get)	No	None significant
anthropic/claude-sonnet-4.6	6/10	Correct	Correct	Correct	No (says create)	No	Fabricated checks
deepseek/deepseek-v3.2	3/10	Wrong	Mostly wrong	Wrong	No	No	Wrong model
minimax/minimax-m2.5	2/10	Wrong	Wrong	Wrong	No	No	Wrong model
minimax/minimax-m2.7	8/10	Partial	Yes	pods/exec	create (wrong)	No	None
qwen/qwen3.6-plus	5/10	Wrong	Mostly wrong	Wrong (pods/exec)	No (says create)	No	Wrong model
deepseek/deepseek-v4-pro	4/10	Partial	Mostly wrong	Wrong (create)	No	No	Exec verb wrong
deepseek/deepseek-v4-flash	3/10	Wrong	Mostly wrong	Wrong	No	No	Fabricated resources
moonshotai/kimi-k2.6	7/10	Correct	Correct	Correct	No (says create)	No	Exec verb wrong
openai/gpt-5.5	6/10	Correct	Correct	Correct	No (says create)	No	Exec verb wrong
qwen/qwen3.6-35b-a3b (LOCAL)	4/10	No	No	No	Fundamental misunderstanding of kubelet webhook auth
anthropic/claude-opus-4.8	5/10	Partial	Partial	Wrong (create)	No	No	Invented subresources
google/gemma-4-31b (LOCAL)	5/10	Partial	Partial	Wrong	Calls SA signer a CA; confused authorization model

Detailed Analysis

anthropic/claude-opus-4.7 — 6/10

Strengths:

Correctly explains webhook authorization delegation model
Identifies nodes/metrics, nodes/stats, nodes/log subresources
Good security notes about the power of nodes/proxy

Weaknesses:

Exec verb wrong: States create on nodes/proxy is needed for exec — should be get (WebSocket upgrade uses HTTP GET)
Confused mention of nodes/pods which is not a standard subresource
No mention of fine-grained authorization (Kubernetes 1.33 beta)

Comparison vs Opus 4.6 (7): Regression. Gets the exec verb wrong (create instead of get) and misses fine-grained authorization.

Notable: A rare regression from Opus 4.6. The exec verb error is shared by most models, but the nodes/pods confusion and missing fine-grained auth represent a step back from Opus 4.6’s cleaner response.

openai/gpt-5.4 — 7/10

Strengths:

Correctly identifies that all kubelet authorization maps to node subresources: nodes/proxy, nodes/stats, nodes/log, nodes/spec, nodes/metrics
Clean, accurate RBAC examples with the right resource names and get verb for all read operations
Correctly identifies exec maps to nodes/proxy
Does not fabricate additional kubelet-side checks (no spurious pods/log or pods/exec claims)
Concise and practical

Weaknesses:

Says exec requires create on nodes/proxy — the docs state that get alone is sufficient due to WebSocket connections using HTTP GET
No mention of fine-grained authorization (K8s 1.33)
Includes nodes/spec which wasn’t asked about (minor, not an error)

Notable: The cleanest and most accurate response for the standard kubelet authorization model. The only substantive error is the exec verb.

google/gemini-3-flash-preview — 7/10

Strengths:

Correctly maps most operations to node subresources
Excellent insight: Explicitly notes that pods/exec is for the API server path, not for direct kubelet access — “It is a common mistake to try and grant permissions on pods/exec.” This is the best single observation across all responses.
Correctly identifies exec maps to nodes/proxy
Mentions system:node-admin built-in role as a practical shortcut
Good explanation of authentication vs authorization flow

Weaknesses:

Lists exec verb as create (and get) — should be get only
Mentions nodes/pods as an alternative for pod lists without clarifying this only exists with fine-grained authorization (K8s 1.33+)
RBAC example uses nodes/pods which doesn’t exist in standard kubelet authorization
No mention of fine-grained authorization despite referencing nodes/pods

Notable positive: The explicit callout that pods/exec is wrong for direct kubelet access demonstrates genuine understanding of the two different authorization paths (API server vs kubelet direct). This is the most insightful observation across all five responses.

anthropic/claude-sonnet-4.6 — 6/10

Strengths:

Correctly identifies the node subresource model: nodes/proxy, nodes/metrics, nodes/stats, nodes/log
Provides the accurate endpoint-to-subresource mapping table
Correctly identifies exec maps to nodes/proxy
Good security notes about nodes/proxy being highly privileged

Weaknesses:

Fabricates additional kubelet-side checks: Claims the kubelet performs a second authorization check on pods/log for container logs and pods/exec for exec operations. This is incorrect — the kubelet only checks node-level resources. It does not perform namespace-scoped pod-level authorization.
Lists exec verbs as get, post, create — only get is needed
The fabricated dual-check model (node resource + pod resource) would mislead administrators into creating unnecessary RBAC rules and misunderstanding the kubelet’s security model

Notable negative: The fabricated pods/log and pods/exec checks are significant because they misrepresent the kubelet’s authorization model. An administrator reading this might incorrectly believe the kubelet provides namespace-scoped pod-level authorization, when in reality it only checks broad node-level permissions. This is exactly the security gap that fine-grained authorization (K8s 1.33) was designed to address.

deepseek/deepseek-v3.2 — 3/10

Strengths:

Correctly identifies nodes/stats for the stats endpoint
Understands the webhook/SubjectAccessReview mechanism conceptually
Correctly notes that pod log/exec authorization is namespaced (when going through the API server, though not via kubelet)
Some useful practical caveats about real-world usage

Weaknesses:

Fundamentally wrong authorization model: Maps /pods to pods resource with list verb instead of nodes/proxy with get
Maps /containerLogs to pods/log instead of nodes/proxy (or nodes/log for /logs/*)
Maps /exec to pods/exec with create instead of nodes/proxy with get
Confuses kubelet webhook authorization checks with standard Kubernetes API RBAC
No mention of fine-grained authorization

Notable negative: The response conflates two different authorization paths — going through the API server (where pods/log, pods/exec are correct) vs going directly to the kubelet (where only node subresources are checked). This is a fundamental misunderstanding of how kubelet webhook authorization works.

minimax/minimax-m2.5 — 2/10

Strengths:

Correctly describes the SubjectAccessReview mechanism at a conceptual level
Authentication details (CN, O fields from certificates) are accurate
Mentions webhook configuration requirement

Weaknesses:

Completely wrong authorization model: Maps every operation to standard API resources:
- Pod lists → pods with list, watch — should be nodes/proxy with get
- Metrics → nodes with get and metrics.k8s.io/pods — should be nodes/metrics with get
- Logs → pods/log with get — should be nodes/log with get
- Exec → pods/exec with create — should be nodes/proxy with get
Does not understand that the kubelet maps endpoints to node subresources at all
The metrics.k8s.io API group reference is for the metrics-server, not kubelet authorization
No mention of fine-grained authorization

Notable negative: This response would be correct if the question were about accessing pods through the Kubernetes API server. But the question specifically asks about communicating directly with the kubelet API, where an entirely different authorization model applies. The response demonstrates no understanding of kubelet-specific authorization.

minimax/minimax-m2.7 — 8/10

Strengths:

Excellent structured table mapping kubelet API operations to RBAC resources and verbs
Correctly identifies all standard verbs and the node subresource model
Concrete YAML examples for ClusterRole and ClusterRoleBinding configurations
Good checklist summary of required permissions

Weaknesses:

Missed the websocket/GET on nodes/proxy trick for exec — lists create as the verb instead of get
No mention of fine-grained authorization (KubeletFineGrainedAuthz feature gate, K8s 1.33+)

Notable: The best structured response of any model for this question, with clear tabular mappings that would be immediately useful for an administrator. Represents a dramatic improvement over MiniMax M2.5 (which scored 2/10 with a completely wrong authorization model). Highest score on kubelet API across all models, tied with GPT 5.4 and Gemini 3 Flash but earning the edge through superior presentation.

qwen/qwen3.6-plus — 5/10

Strengths:

Correctly explains webhook authorization delegation model (kubelet sends SubjectAccessReview)
Mentions nodes/metrics and nodes/stats for metrics endpoints
Good structural explanation of namespace scoping vs cluster scoping
Correct note about user identity mapping from certificate CN/O fields

Weaknesses:

Fundamentally wrong authorization model for most endpoints: Maps pod lists to standard pods resource with list/get verbs, pod logs to pods/log, and exec to pods/exec — these are API server RBAC resources, not kubelet webhook authorization checks
Exec verb wrong: States create on pods/exec is needed — should be get on nodes/proxy
The version caveat claiming “Older versions used nodes/proxy” is backwards — nodes/proxy is the current and correct resource for kubelet authorization
No mention of fine-grained authorization (K8s 1.33)

Notable: The response conflates API server RBAC (where pods, pods/log, pods/exec are correct) with kubelet webhook authorization (where only node subresources are checked). Correctly mentions nodes/metrics and nodes/stats for some endpoints but inconsistently applies the wrong model for pods, logs, and exec.

deepseek/deepseek-v4-pro — 4/10

Strengths:

Correctly identifies webhook authorization delegation model

Weaknesses:

Critical error on exec verb: Claims exec requires CREATE on nodes/proxy — the correct answer is GET due to WebSocket implementation
No mention of fine-grained authorization (KubeletFineGrainedAuthz feature gate, K8s 1.33+)
Partially mixes API server and kubelet authorization models

Notable: A regression from DeepSeek V3.2’s already-low score (3/10) to 4/10 — marginal improvement. The exec verb error is shared by most models, but the lack of fine-grained authorization mention and partial model confusion limit the score.

deepseek/deepseek-v4-flash — 3/10

Strengths:

Understands the concept of webhook authorization delegation

Weaknesses:

Fabricates incorrect resource strings rather than using the correct node subresource model
Does not correctly map kubelet endpoints to nodes/proxy, nodes/metrics, nodes/stats, nodes/log
Misses the GET on nodes/proxy trick for exec operations
No mention of fine-grained authorization (K8s 1.33)

Notable: Matches DeepSeek V3.2’s score of 3/10 — no improvement on this question between generations. Both DeepSeek non-Pro models fundamentally confuse the kubelet webhook authorization model with standard API server RBAC. V4 Pro scored marginally better (4/10) but the entire DeepSeek family struggles on this question.

openai/gpt-5.5 — 6/10

Strengths:

Correctly identifies the node subresource model from the outset: “the Kubelet asks the main Kubernetes API server to authorize the client identity using RBAC against Node subresources”
All four node subresources correctly listed: nodes/proxy, nodes/metrics, nodes/stats, nodes/log with correct get verb for read operations
Clean YAML examples for a kubelet-read ClusterRole — immediately usable
Correctly maps /pods to nodes/proxy and /exec to nodes/proxy
Good practical note about limiting to specific nodes using resourceNames

Weaknesses:

Exec verb wrong: States create on nodes/proxy is needed for exec — the correct answer is get (WebSocket upgrade uses HTTP GET). Acknowledges that “GET-based WebSocket upgrade” may also need get, but treats create as the primary verb
No mention of fine-grained authorization (KubeletFineGrainedAuthz feature gate, K8s 1.33+ beta)

Notable: Gets the node subresource model completely right, matching GPT 5.4 and the Anthropic models on the fundamental authorization model. The exec verb error is shared by every model tested — no model has yet correctly identified get as sufficient for exec. The response is cleaner than GPT 5.4’s but scores lower due to less insightful analysis.

moonshotai/kimi-k2.6 — 7/10

Strengths:

Correctly identifies the node subresource model for kubelet webhook authorization
Correct read mappings for nodes/proxy, nodes/metrics, nodes/stats, nodes/log
Correctly maps exec to nodes/proxy

Weaknesses:

Exec verb wrong: States create on nodes/proxy is needed for exec — should be get (WebSocket upgrade uses HTTP GET)
No mention of fine-grained authorization (KubeletFineGrainedAuthz feature gate, K8s 1.33+)

Notable: Matches GPT 5.4 and Gemini 3 Flash at 7/10 with a clean understanding of the node subresource model. Like every other model tested, gets the exec verb wrong.

qwen/qwen3.6-35b-a3b (LOCAL) — 4/10

Strengths:

Understands the concept of webhook authorization delegation at a high level

Weaknesses:

Opens by saying “no main API RBAC required” — fundamentally wrong. Kubelet webhook authorization delegates to the API server via SubjectAccessReview, which checks RBAC on node subresources
Doesn’t know kubelet webhook mode delegates to SubjectAccessReview on nodes subresources
Never mentions nodes/log, nodes/metrics, nodes/proxy — the core of kubelet webhook authorization
Misses fine-grained kubelet authorization entirely
No mention of the exec verb trick (GET on nodes/proxy)

Notable: The weakest understanding of the kubelet webhook authorization model among recent models. The fundamental error of claiming “no main API RBAC required” shows a gap in understanding how kubelet webhook auth works — it specifically requires RBAC on the main API server. Matches DeepSeek V4 Pro at 4/10.

google/gemma-4-31b (LOCAL) — 5/10

Strengths:

Understands the webhook authorization delegation model at a conceptual level
Identifies some node subresources for read operations
Mentions nodes/metrics and nodes/stats for metric endpoints

Weaknesses:

Partially conflates API server RBAC with kubelet webhook authorization — maps some operations to standard pod resources rather than node subresources exclusively
Exec verb wrong — states create on nodes/proxy is needed for exec (should be get due to WebSocket implementation)
Incomplete mapping of all kubelet endpoints to their correct node subresources
No mention of fine-grained authorization (KubeletFineGrainedAuthz feature gate, K8s 1.33+)

Notable: A slight improvement over Qwen-35b (4/10) but still below the cluster of GPT 5.4, Gemini 3 Flash, and Kimi K2.6 at 7/10. The model has partial knowledge of the node subresource model but doesn’t apply it consistently. The exec verb error is shared by nearly every model tested.

anthropic/claude-opus-4.8 — 5/10

Strengths:

Understands the webhook authorization delegation model at a conceptual level
Identifies some node subresources for read operations

Weaknesses:

Exec verb wrong: Claims create on nodes/proxy is needed for exec — the correct answer is get (WebSocket upgrade uses HTTP GET)
Invented subresources: Claims nodes/stats and nodes/metrics exist as separate subresources when the kubelet actually maps /stats/* and /metrics/* to those, but also fabricates other subresource mappings
No mention of fine-grained authorization (KubeletFineGrainedAuthz feature gate, K8s 1.33+)
Partially conflates API server RBAC with kubelet webhook authorization

Comparison vs Opus 4.7 (6): Regression. The invented subresources and continued exec verb error bring the score below Opus 4.7’s cleaner response.

Notable: A regression from Opus 4.7 (6/10). The kubelet webhook authorization model continues to be a weak spot for Anthropic models. The exec verb error is shared by every model tested, but the invented subresources are a new issue for the Anthropic family.

Key Findings

The node subresource model is the key differentiator: Several models (Claude, GPT 5.4, Gemini 3 Flash) correctly understood that kubelet webhook authorization checks node subresources. Qwen 3.6 Plus partially mixed API server and kubelet models. MiniMax M2.5 and DeepSeek V3.2 mapped everything to standard API resources, which is fundamentally wrong for direct kubelet access.
No model got the exec verb right: The documentation explicitly warns that get on nodes/proxy is not read-only due to WebSocket protocols. All five models either said create or included create alongside get. This confirms the scoring notes’ prediction that models are unlikely to get this right.
No model mentioned fine-grained authorization: The KubeletFineGrainedAuthz feature gate (K8s 1.33 beta) was not mentioned by any model, missing the bonus scoring opportunity.
Fabricated checks are worse than missing information: Claude’s response fabricated additional kubelet-side checks on pods/log and pods/exec that don’t exist. While it got the node-level mappings right, the fabricated dual-check model actively misleads about the kubelet’s security properties.
Gemini 3 Flash produced the best single insight: Explicitly warning that pods/exec is a common mistake for direct kubelet access demonstrates deeper understanding than any other response, even though the model still got the exec verb wrong.
API server vs kubelet confusion: Both MiniMax M2.5 and DeepSeek V3.2 answered as if the question were about API server RBAC, not kubelet webhook authorization. This suggests these models lack specific training data about kubelet internals.