[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: File map_reduce_test.rb     Zip Archive shardsvr2.zip    
Issue Links:
Depends
depends on SERVER-1469 replica sets should use global privat... Closed
Related
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
Tue Dec 13 22:17:54 [conn5] ERROR: Uncaught std::exception: could not initialize cursor across all shards because : unauthorized db:XXXX

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 SERVER-921
Branch: master
https://github.com/mongodb/mongo/commit/9e5a8a53d334082015e66274aa87f39a3b52c59a

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 SERVER-921
Branch: master
https://github.com/mongodb/mongo/commit/09d1825d7f599724739ee712c8b91bfb566ea607

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 SERVER-921
Branch: master
https://github.com/mongodb/mongo/commit/67945f8b00d6e3cad4eaace5ee8f3cd9a6a71dde

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 SERVER-921
Branch: master
https://github.com/mongodb/mongo/commit/d9cec7a4805364b5266a6fed914958998fc0d9b7

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?

Generated at Thu Feb 08 02:55:32 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.