-
Notifications
You must be signed in to change notification settings - Fork 56
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
Discussion: possibility to "get rid of" KEYCLOAK_ADMIN
and KEYCLOAK_ADMIN_PASSWORD
env vars once the stage was bootstrapped
#190
Comments
oh wow this being 644 is huge issue: https://github.com/ansible-middleware/keycloak/blob/main/roles/keycloak_quarkus/tasks/systemd.yml#L9, definitely needs to be 400 As for the envvars I am aware of their single-shot usage; and have been reluctant to do anything without proper thinking, so anybody with idea pls come forward :) |
That said, if somebody has enough privileges on the machine to read /etc/sysconfig/ , no envvar protection can really be implemented, because he would be able to read /proc/ |
Agreed, and https://unix.stackexchange.com/a/433910 also stipulates good argument (about systemd services though); looking at other files in Thus bringing this issue back to the original question:
any constructive ideas welcome indeed ;-) |
…nce keycloak is bootstrapped
…nce keycloak is bootstrapped
…k.general.bootstrapped`
…nce keycloak is bootstrapped
…nce keycloak is bootstrapped
…nce keycloak is bootstrapped
…nce keycloak is bootstrapped
…nce keycloak is bootstrapped
…_ADMIN_envs #190: remove `keycloak_quarkus_admin_user[_pass]` once keycloak is bootstrapped
SUMMARY
These two env vars allow to set the initial admin and kc takes care of creating this initial user if it doesn't exit yet. With other words, these are only really required on a new installation but from a security perspective the do not necessarily have to reside in
/etc/sysconfig/keycloak
where the whole world (with access to the machine) can read these and thus basically have a root-login.I've been thinking whether there's a possibility to reduce the exposure of this sensitive data in an automated way, something like keeping them until KC has fully started, then removing them, but I do not really like any of my ideas so far.
So this issue is really more a brainstorming on how one could approach this as part of this role.
(Untested, but should be doable) manual workaround by the operator would be:
KEYCLOAK_ADMIN_PASSWORD
to a dummy value once the environment has been fully initialized (NB: the role doesn't support an empty password as of now)Note: reading the KC source, these 2 can only be set as environment variables, i.e., there is no option to move these into a trust store which could only be read by
root
andkeycloak
...ISSUE TYPE
The text was updated successfully, but these errors were encountered: