Summary
The node API authorization is too coarse. We need finer grained authorization of different request types, and maybe resources acted on.

Background

The Kubelet API on the authenticated (10250) port currently uses a very coarse-grained scheme for authorizing requests. For example, reading /healthz and calling /exec/... (i.e. execute arbitrary code) require the same proxy subresource. The SubjectAccessReviews are currently populated with:

• Requisting user (generally from a TokenReviewRequest or client certificate authentication)
• Request verb
• A resource request with:
  • APIGroup: ""
  • APIVersion: "v1"
  • Resource: "nodes"
  • Name: nodeName (the name of the node the request was against)
  • Subresource: one of: proxy, log, metrics, spec, stats

The full mapping of request paths to subresources can be found here:

Fixing this issue is a prerequisite to removing the Kubelet's unauthenticated API: #12968

Although this issue is specific to the Kubelet API, other components that use delegated authorization for a subdivided API will face the same problems.

Desired State

In an ideal world, authorization would happen against the following criteria:

1. Requester has permission to use the node API for this Kubelet.
2. If it's a resource request with a Kubernetes API analog, the requester is authorized to make the request through the regular API
   • E.g. /exec/podNamespace/podID/containerName maps to:

     apiGroup: "core"
     apiVersion: "v1"
     resource: "pods"
     namespace: podNamespace
     name: podName
     subresource: "exec"
     

   • E.g. /pods/ maps to:

     apiGroup: "core"
     apiVersion: "v1"
     resource: "pods"
     verb: "list"
     

3. If it's a non-resource request (e.g. /healthz, /logs), then it's a regular non-resource request authorization check (still requiring [1]), with the requested path being the requested path.
   • optional: We could prefix the request path to indicate a request via the kubelet API, so the authorization can't be used against other non-kubelet targets.

These changes need to maintain backwards compatibility with the current coarse grained permissions.

/sig auth
/sig node
/kind feature
/area kubelet-api
/priority important-longterm

See also:

• Deprecate Kubelet Read-only port #12968
• Implement a kubelet pod api #28138
• Clean up Kubelet RESTful APIs #2098