[SERVER-5479] Arbiter in authenticated replica set should allow and require login/auth for admin-only operations Created: 02/Apr/12 Updated: 30/Aug/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Admin, Replication, Security |
| Affects Version/s: | 2.0.3, 2.1.0 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Tad Marshall | Assignee: | Backlog - Security Team |
| Resolution: | Unresolved | Votes: | 42 |
| Labels: | datarepl3.2 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Tested on Ubuntu 11.10 64-bit with 2.0.3 and today's 2.1.1-pre- but probably the same on all platforms. |
||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
| Assigned Teams: |
Server Security
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Minor Change | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Create a replica set with one primary, one secondary and one arbiter, each started with --auth and --keyFile. Create a user in the admin database on the primary and log in with db.auth(). Admin-only commands like logRotate work on the primary. Set db to the local database on the secondary but do not log in with db.auth(). Admin-only commands fail as they should. Now set db to the local database on the arbiter. Admin-only commands work without log-in. This is convenient, since you CAN'T log in to the arbiter ... it has no admin database to hold the system.users collection. This is both inconsistent and a security problem. Once connected to the arbiter, the commands "use admin" and "db.shutdownServer()" will shut down the arbiter, for example. We should add a mechanism to make the admin.system.users collection from the primary available to the arbiter and enforced by the arbiter so that if authentication is running on the replica set then the arbiter follows the same rules as the primary and secondaries. |
| Comments |
| Comment by Wernfried Domscheit [ 11/Feb/21 ] | ||||
|
You can use this workaround. Stop the arbiter and restart in Maintenance mode (see https://docs.mongodb.com/manual/tutorial/perform-maintence-on-replica-set-members/index.html) Then create the Shard Local Admin User. Restart the Arbiter node in normal mode Of course, these steps should be done as part of the Mongo deployment. | ||||
| Comment by Alistair Evans [ 12/Apr/19 ] | ||||
|
Hey, just wanted to add on this issue that none of the workarounds provided seem to work (on 3.4.1); in general this problem is a major pain/concern for implementation on Windows Servers. The only available option is to stop the arbiter, rename the file and then start it again. This isn't too **bad if the majority of the set is healthy at the moment of restart, but if there are issues with the set at that moment, the Primary may step down, causing errors until the arbiter is back up and the majority is restored. Thanks, Alistair | ||||
| Comment by Spencer Jackson [ 23/Oct/18 ] | ||||
|
Hi, eliad. Because arbiters do not persist data, they don't have access to user credentials or privileges, and so cannot perform normal authentication/authorization. Changing arbiters to store cluster data would make authentication possible, but would be a significant change in behavior with operational considerations, and would require currently unscheduled development resources. Up-thread, there are some suggested workarounds which allow clients to authenticate as the __system user, and perform administrative actions, which I hope will help until a comprehensive solution is designed and implemented. Spencer | ||||
| Comment by eliad bar shaolm [ 23/Oct/18 ] | ||||
|
any update? maybe on version 4.0? | ||||
| Comment by Scott Lowe [ 15/Jan/18 ] | ||||
|
And updates here? | ||||
| Comment by Jyotman Singh [ 18/May/17 ] | ||||
|
Any update on this issue? This is a big problem. | ||||
| Comment by Henrik Hofmeister [ 31/May/16 ] | ||||
|
Still an issue on version 3.0.2 | ||||
| Comment by Jared D. Cottrell [ 28/Aug/14 ] | ||||
|
I'd like to see consistent credentials across the entire cluster, including the arbiter. In versions >= 2.6 I'm guessing this would mean replicating the admin.users collection. For users with privileges to do things that make no sense on an arbiter, performing such operations could just fail with the errors they already get if they try to do the same things as a super user. This would be useful for remote monitoring (e.g. MMS trying to run serverStatus) as well as remote operations like the one suggested in step 3 of the SSL upgrade:
| ||||
| Comment by Jared D. Cottrell [ 28/Aug/14 ] | ||||
|
It should be noted that logging in as __system using the key file as the password only works if your clusterAuthMode is keyFile (the default). If you switch to using x509 there is no more key file. | ||||
| Comment by Andy Schwerin [ 27/Jun/14 ] | ||||
|
brettcave, you should be able to use the contents of the keyFile to authenticate against the arbiter. Authenticate as the user "__system" on the "local" database. To convert the contents of the keyFile into a password you can use in the shell, typically it is only necessary to strip out the whitespace characters. | ||||
| Comment by Brett Cave [ 27/Jun/14 ] | ||||
|
Is it possible to use key-based authentication (in the same way that the RS authenticates using a key) - if that is possible, then monitoring / connections could be made using the key. | ||||
| Comment by Brett Cave [ 27/Jun/14 ] | ||||
|
We're using MMS monitoring service, and are unable to monitor any arbiters because of this issue. | ||||
| Comment by Spencer Brody (Inactive) [ 15/Apr/14 ] | ||||
|
To clarify, the current behavior when connecting to an arbiter with security enabled is that by default connections over localhost will be given full access (which will allow things like shutting down the arbiter), but remote connections will be denied all access. This is due to the localhost exception and the fact that the arbiter will always believe it has no users configured (as it has no admin database). If you disable the localhost exception (using the enableLocalhostAuthBypass option to setParameter), then all connections will be completely denied access. The only way to shut down the arbiter in that case would be through a signal from the operating system. | ||||
| Comment by Gerric Chaplin [ 05/Apr/13 ] | ||||
|
Bump for the greater good. Still an issue on 2.4.1.
| ||||
| Comment by Tad Marshall [ 11/Apr/12 ] | ||||
|
Some new information from the affected customer: We recently identified a bug where some authentication events were processed differently when the client was running on the same machine as the server. My testing was in an environment like this: I used different ports for the primary, secondary and arbiter, but all were running on the same machine and I connected to each of them from a mongo shell running on the same machine. This is a standard test scenario for us, but we will need to do more testing with access from different IP addresses now that we know about this issue. Can you try issuing your logRotate command from a mongo shell running on the same machine/instance as the arbiter and see if you can duplicate my result? In my test, logRotate worked. Thanks, let me know how this works! Tad You are right, running all mongo in the same machine and different ports the logRotate works. |