KEP-3331: Structured Authentication Config

[nabokihms]

• One-line PR description: Structured config for OIDC authentication

• Issue link: Structured Authentication Config #3331

• Other comments: -

[k8s-ci-robot]

Hi @nabokihms. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[enj]

/assign

[enj]

@nabokihms are you targeting this for v1.26?

[nabokihms]

@enj Yeah, I'd like to take it to v1.26 if it is possible.

[liggitt]

/ok-to-test

[liggitt]

did a first pass on the proposed config structure

[andrewsykim]

(shadowing @deads2k on PRR)

[andrewsykim]

Some possible rollout/rollback failures I can imagine are:

• General bugs in kube-apiserver's parsing of the structured config file. Maybe more relevant in future versions where there could be bugs in the conversion logic between multiple versions (v1alpha1, v1beta1, etc) of the config.
• Cluster admin rolls out the feature with the addition of some validation rules that may have some untended consequences
• Rolling back would mean losing validation functionality offered from structured config that some other component may depend on

(not suggesting much can be done about all of these, especially if they are due to user error, but probably worth noting here)

[deads2k]

Yes. And noting that failures are intended to prevent process startup means that HA clusters that ripple-start will survive intact.

[enj]

This is ready from an API perspective (have addressed all of Jordan's API review feedback).

/approve

Just waiting on PRR now.

/assign @deads2k

[andrewsykim]

Any reason integration tests aren't included here? Is it because we need to test with a OIDC provider?

[enj]

This is a typo and should say integration tests, will fix.

[andrewsykim]

I would just say No here, reading and serializing the config on start-up is negligible, unless we plan to watch for file changes and allow for dynamic changes to the authentication config

[enj]

We do plan to watch for config changes and dynamically update the authenticators (and likely throw away the token cache). This also involves re-parsing the CEL functions (and we have new overhead of CEL functions per authentication as well).

[deads2k]

PRR is complete enough for alpha. Please consider what metrics you'll add for beta when this gets enabled by default.

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: deads2k, enj, nabokihms

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:

• keps/prod-readiness/OWNERS [deads2k]
• keps/sig-auth/OWNERS [deads2k,enj]

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

[enj]

/lgtm