Replies: 12 comments 23 replies
-
|
I can think about two possible approaches to this this problem:
In both cases, users should be created based on a local-secure-random token (probably created when the server is started for the first time) so that access is restricted to localhost. I think both options are mutually exclusive, and I'm not sure which one is the best. By leveraging On the other hand, providing a specific command in Dist.X CLI would provide a simpler experience to solve this particular problem? |
Beta Was this translation helpful? Give feedback.
-
|
We need to keep the cloud env in mind for the initial admin creation (and maybe even for the restoration). Even though the Operator.X won't need it (it won't be managing any KC resources), users need to be able to simply login to their new KC instances. And SSHing to the pod (to execute bunch of commands locally) is probably not the most user friendly solution. We should probably allow creating an admin user from a file that would be actually a mounted K8s secret (env vars are considered less secure). The question is, what about restoring access? What if the secret is then modified by the user? Do we care? Will it take any effect in KC? Should we even allow changing the admins password via REST API, or should we just rely on file/secret? |
Beta Was this translation helpful? Give feedback.
-
|
Summarising use-case:
Not really convinced the current approach we have with kc-add-user + environment variables are the best, especially on the container and operator. Leeds to questions like should the admin password be updated if the env variable changes, and things like the operator keeping a secret with the admin password (that results in sharing an admin account). Some thoughts on perhaps a different way:
Not sure about recover admin access, but if you think about anyone that has access to the KC process and server config files will be able to get access to the DB secret (even if stored in a vault). So, the local auth for kcadmin could make sense, or perhaps just connect to the DB directly, with a special way to start the server like we do today. In essence though I'd like to see a bit more UX-centric discussion happening here. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, as discussed with @vmuzikar in discussion 9362, I have the following use case (which is the same as reading env vars from mounted volume IMHO):
/vault/secrets/admin-credentials KEYCLOAK_ADMIN=toto
KEYCLOAK_ADMIN_PASSWORD=testI would like to know if it's possible to read those values at boot time ? |
Beta Was this translation helpful? Give feedback.
-
|
Hi Guys, What is the latest about this? I would like to mount the KEYCLOAK_ADMIN_PASSWORD from a file but I am not sure how to import it. The password is already mounted in Thanks |
Beta Was this translation helpful? Give feedback.
-
|
After reviewing this discussion with @stianst, it is more clear the use cases we want to support:
BootstrappingThis use case is about starting the server for the first time and gaining access to the server to perform management operations. Currently, the master admin account is created by:
Using environment variablesCreating the master admin user using environment variables is not secure and considered a bad practice. Credentials are in plain text and can easily be accessed if you have access to the environment/container where the server is running. For instance, one can easily see the credentials from using a CLI or the UI if using Openshift. An alternative to environment variables is to use mounted secrets but they are still open from unwanted access if you have access to the environment where the server is deployed. Note that this mechanism is mainly useful when you can't access the welcome page to create the admin user because you can't access the server through the loopback interface (running as a container) or when you want automation happening right after the server is started to provision realms. Welcome PageCreating users from the welcome page should be OK and kept as is. However, it does not help much if you need automation right after the server is started, like provisioning realms. Import RealmIf you are fluent enough to create a JSON file with realm representations, importing a realm at startup can help to not only bootstrap the master admin user but also any other data you need to provision. This approach does not provide the necessary flexibility in terms of configuration because the realm configuration is statically defined in a JSON file. Recovering AccessThe solution for recovering access is not so clear. Here we can use recover links or just specific commands in the CLI to manage admin access as previously suggested. Other than that, recovering access for admin accounts should leverage the existing capabilities provided by the server like using email and action tokens. AutomationThe way we are doing automation is wrong because it relies on the master admin user. We should favor instead using master service accounts for a number of reasons, some of them are:
If we create a master service account when bootstrapping the server, as previously mentioned, we should be able to provide a better and more secure ground for automation. If we go through the ProposalWe keep the welcome page and import realm methods for bootstrapping the master admin user and realms. We drop support for environment variables to create the master admin user. We also do not support mounted secrets. I know that has a deep impact on UX and how you are using containers and the operator, but at the same time relying on environment variables or mounted secrets is not really secure. Perhaps we can still support them with a trade-off and I would like to hear what others think about it. Instead, we should consider introducing a The problem with the If the proposal around the By introducing the An alternative to the |
Beta Was this translation helpful? Give feedback.
-
|
The current recovery story is a pain: Before upgrading to recent keycloak, our admins used direct access to keycloak processes to create a new, temporary, admin user and password with the environment variables (via kubernetes/helm). We tried to simply delete all users in the For what it's worth, our current procedure is to manually created via raw SQL a ADMIN_USER_ID=09fd95c9-b774-4c87-a9f1-17f58e60c4da
PASSWORD=$(pwgen -s 22 1)
python3 - <<OEF
import os
from base64 import b64encode
from hashlib import pbkdf2_hmac
import json
import uuid
salt = os.urandom(16)
iterations = 27500
secret_value = pbkdf2_hmac('sha256', b'$PASSWORD', salt, iterations, dklen=64)
secret_data=json.dumps({"value": b64encode(secret_value).decode(), "salt": b64encode(salt).decode()})
credential_data=json.dumps({"hashIterations": iterations, "algorithm": "pbkdf2-sha256"})
print(f"INSERT INTO credential (id, type, user_id, secret_data, credential_data, priority) VALUES ('{uuid.uuid4()}', 'password', '$ADMIN_USER_ID', '{secret_data}', '{credential_data}', 10)")
OEF
echo Use this password to login: $PASSWORD(It seems the cache sometimes causes issues and the login doesn't work; a restart helps.) => It would be great to have a much easier way to recover access via server access like we had before. |
Beta Was this translation helpful? Give feedback.
-
|
Hello, I have an error in the following code, can you help me? |
Beta Was this translation helpful? Give feedback.
-
|
hi recently, i report a issue by now keycloak can delete all users,include himself. i think we shoud add a check to prevent a user can delete himself |
Beta Was this translation helpful? Give feedback.
-
|
I am trying to run the following - But getting an error that says - |
Beta Was this translation helpful? Give feedback.
-
|
Importing on startup is problematic when there are multiple files because no order is defined. In my case I wanted to separate the definition of a new realm with the definition of the users in that realm, so that QA could easily add more users without changing the realm, but ExportImportManager does not sort the file list (line 124) so it happened that the users were imported first before the realm was defined. I might try to make the changes myself, but I am not a sw developer (well not since the early 1990's with Java 0.3) |
Beta Was this translation helpful? Give feedback.
-
|
Created a summarized design proposal here. Input would be most appreciated. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
We should provide a better experience for managing admin access to a Keycloak server. There are two main use cases we want to support, as suggested by @stianst :
The corresponding operations to support the aforementioned use cases should rely on specific commands available from the CLI.
Create the initial admin account
This operation should be as simple as creating the master admin account for the first time. Helpful to automate how servers are preovisioned.
Recovering access when admin account is lost
This operation should allow the password to be recovered. There are some things to consider here like how to securely give information about the master admin.
Perhaps we could rely on sending an e-mail based on the e-mail previously set to the admin account. If not set, recovery should not be possible.
Or perhaps we could generate recovery codes or basic support for 2FA.
Beta Was this translation helpful? Give feedback.
All reactions