Kubelet Authentication & Authorization
Kubelet Authentication
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
.
The 3 authentication methods are:
Anonymous (default): Use set setting the param
--anonymous-auth=true
or the config:
Webhook: This will enable the kubectl API bearer tokens as authorization (any valid token will be valid). Allow it with:
ensure the
authentication.k8s.io/v1beta1
API group is enabled in the API serverstart the kubelet with the
--authentication-token-webhook
and--kubeconfig
flags or use the following setting:
The kubelet calls the TokenReview
API on the configured API server to determine user information from bearer tokens
X509 client certificates: Allow to authenticate via X509 client certs
see the apiserver authentication documentation for more details
start the kubelet with the
--client-ca-file
flag, providing a CA bundle to verify client certificates with. Or with the config:
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.
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.
Note that even if the anonymous authentication is enabled the anonymous access might not have any permissions to perform any action.
The authorization via webhook can be configured using the param --authorization-mode=Webhook
or via the config file with:
The kubelet calls the SubjectAccessReview
API on the configured API server to determine whether each request is authorized.
The kubelet authorizes API requests using the same request attributes approach as the apiserver:
Action
The resource talking to the Kubelet api is always nodes and subresource is determined from the incoming request's path:
For example, the following request tried to access the pods info of kubelet without permission:
We got a Forbidden, so the request passed the Authentication check. If not, we would have got just an
Unauthorised
message.We can see the username (in this case from the token)
Check how the resource was nodes and the subresource proxy (which makes sense with the previous information)
References
Last updated