add structured authentication configuration

[Payback159]

What type of PR is this?

Uncomment only one /kind <> line, hit enter to put that in a new line, and remove leading whitespaces from that line:

/kind api-change
/kind bug
/kind cleanup
/kind design
/kind documentation
/kind failing-test

/kind feature

/kind flake

What this PR does / why we need it:

#11834

Which issue(s) this PR fixes:

Fixes #11834

Special notes for your reviewer:

I have tried to take #11822 into account.
I have one more question:

From my point of view, setting the default value for kube_oidc_username_prefix and kube_oidc_groups_prefix to oidc: would be the safer and more future-proof way. As this prevents any collision per default with other users.

This would mean a breaking change today, as Kubespray users who have not set the prefix would now receive a prefix and thus break the (cluster)role bindings if the user did not subsequently prefix all users and groups with oidc:.

The alternative is to set the prefix to an empty string, in which case there would be no breaking change and the user is responsible for the configuration.

Both are supported by “Structured Authentication Configuration” only not setting the prefix is unsupported. (Which to my knowledge was supported by kubeadm with the currently used --oidc flags.)

Does this PR introduce a user-facing change?:

Add the possibility to use "Structured Authentication Configuration" for Kubernetes API OIDC

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Payback159
Once this PR has been reviewed and has the lgtm label, please assign vannten for approval. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[k8s-ci-robot]

Hi @Payback159. Thanks for your PR.

I'm waiting for a kubernetes-sigs 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-sigs/prow repository.

[VannTen]

I would not put this under kube_oidc. The structured authentication configuration put the current possible config under the top level key, `jwt` and I understood it's not impossible this will be extended in the future for supporting other pluggable mechanism. In fact, I think we might as well expose the complete configuration by rendering a Ansible variable as yaml in the configuration file, maybe with smart defaults. Either way, this should not conflict with the existing oidc support in Kubespray. Upstream does not break compat with the OIDC authenticator, and we should not do that ourselves. On another note, you can't check the version for knowing if the feature is active : it could be explicitly enabled for earlier version or disabled for >=1.30 using the feature gate.

[yankay]

/ok-to-test

[Payback159]

Thanks. I have pushed another implementation based on your feedback.

The following has changed:

• removed configuration under kube_oidc
• the currently known version of the StructAuth configuration is templatized.
• The configuration is now rolled out based on the FeatureGate or not (and not based on the kube_version)

What is still missing in some areas of the jwt configuration would be to check whether the claim is configured directly because, as I understand it, the fields claimMappings.[username|groups].claim and claimMappings.[username|groups].expression are mutually exclusive.

What do you think?