Secure the /q endpoint (or subset) in Prod more by default

[phillip-kruger]

Description

Currently users can include certain /q endpoints in a PROD profile. Some of these endpoint should be secured, but currently it's up to the user to do this, and by default, when including this, it will be unsecure.

This feature request suggest to change the default in the above case to secure, and let the user either 1) secure it themselves using their own security model, or 2) explicitly remove the security, or 3) keep the generated default security.

The generated default security could be a basic auth, that use admin and a generated password that print on startup ? Or just an admin key that print on startup.

Some /q services should always be open (like health). So this might only apply to certain services under /q , or health should be moved out of /q ?

cc @maxandersen @Sanne

Implementation ideas

No response

[sberyozkin]

I think this issue should be resolved, if it is to be resolved, as part of #5485.

I'm not sure it makes sense to selectively secure some /q endpoints if the rest of the application remains insecure by default

[sberyozkin]

Perhaps it is not worth mixing this issue with #5485. But managing the admin passwords out of the box (ex if basic auth is enabled for some /q/*) would require persisting them with all security related follow ups required (PEN testing, configuration management review, etc at the RHBQ level) - Quarkus will become an application itself. It is not a blocker in itself but something which is worth considering too when deciding how to approach it

[brunobat]

We got more users requesting this feature @sberyozkin @phillip-kruger

[geoand]

Won't this be dealt with when we have #23429?