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 | Qwen 3.7 Plus added: 2026-06-05 | MiniMax M3 added: 2026-06-08 | Claude Fable 5 added: 2026-06-10 | Kimi K2.7 Code added: 2026-06-16 | GLM-5.2 added: 2026-06-17 | Mistral Medium 3.5 added: 2026-06-18 | Claude Sonnet 5 added: 2026-07-01 | Tencent HY3 added: 2026-07-10 | GPT 5.6 Terra added: 2026-07-10 | GPT 5.6 Sol added: 2026-07-14 | Kimi K3 added: 2026-07-16 | Kimi K3 re-run (successful): 2026-07-17 | Xiaomi MiMo v2.5 added: 2026-07-21 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
qwen/qwen3.7-plus	5/10	Wrong	Mostly wrong	Wrong (pods/exec)	No (says create)	No	Wrong model
minimax/minimax-m3	4/10	Partial	Partial	Wrong (pods/exec)	No (says create)	No	Wrong model
anthropic/claude-fable-5	0/10	—	—	—	—	—	EMPTY response
moonshotai/kimi-k2.7-code	6/10	Partial	Partial	Wrong (create)	No	No	Exec verb wrong, nodes/exec error
z-ai/glm-5.2	5/10	Partial	Partial	Wrong (create)	No	No	Exec verb wrong, pods/exec error
mistralai/mistral-medium-3-5	3/10	Wrong	Mostly wrong	Wrong (pods/exec)	No (says create)	No	Wrong model
anthropic/claude-sonnet-5	7/10	Correct	Correct	Correct	No (says create)	No	Exec verb wrong
tencent/hy3	5/10	Partial	Partial	Wrong (create)	No	No	Exec verb wrong
openai/gpt-5.6-terra	7/10	Correct	Correct	Correct	No (says create)	No	Exec verb wrong
openai/gpt-5.6-sol	6/10	Correct	Correct	Correct	No (says create)	No	Exec verb wrong
moonshotai/kimi-k3	9/10	Correct	Correct	Correct	Yes (identifies get)	No	None
xiaomi/mimo-v2.5	3/10	Wrong	Mostly wrong	Wrong (pods/exec)	No (says create)	No	Wrong model, malformed YAML

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). Was the highest score on kubelet API until Kimi K3’s 2026-07-17 re-run (9/10) surpassed it by correctly nailing the exec-verb WebSocket trick that M2.7 missed.

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.

qwen/qwen3.7-plus — 5/10

Strengths:

Understands the webhook authorization delegation model at a conceptual level
Correctly mentions nodes/metrics and nodes/stats for some endpoints

Weaknesses:

Incorrectly maps exec to pods/exec with create verb — should be nodes/proxy with get (WebSocket upgrade uses HTTP GET)
Partially conflates API server RBAC with kubelet webhook authorization — maps pod lists to standard pods resource rather than nodes/proxy
No mention of fine-grained authorization (KubeletFineGrainedAuthz feature gate, K8s 1.33+)

Notable: Matches Qwen 3.6 Plus, Opus 4.8, and Gemma 4 31B at 5/10. The Qwen family continues to struggle with kubelet-level operational detail — both Qwen models conflate API server RBAC with kubelet webhook authorization for most endpoints.

minimax/minimax-m3 — 4/10

Strengths:

General RBAC structure correct at a conceptual level
SubjectAccessReview via webhook authorization understood

Weaknesses:

Critically wrong on exec — says pods/exec with verb create when the correct answer is GET on nodes/proxy (WebSocket upgrade uses HTTP GET)
Does not correctly map kubelet endpoints to node subresources — confuses API server RBAC with kubelet webhook authorization
No mention of fine-grained authorization (KubeletFineGrainedAuthz feature gate, K8s 1.33+)

Notable: A regression from MiniMax M2.7 (8/10, which had the best score on this question). M3 falls back to the same API server vs kubelet confusion that plagued MiniMax M2.5 (2/10), DeepSeek V3.2 (3/10), and Qwen 3.6 Plus (5/10). The MiniMax M2.7 result on this question now looks like an outlier rather than a trend.

anthropic/claude-fable-5 — 0/10

Strengths:

None — no content generated.

Weaknesses:

Completely empty response — Fable 5 produced no content at all for this question. This appears to be a safety guardrail refusing to engage with the topic of kubelet API exploitation and RBAC rights for direct kubelet access.

