Skip to content
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

Closed
hwo-wd opened this issue Apr 16, 2024 · 3 comments · Fixed by #197
Labels
question Further information is requested

Comments

@hwo-wd
Copy link
Collaborator

hwo-wd commented Apr 16, 2024

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
Copy link
Member

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
Copy link
Member

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/

@guidograzioli guidograzioli added the question Further information is requested label Apr 17, 2024
@hwo-wd
Copy link
Collaborator Author

hwo-wd commented Apr 17, 2024

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

hwo-wd added a commit to world-direct/ansible-keycloak that referenced this issue Apr 19, 2024
hwo-wd added a commit to world-direct/ansible-keycloak that referenced this issue Apr 19, 2024
hwo-wd added a commit to world-direct/ansible-keycloak that referenced this issue Apr 19, 2024
hwo-wd added a commit to world-direct/ansible-keycloak that referenced this issue Apr 19, 2024
hwo-wd added a commit to world-direct/ansible-keycloak that referenced this issue Apr 19, 2024
hwo-wd added a commit to world-direct/ansible-keycloak that referenced this issue Apr 19, 2024
hwo-wd added a commit to world-direct/ansible-keycloak that referenced this issue Apr 19, 2024
hwo-wd added a commit to world-direct/ansible-keycloak that referenced this issue Apr 19, 2024
guidograzioli added a commit that referenced this issue Apr 19, 2024
…_ADMIN_envs

#190: remove `keycloak_quarkus_admin_user[_pass]` once keycloak is bootstrapped
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
2 participants