[SERVER-921] sharding authentication support Created: 10/Mar/10 Updated: 12/Jul/16 Resolved: 22/Jun/11 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 1.9.1 |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Eliot Horowitz (Inactive) | Assignee: | Kristina Chodorow (Inactive) |
| Resolution: | Done | Votes: | 23 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||
| Issue Links: |
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
Will use private key for internal communication. |
| Comments |
| Comment by larry.loi [ 13/Dec/11 ] |
|
the attached log is which crashed shard server log file. |
| Comment by larry.loi [ 13/Dec/11 ] |
|
got a kinda message like that |
| Comment by Kristina Chodorow (Inactive) [ 13/Dec/11 ] |
|
@larry.loi: please create a new bug and attach your mongod log from the crash. |
| Comment by Kristina Chodorow (Inactive) [ 13/Dec/11 ] |
|
@larry.loi: please create a new bug and attach your mongod log from the crash. |
| Comment by larry.loi [ 13/Dec/11 ] |
|
if disable authentication, map reduce will running fine. |
| Comment by larry.loi [ 13/Dec/11 ] |
|
I am running 2.0.1, my shard servers environment is working fine in general operations like insert, update, select delete etc. but it would crash the primary shard of a database if I running map reduce. |
| Comment by Kristina Chodorow (Inactive) [ 29/Jun/11 ] |
|
No, it will be available in 2.0. |
| Comment by Everett Li [ 29/Jun/11 ] |
|
Will this fix be backported to 1.8.x? |
| Comment by Kristina Chodorow (Inactive) [ 22/Jun/11 ] |
|
See documentation at: http://www.mongodb.org/display/DOCS/Security+and+Authentication#SecurityandAuthentication-ReplicaSetandShardingAuthentication |
| Comment by auto [ 22/Jun/11 ] |
|
Author: {u'login': u'kchodorow', u'name': u'Kristina', u'email': u'kristina@10gen.com'}Message: add auth support |
| Comment by auto [ 22/Jun/11 ] |
|
Author: {u'login': u'kchodorow', u'name': u'Kristina', u'email': u'kristina@10gen.com'}Message: move runAgainstRegistered to sharding |
| Comment by auto [ 22/Jun/11 ] |
|
Author: {u'login': u'kchodorow', u'name': u'Kristina', u'email': u'kristina@10gen.com'}Message: split security into s-only, d-only, and common |
| Comment by auto [ 22/Jun/11 ] |
|
Author: {u'login': u'kchodorow', u'name': u'Kristina', u'email': u'kristina@10gen.com'}Message: add auth method for config server connections |
| Comment by Kristina Chodorow (Inactive) [ 25/May/11 ] |
|
This will be for client authentication and authentication between the various cluster components. It will be very similar to how replica set authentication is working currently (http://www.mongodb.org/display/DOCS/Replica+Set+Authentication). mongos' only responsibility will be tracking which connections are authenticated. If a db only exists on one shard, theoretically the user only exists on that shard. As soon as the db migrates chunks, the user will exist on the other shards. This will be completely irrelevant to clients, you will interact with mongos exactly the same way you would with a single server running --auth. |
| Comment by Rasitha Wijesinghe [ 25/May/11 ] |
|
Just to be clear, will this provide client authentication connecting to mongos? Or is this only for authenticating between mongod, configsrv & mongos? Do we have any ideas on how this will be implemented? Since users are defined in each database, I'd think it doesn't make much sense for mongos to do authentication. It should instead pass credentials to the shard or shards when reading/writing data and the shard(s) will take care of authenticating the user. Can there be a situation where a user exists on one shard and not on the other? If yes, is that valid? I'd think if you setup a sharding cluster, mongos should take care of adding a user where it will create the user in all shards where the database is present. When a database/collection gets sharded for the first time, it should also copy users to the new shard. If this the right approach, mongod should reject manual user creations when used in a sharded environment (similar to how a primary works within a replica set). Thoughts? |