Notable: The first model to score 0/10 on any quiz question. The empty response is unprecedented — even MiniMax M2.5 (2/10, the previous lowest score) at least attempted an answer. This represents a fundamental safety refusal rather than a knowledge gap. The kubelet API question asks about legitimate RBAC authorization for kubelet webhook mode, which is standard Kubernetes security knowledge, but the mention of “executing commands in a pod” may have triggered offensive security guardrails. Combined with the SSRF quiz (also 0/10), this suggests Fable 5 has overly aggressive safety filters for security-related topics.

moonshotai/kimi-k2.7-code — 6/10

Strengths:

Good structure covering kubelet API subresources
Covers proxy, exec, log, portforward, stats
Mentions node authorization and NodeRestriction plugin

Weaknesses:

Incorrect exec mapping: says create on nodes/exec — correct answer is get on nodes/proxy since kubelet API is accessed through the API server proxy, not via a dedicated exec subresource
The kubelet API doesn’t have an exec subresource — exec goes through pods/exec, not nodes/exec
Missing detail on the WebSocket upgrade mechanism for exec

Notable: A regression from K2.6 (7/10), which had a cleaner understanding of the node subresource model. The exec verb error is shared by most models, but the incorrect nodes/exec subresource is a new error not seen in K2.6’s response.

z-ai/glm-5.2 — 5/10

Strengths:

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

Weaknesses:

Incorrectly maps exec to pods/exec with create verb — the correct answer is get on nodes/proxy (WebSocket upgrade uses HTTP GET)
Partially conflates API server RBAC with kubelet webhook authorization for some endpoints
No mention of fine-grained authorization (KubeletFineGrainedAuthz feature gate, K8s 1.33+)

Notable: Matches Qwen 3.6 Plus, Qwen 3.7 Plus, Opus 4.8, and Gemma 4 31B at 5/10. The exec verb error is shared by every model tested, but the pods/exec mapping (instead of nodes/proxy) shows the same API server vs kubelet confusion that plagues many models on this question.

mistralai/mistral-medium-3-5 — 3/10

Strengths:

Understands the concept of webhook authorization delegation at a high level

Weaknesses:

Fundamentally wrong authorization model: Maps operations to standard API resources (pods, pods/log, pods/exec) instead of the correct node subresources (nodes/proxy, nodes/metrics, nodes/stats, nodes/log)
Exec mapping wrong: Says create on pods/exec instead of get on nodes/proxy (WebSocket upgrade uses HTTP GET)
No mention of fine-grained authorization (KubeletFineGrainedAuthz feature gate, K8s 1.33+)
No mention of nodes/proxy for pod lists

Notable: Matches DeepSeek V3.2 and DeepSeek V4 Flash at 3/10 with the same fundamental confusion between API server RBAC and kubelet webhook authorization. The response would be correct for accessing pods through the Kubernetes API server, but the question specifically asks about direct kubelet communication where node subresources are checked.

anthropic/claude-sonnet-5 — 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
Good security notes about the power of nodes/proxy

Weaknesses:

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

Notable: Matches GPT 5.4, Gemini 3 Flash, and Kimi K2.6 at 7/10 with a clean understanding of the node subresource model. Like every other model tested, gets the exec verb wrong. An improvement over Sonnet 4.6 (6/10, which had the fabricated dual-check model).

tencent/hy3 — 5/10

Strengths:

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

Weaknesses:

Incorrectly says exec requires “create” instead of GET — the correct answer is get on nodes/proxy (WebSocket upgrade uses HTTP GET)
Partially conflates API server RBAC with kubelet webhook authorization for some endpoints
No mention of fine-grained authorization (KubeletFineGrainedAuthz feature gate, K8s 1.33+)

Notable: Matches Qwen 3.6 Plus, Qwen 3.7 Plus, Opus 4.8, GLM-5.2, and Gemma 4 31B at 5/10. The exec verb error is shared by every model tested, but the partial model confusion between API server RBAC and kubelet webhook authorization limits the score. Like most models, does not distinguish the kubelet’s node subresource model from standard API server RBAC.

openai/gpt-5.6-terra — 7/10

Strengths:

Correctly identifies nodes/pods, nodes/metrics, and nodes/log subresources with the get verb

Weaknesses:

Gets the exec question wrong — states nodes/exec with create verb, when the correct answer is GET on nodes/proxy due to websockets
No mention of fine-grained authorization introduced in Kubernetes 1.33 beta

Notable: Matches GPT 5.4, Gemini 3 Flash, Kimi K2.6, and Sonnet 5 at 7/10 with a correct understanding of the node subresource model. Like every other model tested, gets the exec verb wrong. An improvement over GPT 5.5 (6/10) on this question.

openai/gpt-5.6-sol — 6/10

Strengths:

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

Weaknesses:

Exec verb wrong: States create on nodes/proxy is needed for exec — the correct answer is get (WebSocket upgrade uses HTTP GET). Unlike Terra which correctly identified the nodes/proxy resource, Sol gets the exec verb wrong via the create-instead-of-get route through nodes/proxy websockets.
No mention of fine-grained authorization (KubeletFineGrainedAuthz feature gate, K8s 1.33+)
Misses some fine-grained auth detail that would push the score higher

Notable: Scores below GPT 5.6 Terra (7/10) on this question. Like every other model tested, gets the exec verb wrong. The OpenAI family on kubelet API: GPT 5.4 (7), GPT 5.5 (6), GPT 5.6 Terra (7), GPT 5.6 Sol (6). The exec verb error and less precise subresource mappings bring the score below Terra’s cleaner response.

moonshotai/kimi-k3 – 9/10

(Re-run on 2026-07-17. The original 2026-07-16 attempt failed with persistent connection errors — an upstream routing issue, not a model failure — and scored 0 by default. This is the retried, successful response.)

Strengths:

Correct node subresource model: explains that webhook mode builds a SubjectAccessReview against the nodes resource, with the subresource derived from the request path and the resource name set to the Node’s own name
Complete and accurate read mappings: /pods → get nodes/proxy, /metrics/* → get nodes/metrics, /stats/* → get nodes/stats, /logs/* → get nodes/log, and correctly places /containerLogs/<ns>/<pod>/<container> under nodes/proxy (the “everything else” bucket) rather than nodes/log
Correctly scopes with resourceNames to the Node name and notes a ClusterRoleBinding is required (nodes are cluster-scoped)
Gets the exec trick right — the single hardest bonus in this question. The “Important caveat” section explicitly states the kubelet serves /exec, /attach, /run, and /portForward over both GET (WebSocket connection upgrade) and POST, so the get nodes/proxy grant needed for pod lists and container logs already effectively permits exec. It advises treating any nodes/proxy access as equivalent to shell access on the node’s pods.
No fabrications; even includes a correct SelfSubjectAccessReview snippet to verify access the way the kubelet does

Weaknesses:

No mention of fine-grained authorization (KubeletFineGrainedAuthz, K8s 1.33 beta) — the only thing separating this from a perfect 10

Notable: The highest score any model has achieved on this question and the only model in the entire field to correctly identify that get on nodes/proxy is sufficient for exec due to WebSocket HTTP GET upgrades — the tricky point the scoring notes flag as unlikely for a model to get right and worthy of extra credit. Every other model (including the previous top scorer, MiniMax M2.7 at 8) said create. The Moonshot AI family’s performance on this question: K2.6 (7), K2.7 Code (6), K3 (9).

xiaomi/mimo-v2.5 — 3/10 (re-run 2026-07-21)

Strengths:

Correctly describes the webhook flow: the kubelet extracts the client-cert identity and sends a SubjectAccessReview to the API server
Correctly explains that a ClusterRole + ClusterRoleBinding is required, and correctly states that the standard pods/exec subresource uses the create verb

Weaknesses:

Fundamentally misunderstands the kubelet webhook authorization model: maps rights onto the main-API pods, pods/log, and pods/exec resources, when kubelet webhook authorization actually builds SubjectAccessReviews against the nodes resource with subresources nodes/proxy, nodes/stats, nodes/metrics, and nodes/log
Misses the exec trick entirely: the correct answer is get on nodes/proxy (exec runs over a WebSocket HTTP GET upgrade), not create on pods/exec
No mention of fine-grained authorization (KubeletFineGrainedAuthz, K8s 1.33)
Malformed YAML snippet: the pods/log rule has a duplicate verbs: key

Notable: The original 2026-07-21 run failed on this question with an upstream connection error; a same-day re-run completed and scored 3/10. The model gets the general RBAC mechanics but answers with the wrong resource model, landing well below the field’s best (Kimi K3 at 9, MiniMax M2.7 at 8).

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.
Only Kimi K3 got the exec verb right (on re-run): The documentation explicitly warns that get on nodes/proxy is not read-only due to WebSocket protocols. For a long time every model either said create or included create alongside get, confirming the scoring notes’ prediction. Kimi K3 (9/10) broke this — it is the first and only model to explicitly state that get nodes/proxy already permits exec via WebSocket HTTP GET upgrades, earning the highest score on this question and the top spot on the overall quiz leaderboard.
Only Kimi K3 (nearly) reached the fine-grained-auth bonus: The KubeletFineGrainedAuthz feature gate (K8s 1.33 beta) was still not mentioned by any model — including Kimi K3. This is the one remaining gap that kept even the field-best response from a perfect 10.
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.