0

We do copies from Prod -> Dev weekly. For the devs, we need a user that exists on the dev DB side to read/write into the dev DBs but not have this user exist on the prod side so we never have to give devs access to the prod databases whenever we want to give devs access to dev dbs. We do just make a brand new user each time as part of the workflow for this but it seems like there may be better solutions.

To simplify, how can we create a user in mongoDB so that it persists despite any restores or copies we do from Prod databases?

I have been looking into the $external for MongoDB but I don't think we have something like that setup and if we did how would that factor in RBAC? From what I've read, the external DB is not really a DB at all and only stores credentials. Wouldn't the roles for that user also then be erased if, like I mentioned before, we do a copy down from Prod? I feel like I am wrong here though so please feel free to correct me.

Shadow
  • 33,525
  • 10
  • 51
  • 64
Kyle
  • 15
  • 2

1 Answers1

0

All authorisation and authentication profiles are internally stored in the "admin" database even mappings for the virtual $external authentication/authorisation profiles they are also stored in the admin database.

Option 1) You mongodump/mongorestore only the necessary databases from PROD to DEV environments excluding the the admin database. ( Much cleaner option )

Option 2) If you take fs snapshots from PROD you will need to make mongodump for DEV admin database and mongorestore it after you restore the fs snapshot taken from PROD to DEV environment. ( Afcourse if you forget to mongorestore the DEV admin database you will have the PROD users in DEV ).

Option 3) You configure $external authorisation/authentication with same groups, mappings -> LDAP, KERBEROS etc , so you keep the mappings and copy PROD to DEV fs snapshots , but your users in DEV & PROD are auhtorized/authenticated by the external source ( LDAP server for example) so the credentials are not inside the DEV environment. ($external authentication/authorisation requiere mongoDB enterprise version)

R2D2
  • 9,410
  • 2
  • 12
  • 28
  • 1
    I think option 1 is a good option. Although, if we do make new users on prod in the future we might have to do a full restore then remake the read/write user on the dev dbs. But that is admittedly, more infrequent than weekly copies and making a new user. – Kyle Nov 17 '22 at 00:16
  • I do wonder if there are potential issues with not having the point in time admin database copied down to dev. Does the admin database contain anything that would be sensitive in that matter? Like indexes created at some point in time. – Kyle Nov 17 '22 at 21:50
  • No , it is only authorisation/authentication data ... – R2D2 Nov 17 '22 at 23:49