allow delegated authorization to have privileged groups

[deads2k]

In kube, system:masters is a special group that has full API powers. We use this group to be able to have kube-apiservers loopback with full power and to allow management of RBAC using a client cert with that group.

Since DelegatedAuthorization is intended to be consistent with kube recommendations, this updates the default value to include an authorizer that lists system:masters as having full rights. This means that system:masters users will not have to have a remote authz call which improves performance and makes debugging very broken conditions possible.

@smarterclayton
@kubernetes/sig-api-machinery-pr-reviews @kubernetes/sig-auth-pr-reviews

delegated authorization can now allow unrestricted access for `system:masters` like the main kube-apiserver

[liggitt]

I think I'm on board with defaulting to a value that allows coasting, but I expected a flag wired to this to surface it and allow control

[deads2k]

I think I'm on board with defaulting to a value that allows coasting, but I expected a flag wired to this to surface it and allow control

This seems like a setting that individual binaries can choose to control how they like. I think a very small minority (if any) would want to allow an admin to control it and those binaries could choose to wire the value to whatever flag they like.

[mikedanese]

I'm worried that:

• This is a leak of an RBAC specific detail into the scope of general authorization
• Bypasses short-circuit deny authorizers

[liggitt]

• This is a leak of an RBAC specific detail into the scope of general authorization
• Bypasses short-circuit deny authorizers

the same superuser exists in the kube-apiserver as the pinned first authorizer in the chain, independent of RBAC and prior to any configured authorizers

[mikedanese]

Ahh... loopback stuff... I have similar concerns with that flow. While we couldn't make the same guarantees around preventing misconfiguration, I would strongly prefer if the loopback authorizer was appended to the authorizer chain rather than prepended. The usecase was outlined here #51862

[mikedanese]

I'm primarily concerned with introducing well known user/group strings that are capable of unilateral bypassing authorization when operators generally have little control over the users and groups of credentials (namely those provisioned by the certificates API).

I would strongly prefer if the loopback authorizer was appended to the authorizer chain rather than prepended.

Alternatively, we could enforce that the loopback authorizer could only authorize request from loopback addresses. Would this approach address the issues raised here? e.g. administrator needs port forward AND a system:master credential to bypass authorization of apiservers running in the cluster and apiservers running outside the cluster can be protected?

[deads2k]

I can make it optional, but I think that prepending is the correct default choice. This is already what the kube-apiserver does, so this is purely an optimization on asking. Again, a user of this API can wire or disable this in any way that they like and removing the default makes it purely opt-in.

[deads2k]

Default removed. If someone requests it, then it will function as desired.

[liggitt]

/kind feature
/priority important-soon
/lgtm
/approve

needs release note

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: deads2k, liggitt

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

The pull request process is described here

Needs approval from an approver in each of these files:

• staging/src/k8s.io/apiserver/OWNERS [deads2k,liggitt]

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

[mikedanese]

/lgtm