The kubelet docs describe two defaults worth checking. Requests to the kubelet's HTTPS endpoint that other methods do not reject are treated as anonymous, and the default authorization mode is AlwaysAllow. Disable anonymous authentication and use Webhook authorization, then confirm the settings on your nodes.
The two defaults
On anonymous requests, the docs say that by default, requests to the kubelet's HTTPS endpoint that are not rejected by other configured authentication methods are treated as anonymous, with the username system:anonymous and the group system:unauthenticated.
On authorization, they say any successfully authenticated request, including an anonymous one, is then authorized, and that the default authorization mode is AlwaysAllow, which allows all requests.
Put together: unless you or your distribution changed things, a request that reaches the kubelet may be allowed. Many managed and installer based clusters change these settings for you, so the real answer is cluster specific. Check yours rather than assuming.
The hardening settings
To disable anonymous requests, start the kubelet with anonymous auth set to false, which makes it respond 401 Unauthorized to unauthenticated requests. To delegate authorization to the API server, set the authorization mode to Webhook, supply a kubeconfig, and make sure the authorization.k8s.io/v1 API group is enabled. The kubelet then calls SubjectAccessReview for each request.
kubelet --anonymous-auth=false \
--authorization-mode=Webhook \
--kubeconfig=/path/to/kubeconfig \
--client-ca-file=/path/to/ca.crt
Most installations set these through a kubelet configuration file rather than flags. The docs page did not list the file field names, so confirm them in the kubelet configuration reference for your version.
Why the kubelet API matters
The docs say permission on nodes/proxy grants access to all other kubelet APIs, including ones that can execute commands in any container on the node. Authentication methods (anonymous, client certificates and bearer tokens) each let a caller reach the kubelet API if enabled, which is why authorization needs to be strict. See our post on why get on nodes/proxy is not read-only.
How to check a node
- Find the kubelet configuration or startup flags on a node, or in your managed service's node settings.
- Check anonymous authentication and the authorization mode.
- Confirm client certificate authentication points at the right CA.
- Restrict network access to the kubelet port to the control plane and tools that need it.
Step four is general network hygiene and not something the fetched page covers.
Safeguard and nodes
Safeguard does not inspect kubelet settings. Use your cluster benchmark or managed service tooling for that. Safeguard's role is the repository and pipeline side, with policies, gates and SBOM and dependency scanning.
When settings differ between node pools
Large clusters often have several node pools created at different times. Check each pool, not only one node. A hardened pool next to an older one with defaults is a common finding. Record what you find in a simple table of pool, anonymous setting and authorization mode, and revisit it after any node image change.
Quick check
Is AlwaysAllow the default kubelet authorization mode?
The Kubernetes docs say so. Many distributions override it, so check your own nodes.
Sources
Last reviewed: 19 October 2026.
