You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As an apparent side effect of #797 and #795 the ability to configure authentication appears severely limited.
The configuration of authentication has changed to BUILD_AND_RUNTIME_FIXED instead of RUN_TIME. This appears to have the side effect (for example) of preventing the Quarkus Kubernetes Config methods being used to set or override values from K8S ConfigMaps or Secrets, and presumably breaks other production solutions invoked at runtime too eg. Vault.
I suspect the change also affects the ability to configure authentication values using system & environment properties for native builds, though this does still work OK for jar builds.
Setting certain configuration properties at build isn't necessarily an issue even if it's potentially inflexible, but deployment specific dynamic values (at minimum usernames/passwords/other identifiers) should always be configurable at runtime.
Either the authentication configuration should revert to runtime from build time or the configuration properties should be split into runtime and build time depending on their effect, in line with the methodology of other Quarkus components.
The text was updated successfully, but these errors were encountered:
As an apparent side effect of #797 and #795 the ability to configure authentication appears severely limited.
The configuration of authentication has changed to BUILD_AND_RUNTIME_FIXED instead of RUN_TIME. This appears to have the side effect (for example) of preventing the Quarkus Kubernetes Config methods being used to set or override values from K8S ConfigMaps or Secrets, and presumably breaks other production solutions invoked at runtime too eg. Vault.
I suspect the change also affects the ability to configure authentication values using system & environment properties for native builds, though this does still work OK for jar builds.
Setting certain configuration properties at build isn't necessarily an issue even if it's potentially inflexible, but deployment specific dynamic values (at minimum usernames/passwords/other identifiers) should always be configurable at runtime.
Either the authentication configuration should revert to runtime from build time or the configuration properties should be split into runtime and build time depending on their effect, in line with the methodology of other Quarkus components.
The text was updated successfully, but these errors were encountered: