Using Node Authorization
Node authorization is a special-purpose authorization mode that specifically authorizes API requests made by kubelets.
The Node authorizer allows a kubelet to perform API operations. This includes:
- secrets, configmaps, persistent volume claims and persistent volumes related to pods bound to the kubelet's node
- nodes and node status (enable the
NodeRestrictionadmission plugin to limit a kubelet to modify its own node)
- pods and pod status (enable the
NodeRestrictionadmission plugin to limit a kubelet to modify pods bound to itself)
- read/write access to the CertificateSigningRequests API for TLS bootstrapping
- the ability to create TokenReviews and SubjectAccessReviews for delegated authentication/authorization checks
In future releases, the node authorizer may add or remove permissions to ensure kubelets have the minimal set of permissions required to operate correctly.
In order to be authorized by the Node authorizer, kubelets must use a credential
that identifies them as being in the
system:nodes group, with a username of
This group and user name format match the identity created for each kubelet as part of
kubelet TLS bootstrapping.
The value of
<nodeName> must match precisely the name of the node as
registered by the kubelet. By default, this is the host name as provided by
hostname, or overridden via the
--hostname-override. However, when using the
option, the specific hostname may be determined by the cloud provider, ignoring
hostname and the
For specifics about how the kubelet determines the hostname, see the
kubelet options reference.
To enable the Node authorizer, start the apiserver with
To limit the API objects kubelets are able to write, enable the
admission plugin by starting the apiserver with
Kubelets outside the
Kubelets outside the
system:nodes group would not be authorized by the
authorization mode, and would need to continue to be authorized via whatever
mechanism currently authorizes them.
The node admission plugin would not restrict requests from these kubelets.
Kubelets with undifferentiated usernames
In some deployments, kubelets have credentials that place them in the
but do not identify the particular node they are associated with,
because they do not have a username in the
These kubelets would not be authorized by the
Node authorization mode,
and would need to continue to be authorized via whatever mechanism currently authorizes them.
NodeRestriction admission plugin would ignore requests from these kubelets,
since the default node identifier implementation would not consider that a node identity.