[SERVER-12798] Make shard maintenance independent of local admin users Created: 20/Feb/14  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Security, Sharding
Affects Version/s: 2.5.5
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Andreas Nilsson Assignee: Backlog - Security Team
Resolution: Unresolved Votes: 1
Labels: platforms-re-triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-11648 Add passthrough connection to shard v... Open
Assigned Teams:
Server Security
Backwards Compatibility: Minor Change
Participants:

 Description   

At the moment in a sharded, auth-enabled system local users on the replicas are required to perform maintenance operations on primaries and secondaries.

This is a confusing inconsistency since the main users of the system are maintained on the config servers and we generally disencourage creating local users. Examples of operations requiring this type of access is running compact.

Some possible strategies to solve this are:
1. As soon as sharding is enabled, let the replicas contact the config servers for auth, just like mongos does. This requires the replicas (including secondaries to have access to the config servers) and will require some mongos/config server fu be copied to mongod.

2. Synchronize the config server users down to the replicas via the primaries.
It is rather inconvenient and cludgy to introduce another information pushing channel in addition to mongos-primary and primary-secondary.



 Comments   
Comment by Jianfa Tang (Inactive) [ 05/Sep/14 ]

I believe a true general purpose solution would be to implement centralized authentication/authorization. i.e., auth attempt on shard replicaSet members should be sent to config server(or mongos?) to be handled. This would be the most intuitive implementation.

Comment by Scott Hernandez (Inactive) [ 13/Mar/14 ]

One part of shard maint/management could be to allow connections/commands through mongos to individual cluster members to initiate and execute operations, maybe something like this:

{runCommand:"setParameter", on:"$ConfigServers", command:{setParameter:true, logLevel:2}}

In this example the "on" field could be either an array of hostnames within the cluster, or special variables which expand to well-known sets ($ConfigServers, $Shards, etc...).

In addition this could also potentially allow user impersonation, with an "as" option.

Generated at Thu Feb 08 03:29:39 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.