5

In mongodb you can store user credentials in different databases. E.g. Say you have a products db, you could store the user products_worker in either database admin or products.

Is there a best practice here? I don't really like having users all over the place. Is there anything wrong with storing all users in admin?

7

Best practice is keep all users at admin database. However, some people don't like that they need to use --authenticationDatabase admin (or equivalent) when they login. Especially, if they use only one database.

2

In the MongoDB official documentation, users are created as an example. The example is creating admin users in the admin database, while other users are created in their respective databases: https://docs.mongodb.com/manual/reference/method/db.createUser/#db.createUser

We have created users in the database they belong to as we have done with oracle databases for many years.

I don't find anything wrong with "either" ways.

  • 1
    Actually, they do both. First examples are at DBs where users belong and rest of examples are created to admin DB. This is of course only when you are creating users to replica sets. When users are created at cluster environment (thru mongoS, not mongoD) all users are always actually at admin database even you "think" that you are creating the user to some specific DB.. – JJussi Jan 13 '18 at 8:15
1

I agree with you. I don't like the idea of having users all over the place, so I would go with having all users in the admin database.

0

Sorry for the answer, can't comment at the moment. For the easiest user management and security audit, create the users in the admin database. When you create the users, you create a role for them and you will specify the DB that role will be applied to. It makes sense to have the users in one DB and the only update would be to their role array if they are granted more role's or role's are revoked. Otherwise, you are going DB to DB to validate what role a user has.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.