charts
charts copied to clipboard
bitnami
[bitnami/keycloak] Support for x509 authentication?
Name and Version
bitnami/keycloak/9.6.8
What is the problem this feature will solve?
First of all, I'm not sure if this is a bug report, a feature request, or just a request for support. However, no matter which of them it ultimately ends up being I do have a feature request related to it.
As far as I can tell given the set of environmental variables and values I'm given, there is currently no way to configure the keycloak image so that a client is required to provide a x509 cert. There are two routes I've previously seen in documentation or used to get a keycloak image to do this. The first is to feed an --https-client-auth=required to the kc.sh and the second is to mount in a custom standalone.xml file with the correct configuration to overwrite the existing one. I've tried doing both with this chart and the first doesn't appear to be working and for the second I couldn't find a standalone.xml file to overwrite (in contrast with every other keycloak image I've ever exec-ed into). I'm not sure why the --https-client-auth didn't work as I was able to confirm that extra startup args configured to the chart did reach the kc.sh (I was able to adjust the logging level for instance) however even with the option set that should enforce it, keycloak did not ask for client certs during the SSL handshake.
What is the feature you are proposing to solve the problem?
Even if this is already possible and I just haven't been able to figure out how, it would be nice there would simply be a chart value for https-client-auth that if set to either 'request' or 'require' would configure the jboss stuff appropriately.
What alternatives have you considered?
No response
Hi,
Thanks for your comments.
Have you tried to start with diagnosticMode enabled ? That way you could enter the POD and run the initialization and start the service manually. It is weird if the parameter is reaching kc.sh it is not enabled.
I had not. Taking your suggestion I did enable it and exec-ed in. However I wasn't actually able to run the kc.sh as it quickly became apparent that there were numerous things done by the scripts that run before the kc.sh (entrypoint, setup, run ect.) and without the setup and parameters provided by them the image would not work as intended. I could recreate all of the input parameters that would be provided to the entrypoint and run them through the scripts that but that would not be any different than running the pod not in diagnosticMode.
It may be worth noting that the option provided to the kc.sh is a thing I've seen in the documentation but it's never actually been how I've gotten it working in the past. In the past I've always overwritten the standalone.xml
It's funny you should get back to me on this Today as I just received news a couple days ago that invalidates the need for it on my end.
With that said, I still believe this is a feature that probably should be supported even if I personally don't need it for my current project anymore.
This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.
Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.