-
Notifications
You must be signed in to change notification settings - Fork 275
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
Replace admin:admin
default credentials
#1576
Comments
Agreed -- the inability to change the admin password in particular without wiping the internal user database is a problem. |
It seems like this is assuming use of the security plugin. It should be optional to use the security plugin. I believe this should be mobed to the security plugin repo here - https://github.com/opensearch-project/security |
@CEHENKLE I don't have permissions to transfer issues to the security plugin repo. Could you pls do that? |
This is a super important security issue. Can you please prioritize it? PS: it seems like there is something that could handle this - but it is 1. not documented and 2. I am not sure how and if it even works. |
@PhilipMay Agree. Take a look at: opensearch-project/OpenSearch#1029 We plan to make changes this year in a major version, but let's not wait if there are low things we can do before that. |
There was a related issue filed opensearch-project/security-dashboards-plugin#1008 where the admin password was not able to be updated in the UX |
Any update on this case !! |
Checking if there is update on this issue ? |
The only way to solve this issue is to add your internal_users.yml under Ex: internal_users.yml: |-
---
_meta:
type: "internalusers"
config_version: 2
admin:
hash: ""
reserved: true
backend_roles:
- "admin"
|
I wrote up https://code.dblock.org/2023/08/08/changing-the-default-admin-password-in-opensearch.html which should show how hard this is to actually do today. I like the idea that the system would come up with a generated password, and require changing that password in a secure way on start. |
Opensearch admin:admin Debian/Ubuntu Solution:
|
@scrawfor99's pull request [1] to address this issue was recently merged in to main. We are about to backport this change into 2.x and want to get some feedback on how we think about approaching this. Currently Planned BehaviorIf a password for the admin account is not supplied, the demo_configuration script will exit early with the following message. echo "Unable to find the admin password for the cluster. Please run 'export initialAdminPassword=<your_password>'
or create a file $ADMIN_PASSWORD_FILE with a single line that contains the password." Otherwise the following will be printed in the middle of the script
What do we think about these changes going into the 2.x release? Are there any modifications that would make this more palatable? Note, I'm also going to mark this |
[Triage] Maintainers agree to take the tradeoff of "breaking" new installs that don't provide a default password for the admin user, for the sake of better securing future cluster installs. This does not break current clusters that get upgraded to a newer version, as those would already have created their admin user/password. That said, we want to make sure that at the very least we fix the docker images we publish alongside our artifacts (and the functional tests) to account for this change. Until those are addressed, the 2.x backport in #3414 should be blocked. |
i can't update admin account : {"status":"FORBIDDEN","message":"Resource 'admin' is reserved."}
and it's working admin password is changed and demo account are back gain... at least I was able to change the default password so thank you :) |
Hey @guldil, I don't think these changes have gone out yet. You should still be able to use the default credentials |
@scrawfor99 but i dont want to use default password, i start a VM with OpenSearch on my private cloud and i can't let the VM with default password, i need remote access on it. For me it's a good solution, i installed OpenSearch 2.11, i change certificates used by default (root-ca / kirk) with my own certificates issued with my "root-ca-new" and i change admin password with my own "admin" (the default kirk). It helped me understand how this part worked. |
Hi @guldil, thanks for the clarification. What you described should work--I was just trying to clarify why the steps on this issue may not be operable quite yet. Everything listed on the documentation website should still work for your use case. |
@scrawfor99 yes i found documentation too late https://opensearch.org/docs/latest/install-and-configure/install-opensearch/debian/#configure-tls, eveything is on it. Maybe documentation installation of Dashboard could be better https://opensearch.org/docs/latest/install-and-configure/install-dashboards/debian/ and https://opensearch.org/docs/latest/install-and-configure/install-dashboards/tls/ when you change Certificates / CA (like the TLS one of OpenSearch Only) |
Hi, |
I am having same issue . Would be good if this cloud be automated. Ideal situation will be to pass the desired password as input to script or playbook. |
if you are using helm charts for deploying opensearch, you can update your opensearch helm chart to use internal_users.yml template and add your admin user password there, for future changes, you can use securityadmin.sh for retrieving the security index data (users, roles, rolesmapping, etc) and put them into a folder and update them and re-uploading them to security index again using securityadmin.sh shell also.
./securityadmin.sh -cd ../../../config/security_backup/ -icl -nhnv \
-cacert ../../../config/root-ca.pem \
-cert ../../../config/admin.pem \
-key ../../../config/admin-key.pem -r
./securityadmin.sh -cd ../../../config/security_backup/ -icl -nhnv \
-cacert ../../../config/root-ca.pem \
-cert ../../../config/admin.pem \
-key ../../../config/admin-key.pem
Opensearch Version: 2.9.0 -- deployed with helm chart version (opensearch-2.14.0) References |
Hi @LinTechSo, @guldil, etc. Just an update: This is actively being worked on by @derek-ho and @DarshitChanpura they are making great progress and hoping to get this out in 2.12. That being said, we have to wait for 2.12 at the earliest since this marks a fairly large UX/UI change from the current way of doing things. You are welcome to check out some of their work over on the repo's pull request list. |
@DarshitChanpura Could you link this to the meta issue where we are addressing this? |
The effort replace default admin password with a custom supplied password is being tracked here:
The issues stemmed from this spike: #3560 If you would like to, please follow these issues along to compute the work done as we target to ship this change with the next release. |
The default credentials for demo admin user have been replaced with a custom password requirement, and this feature has been shipped in 2.12.0. Marking this issue as complete. Please feel free to re-open if something was missed. |
Is your feature request related to a problem? Please describe.
The default
admin:admin
credential is too weak and a sure-fire way to get hacked. Though the documentation recommends users to change the default passwords, it can be easily missed. Such weak defaults can be very easily exploited and lead to massive data leaks (remember Equifax attack?).The second gap is, in the existing distribution, there's no default password policy to ensure stronger passwords. It needs to be configured explicitly by users. That is why such weak credentials are able to slip through the cracks.
Describe the solution you'd like
Remove the default passwords provided in
internal_users.yml
. Instead, have theadmin
user setup passwords for internal users once the OpenSearch process is up. These passwords can be set up post-installation using a REST API andadmin
certificates (for authentication). Setting password foradmin
user would look something like -To make this further easy, OpenSearch distribution could provide a tool such as an OpenSearch shell client to make it easy for admin user to configure all users. This shell client could also help with autogenerating strong passwords and can be further extended to support for more administrative functions in future.
In addition to this, we should also add a default password policy to only allow passwords that match a certain strength criteria. Obv, these policies are overridable depending on the user/enterprise needs. Having a strong default policy will protect against insecure password configurations.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
This is related to opensearch-project/OpenSearch#1618
Task breakdown
The text was updated successfully, but these errors were encountered: