Author: Jordan Liggitt (email@example.com)
The kubelet exposes endpoints which give access to data of varying sensitivity, and allow performing operations of varying power on the node and within containers. There is no built-in way to limit or subdivide access to those endpoints, so deployers must secure the kubelet API using external, ad-hoc methods.
This document proposes a method for authenticating and authorizing access to the kubelet API, using interfaces and methods that complement the existing authentication and authorization used by the API server.
This proposal assumes the existence of:
It also assumes each node is additionally provisioned with the following information:
Enable starting the kubelet with one or more of the following authentication methods:
For backwards compatibility, the default is to enable anonymous authentication.
Add a new
--client-ca-file=[file] option to the kubelet.
When started with this option, the kubelet authenticates incoming requests using x509
client certificates, validated against the root certificates in the provided bundle.
The kubelet will reuse the x509 authenticator already used by the API server.
The master API server can already be started with
--kubelet-client-key options in order to make authenticated requests to the kubelet.
Add a new
--authentication-token-webhook=[true|false] option to the kubelet.
When true, the kubelet authenticates incoming requests with bearer tokens by making
TokenReview API calls to the API server.
The kubelet will reuse the webhook authenticator already used by the API server, configured to call the API server using the connection information already provided to the kubelet.
To improve performance of repeated requests with the same bearer token, the
--authentication-token-webhook-cache-ttl option supported by the API server
would be supported.
Add a new
--anonymous-auth=[true|false] option to the kubelet.
When true, requests to the secure port that are not rejected by other configured
authentication methods are treated as anonymous requests, and given a username
system:anonymous and a group of
Add a new
--authorization-mode option to the kubelet, specifying one of the following modes:
AlwaysAllow (current default)
For backwards compatibility, the authorization mode defaults to
Webhook mode converts the request to authorization attributes, and makes a
API call to check if the authenticated subject is allowed to make a request with those attributes.
This enables authorization policy to be centrally managed by the authorizer configured for the API server.
The kubelet will reuse the webhook authorizer already used by the API server, configured to call the API server using the connection information already provided to the kubelet.
To improve performance of repeated requests with the same authenticated subject and request attributes, the same webhook authorizer caching options supported by the API server would be supported:
This mode allows any authenticated request.