Using Node Authorization [page]deterministic

Node authorization is a special-purpose authorization mode that specifically authorizes API requests made by kubelets.

## Overview

The Node authorizer allows a kubelet to perform API operations. This includes:

Read operations:

* services * endpoints * nodes * pods * secrets, configmaps, persistent volume claims and persistent volumes related to pods bound to the kubelet's node

Kubelets are limited to reading their own Node objects, and only reading pods bound to their node.

Write operations:

* nodes and node status (enable the `NodeRestriction` admission plugin to limit a kubelet to modify its own node) * pods and pod status (enable the `NodeRestriction` admission plugin to limit a kubelet to modify pods bound to itself) * events

Auth-related operations:

* read/write access to the [CertificateSigningRequests API](/docs/reference/access-authn-authz/certificate-signing-requests/) 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 `system:node:<nodeName>`. This group and user name format match the identity created for each kubelet as part of [kubelet TLS bootstrapping](/docs/reference/access-authn-authz/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 [kubelet option](/docs/reference/command-line-tools-reference/kubelet/) `--hostname-override`. However, when using the `--cloud-provider` kubelet option, the specific hostname may be determined by the cloud provider, ignoring the local `hostname` and the `--hostname-override` option. For specifics about how the kubelet determines the hostname, see the [kubelet options reference](/docs/reference/command-line-tools-reference/kubelet/).

To enable the Node authorizer, start the [API server](#gloss:kube-apiserver) with the `--authorization-config` flag set to a file that includes the `Node` authorizer; for example:

```yaml apiVersion: apiserver.config.k8s.io/v1 kind: AuthorizationConfiguration authorizers: ... - type: Node ... ```

Or, start the [API server](#gloss:kube-apiserver) with the `--authorization-mode` flag set to a comma-separated list that includes `Node`; for example: ```shell kube-apiserver --authorization-mode=...,Node --other-options --more-options ```

To limit the API objects kubelets are able to write, enable the [NodeRestriction](/docs/reference/access-authn-authz/admission-controllers#noderestriction) admission plugin by starting the apiserver with `--enable-admission-plugins=...,NodeRestriction,...`

## Service account token audience restriction {#service-account-token-audience-restriction}

When the `ServiceAccountNodeAudienceRestriction` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled and the `NodeRestriction` admission plugin is active, the kubelet can only request service account tokens for audiences that are already referenced by pods running on that node. This prevents a compromised node from obtaining tokens for arbitrary audiences.

The allowed audiences are determined from the pod spec:

• The default API server audience (empty or the API server's configured audience).
• Audiences set in projected service account token volume sources.
• Audiences configured in CSI driver `spec.tokenRequests` for any CSI driver used by the pod, whether through inline CSI volumes, PersistentVolumeClaim-backed volumes, or ephemeral volumes.

This is particularly relevant when using [service account tokens for image credential providers](/docs …(trimmed)