ansible-middleware/keycloak

Discussion: possibility to "get rid of" `KEYCLOAK_ADMIN` and `KEYCLOAK_ADMIN_PASSWORD` env vars once the stage was bootstrapped

hwo-wd opened this issue · 3 comments

hwo-wd commented
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:

  • to manually change the 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)
  • to introduce a flag whether these env variables should be set, but this boils down to the former option pretty much

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 and keycloak...

ISSUE TYPE
  • Question/Discussion
guidograzioli commented

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
well spotted

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 :)

guidograzioli commented

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/

hwo-wd commented

Agreed, and https://unix.stackexchange.com/a/433910 also stipulates good argument (about systemd services though); looking at other files in /etc/sysconfig reveal pretty many 0644s though; anyway, thanks for the quick fix.

Thus bringing this issue back to the original question:

how to properly deal with KEYCLOAK_ADMIN[_PASSWORD] env variables

any constructive ideas welcome indeed ;-)