-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add structured authentication configuration #11841
base: master
Are you sure you want to change the base?
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Payback159 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
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 Once the patch is verified, the new status will be reflected by the 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. |
d02425c
to
521f471
Compare
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.
|
/ok-to-test |
…and the entire Struct-Auth configuration and only create the configurations if the feature gate is activated.
Thanks. I have pushed another implementation based on your feedback. The following has changed:
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 What do you think? |
What type of PR is this?
/kind feature
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
andkube_oidc_groups_prefix
tooidc:
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?: