Setting authentication properties at runtime / from config sources

[nullptr0000]

I'm sure there is probably something obvious I've missed somewhere but I'm having real problems trying to work this one out.

I have a 3rd party API, and I can generate a client for it, with basic auth, set the username and password for it in the application properties at build and everything works fine. Fully functional etc. etc.

If I try to override the default username and password to a different value compared via a configmap (i.e. give it a value replacing the application properties one) it complains with "WARN [io.qua.run.con.ConfigRecorder] (main) Build time property cannot be changed at runtime" which implies the credentials are baked in during build and can't be set later? Not ideal...

Trying it via a K8S secret is actually even worse, as it tries to initialise the config very early on, giving a 'java.util.NoSuchElementException: SRCFG00011: Could not expand value' error when it tries to find the secret value to read from. This seems to be due to it configuring even before the secrets have been loaded by the handler - if I run through the full debug it looks like there is an early load of the ConfigSources and a fuller one later, so this doesn't even fail to override as it just doesn't get the value in the first place. Trying to push through a native build of this just threw up lots of problems which seemed to track to the early initialisation when trying to set the config so I never got to run that.

All this stuff works find for the rest of the application so I'm stuck wondering what I might have missed? I don't think there's a programmatic way of setting the authentication values for the generated API - just the config options - and the documentation doesn't say anything about secrets etc. being tricky, and the config loading (buildtime/runtime/configmaps/secrets/etc) is working fine for the rest of my code, so I'm just left wondering where I could be going wrong??

Is there anything special about trying to set the configuration to anything except a static value at build???

[mcruzdev]

Hi @nullptr0000, did you try to use Custom Headers Support? Or even to customize the request?

[mcruzdev]

Before all, did you see this documentation?

[mcruzdev]

I created a simple sample to demostrating how to achieve it (to use basic authentication), see here.

[nullptr0000]

So I gave it a go - what I already did was aligned with the documentation and the above sample, the only real difference is I have 'basic_auth' instead of 'BasicAuth' (I did try that too just in case!), plus I have a base 'security:' entry in the OpenAPI definition and 'quarkus.openapi-generator.codegen.default-security-scheme=basic_auth' in my application properties. The configuration types I was trying for the authentication were the same as the sample in terms of using a quarkus.openapi-generator.myapi_yaml.auth.basic_auth.username=${api-user} type setting.

It looks like it works as expected if I use an ENV to set the config values (at least for a jar build) as per the sample, as I can see io.smallrye.config is loading those when trying to expand the configuration value and it gets through OK. The problem is that I'm trying to use a K8S secret read in using quarkus-kubernetes-config and that seems to work for other things but not the OpenAPI generator code. I can see a run of io.smallrye.config very early prior to Hibernate/Logging/etc which tries to expand the quarkus.openapi-generator config, then if that had succeeded there'd be a later run of io.smallrye.config that does include the K8S sourced values and this seems to satisfy the rest of the code without issues.

So at the moment it looks like I do have it set up correctly, it just doesn't want to use anything beyond the basic configuration sources as it initialises the configuration values so early in the startup?

On top of this if I try a native build it fails, and that seems to trace back to a 'java.util.NoSuchElementException: SRCFG00011: Could not expand value' which implies it wants to try to bake in the configuration during build as it apparently thinks it's build-time only and part of the basic initialisation phase. This only affects the quarkus.openapi-generator values and only if I set them via =${}, none of the other configuration has this problem.

Has anyone got this working with quarkus-kubernetes-config providing the values? And/or with a native build using a property expression to set the values? The documentation at https://docs.quarkiverse.io/quarkus-openapi-generator/dev/client.html suggests the config should just work as expected for a secret but nothing validates this. I guess I could hack the headers directly to set the auth but that feels like the wrong solution for something that is already built in and works if used slightly differently!

[nullptr0000]

OK so from a deeper look this seems like a side effect of #797 and #795, as someone had a brilliant idea to 'improve efficiency' and in the process changed the entire authentication configuration to be BUILD_AND_RUNTIME_FIXED instead of RUN_TIME which in turn means it can't be overridden by the K8S configuration loader or indeed anything else runtime so that 'improvement' just deeply breaks things.

If it's what it looks like then fantastic job on the design and testing there guys.

Maybe next time remember some configuration needs to be able to be set at runtime and split it up appropriately between build and runtime when you're diving in to 'fix' something just for the sake of it.

[nullptr0000]

Sorry if it came across as a bit abrupt, I had to spend a lot of time trying to work out what was going wrong with something so basic so it wasn't great realising someone had made a deliberate change in an attempt to make an improvement and the fairly obvious consequences hadn't been recognised.

This isn't the only accidental breaking change that was introduced by the same update but at least the OIDC dependency was easy enough to work around.

Obviously the goal of configuring authentication at build time was achieved and given that was the explicit intent I'm not sure how easy it would be to fix it back to being runtime short of reverting it all. Splitting out the authentication ptoperties that should be runtime configurable from those that might not want to be could be complicated.

[ricardozanini]

I'll have to solve another related problem today. After that, I will try it. Also, has the OIDC problem been solved already? Or are you still having it?

[mcruzdev]

I think, as part of the fix we need to do as part of the Quarkus 3 configuration change that made us use the Legacy approach, all the config can be reviewed and the BUILD_AND_RUNTIME_FIXED must be removed from the config root. cc @mcruzdev

Pull request opened #944, but I saw that you are working on it in another PR

[ricardozanini]

@mcruzdev Yes, I've changed all the configuration of all the runtime modules to RUNTIME, I had to change a few things here and there. I should update the PR with the test code now, and we should be ready to go.

[hbelmiro]

@nullptr0000 thanks for reporting it.
Just a reminder: this is an open-source project, so everyone is welcome and encouraged to review PRs. The more eyes we have on them, the lower the chances of mistakes.