-
Notifications
You must be signed in to change notification settings - Fork 634
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
Issue #329: Initialization of a user defined database, username, and … #331
base: master
Are you sure you want to change the base?
Issue #329: Initialization of a user defined database, username, and … #331
Conversation
…password using environment variables
Still not really sold on this. But as far as current implementation it must be gated behind also having a root user and password. The first reason is that without forcing on Lines 186 to 187 in f1775b5
The second reason is that once authentication is turned on, there should be a user that has the role (minimum) of " |
…sername/password and rearranging ordering to suit this
@yosifkit I have gated the requirement of a ROOT user to initialize a NON-ROOT user and updated the PR |
Updated documentation is now also detailing this information |
This would be a nice addition because it would be much easier to initialize a database user for the application! Although to have some consistency in the naming of the variables, I would suggest using |
I agree that it will be a great addition! currently I'm struggling with a non-root admin creation as part of the docker-compose, so if the feature will be available it will be awesome. Is there any update about it? do you have any estimations when this should be ready? |
I'd say that being "locked out" or no root user is a feature here. If you need to do admin or clustering stuff, you're probably more willing to jump into some scripting to take care of restarting the server to make any changes. Without this PR/functionality, devs will continue setting up mongo+docker with very risky defaults. |
Echoing the sentiments of @justsml here, having no root user would indeed be a security feature of this type of configuration. I think that advocating for the ability to create a default database and username+password pair, on behalf of those users who are looking to simply get going with docker-compose, is the right decision here. Forcing users to dive deeper into mongo specific configurations in order to extend the configuration beyond the docker-compose.yml file, in even the most simple of use cases, feels like it is in competition with the docker community's expectations. Another user commented this on a now archived ticket:
|
UP 🥲 |
@rafaelcalves with all the common sense in the world at your fingertips you will never see this merged… it’s just too obvious |
This feels like an anti-pattern. If one were to use a managed mongo instance, they wouldn't have access to the root user so for consistency and good habits, the documentation section about initializing a fresh instance should be the go to for this and requires a lot less code. |
…password using environment variables