Skip to content
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

What does ValidatingWebhookConfiguration validate? #138

Open
jianhang33 opened this issue Nov 8, 2023 · 1 comment
Open

What does ValidatingWebhookConfiguration validate? #138

jianhang33 opened this issue Nov 8, 2023 · 1 comment
Labels
kind/question Question (asking for help, advice, or technical detail) lifecycle/stale Nobody worked on this for 6 months (will further age)

Comments

@jianhang33
Copy link

What happened:
This is more a question than a bug.

I was trying to figure out what ValidatingWebhookConfiguration (in helm) was validating, and found the following

  1. the generated url in clientConfig didn't work. It looks http://oidc-webhook-authenticator./webhook/validating. Is there something else I need to do before enabling this?
  2. It checks that issuerURL, clientID, and usernameClaim are set. Everything else seems to be optional. This is probably fine, but if I have a provider (an oath2 provider) that requires jwks.keys, it didn't complain. Is that expected?
  3. If we can make sure that id-providers have all the data and the right format. We don't actually need it, correct? Since it requires a caBundle for each instance, it is a little hard to do it automatically in scale.

What you expected to happen:
If it could detect that an oath2 provider requires jwks.keys, it would be great.

How to reproduce it (as minimally and precisely as possible):
deploy ValidatingWebhookConfiguration, and deploy id providers with jwks.keys commented out.

Anything else we need to know:

Environment:

@jianhang33 jianhang33 added the kind/bug Bug label Nov 8, 2023
@vlerenc vlerenc added kind/question Question (asking for help, advice, or technical detail) and removed kind/bug Bug labels Nov 8, 2023
@dimityrmirchev
Copy link
Member

the generated url in clientConfig didn't work.

I am not sure what values are you providing when installing the helm chart. Usually the validating webhook is referenced by its service

It checks that issuerURL, clientID, and usernameClaim are set. Everything else seems to be optional.

You can see what the validating webhook is actually checking directly in its implementation. But basically it performs some sanity checks on openidconnect objects.

func (r *OpenIDConnect) validate() field.ErrorList {

If we can make sure that id-providers have all the data and the right format. We don't actually need it, correct?

Well, yes. But this is actually the purpose of the validating webhook - to perform validation on the openidconnect objects.

If it could detect that an oath2 provider requires jwks.keys, it would be great.

How can this be done? Usually OIDC providers are publicly accessible and there is no need to provide their jwks.keys. If there is the need for non-generic validation an additional validating webhook can be implemented and installed to take care of these additional requirements.

Since it requires a caBundle for each instance, it is a little hard to do it automatically in scale.

I am not sure that I get this. Do you mean that it needs a different caBundle for each deployment/installation? I would say that this is pretty common scenario and certificate management/generation is not something specific to this component.

@gardener-robot gardener-robot added the lifecycle/stale Nobody worked on this for 6 months (will further age) label Jul 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/question Question (asking for help, advice, or technical detail) lifecycle/stale Nobody worked on this for 6 months (will further age)
Projects
None yet
Development

No branches or pull requests

4 participants