[SERVER-66228] Not possible to automate setup of replicaSet with RBAC Created: 05/May/22  Updated: 08/Sep/22  Resolved: 08/Sep/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Currn Hyde Assignee: Chris Kelly
Resolution: Done Votes: 0
Labels: Replication, authorization, replica-set
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Steps To Reproduce:

For mongodb to support a replicaset it must have in the mongod.conf file:
replication:
   replSetName: <someName>
 
at the same time for RBAC to be enabled it must contain:
security:
   authorization: enabled
as well as the mode (ex: x509 or keyfile)
 
The issue: With Authorization enabled the only thing you can do, and therefore the first thing you must do is to create the admin user with the ability to create other users via the localhost exception. But that's not possible. This is being blocked by mongodb because the replication specification means mongo will always return:
MongoServerError: not primary
 
this can only be eliminated by first setting up the replicaset. But you can't because that's in conflict with RBAC where the only thing you can first is create a user... but you can't do that because of the replicaset where the only thing you're allowed to do is configure the replicaset and around and around the problem goes.
 
The only current workaround for this design flaw is to boot with one configuration that leaves out one of these options. Configure the remaining option. Then shut down mongodb and swap out the configuration file with the complete one that has both replicaSet and RBAC enabled then reboot mongo and complete the setup of the other one. This is a very annoying problem and is counter intuitive. Please Fix.

Participants:

 Description   

There are requirements to setting up a RBAC. There are requirements to setting up a replica set. These requirements are opposed to each other making it not possible to automate the setup of a mongo server.

 



 Comments   
Comment by Chris Kelly [ 08/Sep/22 ]

Just to add clarification before closing this ticket:

There is a documented for accomplishing setting up new replica sets with RBAC.

In order to do this, follow the steps for Deploying a Replica Set With Keyfile Authentication. The key point you are interested in is step 4, connecting over the localhost interface. 

From here you can also initiate the replicaset, without rebooting or swapping configs, and then subsequently create your administrator user.

After you create the first user, the localhost exception is no longer available. The first user must have privileges to create other users, such as a user with userAdminAnyDatabase. This ensures that you can create additional users after the Localhost Exception closes.

If there are any further difficulties, the documentation has good examples for accomplishing this in more ways, and in greater detail. If you happen to find inconsistencies there that don't make sense, we would be interested in fixing that though.

Regards,
Christopher

 

Comment by Currn Hyde [ 11/Jul/22 ]

I have just been using the workaround I listed in my bug report of partial
setup, shutdown and swap configs, then boot and continue.

Comment by Chris Kelly [ 11/Jul/22 ]

Just wanted to check in on this, did this solution work for you? If so, we can close this ticket.

Christopher

Comment by Spencer Brown [ 31/May/22 ]

As mentioned in our tutorial for manually deploying a replica set with keyfile authentication, you can:

1. Start the replica set members with a configuration including both the replica set name and security auth enabled and keyfile internal authentication
2. initiate the replica set under the localhost exception
3. Create the first admin user, also under the localhost exception

This is how MongoDB's automation solutions (Atlas, Ops Manager, Cloud Manager) create new replica sets.

Please try this and let us know if it works for you.

Generated at Thu Feb 08 06:04:50 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.