You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The way security config is implemented leads to an undesired dilemma in case you want to manage users on the OS platform via OS Dashboards or the API.
The fact that both internal users and security config are in the same secret means that the management of both is interconnected.
The implementation of this PR improved things, but did not solve the issue.
How can one reproduce the bug?
You basically have 2 options:
In security config internal_users.yml you define admin user with a custom password plus your security config under config.yml. You then create other users in OS using e.g. OS Dashboards or the OS API. If you need to make a change in config.yml, the Operator will detect this and run the security admin job, which will also overwrite your users, because in security config the internal_users.yml file is present.
In security config you only define config.yml. This means that admin user will have the default (admin) password. You then create other users using Dashboards or the API. If you need to make a change in config.yml then, because internal_users.yml is not defined in security config, the users you have created will remain in place. But this means that you're stuck with default admin credentials forever which is a security issue.
What is the expected behavior?
I see there are two options:
Separate config.yml with users/roles/etc configuration. Changes in config.yml should only trigger this part of the config to be changed and not touch users/roles/etc.
Create more complex default password for admin user like requested here. You're again stuck with it (i.e. if you try to change this you will overwrite your users), but at least it will not be admin/admin.
Thank you in advance.
The text was updated successfully, but these errors were encountered:
Hi @dmantas. This is currently a limitation of the operator that are discussed in several issues: #571, #254, #221.
Right now you can only use either securityconfig or CRDs for user management.
What is the bug?
The way security config is implemented leads to an undesired dilemma in case you want to manage users on the OS platform via OS Dashboards or the API.
The fact that both internal users and security config are in the same secret means that the management of both is interconnected.
The implementation of this PR improved things, but did not solve the issue.
How can one reproduce the bug?
You basically have 2 options:
internal_users.yml
you defineadmin
user with a custom password plus your security config underconfig.yml
. You then create other users in OS using e.g. OS Dashboards or the OS API. If you need to make a change inconfig.yml
, the Operator will detect this and run the security admin job, which will also overwrite your users, because in security config theinternal_users.yml
file is present.config.yml
. This means thatadmin
user will have the default (admin
) password. You then create other users using Dashboards or the API. If you need to make a change inconfig.yml
then, becauseinternal_users.yml
is not defined in security config, the users you have created will remain in place. But this means that you're stuck with default admin credentials forever which is a security issue.What is the expected behavior?
I see there are two options:
config.yml
with users/roles/etc configuration. Changes inconfig.yml
should only trigger this part of the config to be changed and not touch users/roles/etc.admin
user like requested here. You're again stuck with it (i.e. if you try to change this you will overwrite your users), but at least it will not beadmin
/admin
.Thank you in advance.
The text was updated successfully, but these errors were encountered: