[SERVER-6823] Enable Access control without downtime Created: 22/Aug/12  Updated: 05/Apr/18  Resolved: 13/Apr/16

Status: Closed
Project: Core Server
Component/s: Security, Sharding
Affects Version/s: 2.2.0-rc1
Fix Version/s: 3.3.5

Type: New Feature Priority: Major - P3
Reporter: Kay Agahd Assignee: Shane Harvey
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

linux 64 bit


Issue Links:
Depends
is depended on by DOCS-7506 Enable Access control without downtime Closed
Duplicate
is duplicated by SERVER-4268 Authentication Should Support An 'Opp... Closed
is duplicated by SERVER-9895 Support rolling upgrade from no auth ... Closed
is duplicated by SERVER-6953 Allow switching from unauthenticated ... Closed
Related
related to SERVER-24265 Add transitionToAuth option to YAML c... Closed
Backwards Compatibility: Fully Compatible
Sprint: Security 12 (04/01/16), Security 13 (04/22/16)
Participants:
Case:
Linked BF Score: 0

 Description   

In response to https://groups.google.com/forum/?fromgroups=#!topic/mongodb-user/pw2i1v8WiXc

It's not acceptable for me as well to have downtime when switching auth on.

You could solve it this way:
1) Add some auth token to your mongo database(s) using db.addUser("user", "pw"). Since mongo runs still without --keyFile option, mongo should ignore the auth tokens and behave normally.
2) Modify your application so it passes user/pw to mongoDB. Since mongo runs still without --keyFile option AND does not have any ADMIN user, mongo should ignore the auth tokens and behave normally.
3) Restart successively all servers with --keyFile option. Begin with slaves and then stepDown the master, so there is no downtime. ConfigServer and router are redundant so there is no downtime. However, this would require that mongoDB does not yet requires authentication as long as no ADMIN user has been registered.
4) Connect to the router and add an user to the admin database. Now, BOTH conditions (running with --keyFile option AND having at least one admin user) are true, hence mongo should now require authentication.

The advantage of this procedure is also that you could undo very fast mongo's authentication (just by removing the admin user) in case that some mongo clients had not been prepared for authentication or someting else went wrong with authentication.



 Comments   
Comment by Githook User [ 19/May/16 ]

Author:

{u'username': u'ShaneHarvey', u'name': u'Shane Harvey', u'email': u'shane.harvey@mongodb.com'}

Message: SERVER-6823 Enable simultaneous ssl/x509 auth upgrade with only two restarts

Reduce the required number of restarts from three to two by allowing sslMode
allowSSL to be used in combination with transitionToAuth and clusterAuthMode
x509.
Branch: master
https://github.com/mongodb/mongo/commit/aa9fc690ceef10bdbadb433f28fe57aded7e80ba

Comment by Githook User [ 18/Apr/16 ]

Author:

{u'username': u'ShaneHarvey', u'name': u'Shane Harvey', u'email': u'shane.harvey@mongodb.com'}

Message: SERVER-6823 Rename --tryClusterAuth to --transitionToAuth
Branch: master
https://github.com/mongodb/mongo/commit/8432d0bb4809e6547338771a365f3b5340b79024

Comment by Githook User [ 14/Apr/16 ]

Author:

{u'username': u'ShaneHarvey', u'name': u'Shane Harvey', u'email': u'shane.harvey@mongodb.com'}

Message: SERVER-6823 Rolling access control upgrade tests require persistence
Branch: master
https://github.com/mongodb/mongo/commit/6e18b2fb457b93d6d6d37ea3b8c470aa8dcc8817

Comment by Githook User [ 13/Apr/16 ]

Author:

{u'name': u'Shane Harvey', u'email': u'shane.harvey@mongodb.com'}

Message: SERVER-6823 Enable Access control without downtime.

Add --tryClusterAuth flag that enables communicatation between nodes running
with and without auth.
Branch: master
https://github.com/mongodb/mongo/commit/26b55942cc467bca2cc2b935e517b443cf16c550

Comment by Spencer Brody (Inactive) [ 07/Nov/12 ]

SERVER-6897 is addressing the inability to upgrade a 2.0 replica set using auth to a 2.2 replica set using auth without downtime. It has been fixed in 2.2.1.

This ticket is for taking a cluster from running without auth to running with auth. The fix for this has not been scheduled and will probably not make it into 2.4.

Comment by Joel Krauska [ 06/Nov/12 ]

SERVER-6897 seems to be a duplicate of this bug. (or perhaps related – it's implied that this bug might be fixed in 2.4??)

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