update the kubelet authorizer to allow system:masters access without a SAR

[deads2k]

system:masters group is defined in kube-apiserver to always have access. Because of this, we know that every delegated authorization check for this group on every kubernetes cluster, will always return allowed. We can add the system:masters authorizer first.

/kind cleanup
/priority important-soon
@kubernetes/sig-auth-bugs @kubernetes/sig-node-pr-reviews

NONE

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: deads2k
To complete the pull request process, please assign dchen1107 after the PR has been reviewed.
You can assign the PR to them by writing /assign @dchen1107 in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• cmd/kubelet/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[enj]

Can we migrate the Kubelet to NewDelegatingAuthorizationOptions (just the struct, not the flag set)? The Kubelet is a bit of a unicorn in regards to its authn and authz stack. It would be nice to normalize it to what the API server uses.

[enj]

/triage accepted

[yangjunmyfm192085]

/test pull-kubernetes-unit

[deads2k]

Can we migrate the Kubelet to NewDelegatingAuthorizationOptions (just the struct, not the flag set)? The Kubelet is a bit of a unicorn in regards to its authn and authz stack. It would be nice to normalize it to what the API server uses.

I looked at that first, but doing so requires disconnecting the way they build the client. It's a significantly more invasive change.

[enj]

I looked at that first, but doing so requires disconnecting the way they build the client. It's a significantly more invasive change.

Right, but it is also the correct change. If the Kubelet was already using the API server code, #98325 would have already fixed its defaulting to include system:masters.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

[k8s-triage-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

[k8s-ci-robot]

@k8s-triage-robot: Closed this PR.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.