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

Issue #329: Initialization of a user defined database, username, and … #331

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Issue #329: Initialization of a user defined database, username, and … #331

wants to merge 2 commits into from

Conversation

johnwyles
Copy link

…password using environment variables

@yosifkit
Copy link
Member

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 --auth, the user and password will be meaningless since the DB won't require authentication:

mongo/docker-entrypoint.sh

Lines 186 to 187 in f1775b5

# if we have a username/password, let's set "--auth"
_mongod_hack_ensure_arg '--auth' "$@"

The second reason is that once authentication is turned on, there should be a user that has the role (minimum) of "userAdmin or userAdminAnyDatabase role in the admin database", since that is what MongoDB does for localhost exception when no users have been created and auth is on. I tested running mongod without auth, creating a readWrite user on test and then restarting mongod with authentication enabled. I can authenticate and do things in the test database as expected. But the downside is that, short of restarting the server to be without --auth, there is no way to change the password or do any administration and clustering.

…sername/password and rearranging ordering to suit this
@johnwyles
Copy link
Author

@yosifkit I have gated the requirement of a ROOT user to initialize a NON-ROOT user and updated the PR

@johnwyles
Copy link
Author

Updated documentation is now also detailing this information

@rmoreas
Copy link

rmoreas commented Apr 20, 2019

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 MONGO_INITDB_DATABASE_USERNAME and MONGO_INITDB_DATABASE_PASSWORD.

@kmualem
Copy link

kmualem commented Jul 23, 2019

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?

@justsml
Copy link

justsml commented Nov 3, 2019

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.

@KenEucker
Copy link

KenEucker commented Feb 7, 2021

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:

For context, I've just spun up half a dozen first-party different Docker images for various databases (as I'm writing tests for a library that supports a range of backend databases) and the mongo Docker file is the only first-party image that didn't make it easy to spin up an instance with read/write access to a named database using username, password and database environment variables.

@rafaelcalves
Copy link

UP 🥲
Is there any possibility of this feature to be approved and merged someday?

@johnwyles
Copy link
Author

@rafaelcalves with all the common sense in the world at your fingertips you will never see this merged… it’s just too obvious

@LaurentGoderre
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants