[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: |
|
||||||||
| 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: 2. Synchronize the config server users down to the replicas via the primaries. |
| 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:
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. |