In the development process of Internet companies, we often encounter some scenarios that were not considered at the beginning. After going online or after the service has been running for a period of time, we find that some things have not been done well and need to be optimized and reconstructed.
These scenarios include, some service password configuration is too simple (or not configured), sensitive data is not desensitized (transferred), the code does not have enough test cases, the daily service breaks out the vulnerability and needs to be upgraded and repaired, etc. In the optimization process, we all hope to achieve zero downtime and smooth migration, so as to minimize the service impact time.
Today I am talking about one of the scenarios here. Mongo implements zero restart to add access control.
Write in front
This article is conducted on Ubuntu: 16.04, mongo 3.4 version
Requirements: Your replica set can select a new primary after the existing primary members (such as downtime).
Mongo cluster realizes zero downtime to add "identity authentication". The required version is mongo 3.4 or higher. The reason is that mongo added --transitionToAuth parameters in 3.4 . This article mainly uses this parameter to achieve zero downtime for upgrade authentication.
Here we take 3 node replica sets as an example.
Create a user administrator
userAdminAnyDatabase User linked to primary for creation permission
admin = db.getSiblingDB("admin")
admin.createUser(
{
user: "yourname1", pwd: "changeme1",
roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
}
)
After completing this process, any client that manages users in the replica set must authenticate as that user, or a user with similar permissions.
Create a cluster administrator
Connect to the primary node and create a clusterAdminuser with a role. clusterAdminRoles grant access to replication operations, such as configuring replica sets.
db.getSiblingDB("admin").createUser(
{ "user" : "yourname2", "pwd" : "changeme2",
roles: [ { "role" : "clusterAdmin", "db" : "admin" } ]
}
)
The user who created the client application link
Create users to allow client programs to interact with the replica level. To complete this step, the client needs to link the copy level through the corresponding account password.
Here we need to pay attention to the use of readWritepermissions to operate on the data. It is recommended to set a more complicated password for a specific database (such as yourdb) to enhance system security. Here, it is recommended to use 1password for generation management.
db.getSiblingDB("yourdb").createUser(
{ "user" : "yourname_client", "pwd" : "changeme2",
roles: [ { "role" : "readWrite", "db" : "yourdb" } ]
}
)
Client authentication yourdbcan read and write it.
Update client application code
In this step, the copy-level link does not require authentication, but the client application can still link to the copy-level through the authenticated account and password.
Here we assume that your copy-level replia set is yourRepl for testing
mongo -u yourname_client -password changeme2 -authenticationDatabase yourdb —host yourRepl/mongo1.example.net:27017, mongo2.example.net:27017, mongo3.example.net:27017
You can link successfully, then update the client code and release it online.
Create key file
openssl rand -base64 756>
<path-to-keyfile>
chmod 400<path-to-keyfile>
Here you can create it in any way, and the password complexity is guaranteed by openssl
It is guaranteed that the above keyfile needs to mongodbbe accessible by users (you start mongod)
Through the keyfile authentication method, each mongod instance in the replica level will use the content of the keyfile as a password to authenticate other members. Only the correct mongo instance with the correct keyfile can be added to the replica level.
Then copy the keyfile to each copy level
Add transitionToAuth and restart the instance
Note: Before restarting, ensure that the configuration file has the following configuration
security: keyFile: <path-to-keyfile> transitionToAuth: true # This configuration is very important replication: replSetName: <replicaSetName>
Restart secondary or arbiter first
sudo service mongod restart
Need to restart for the primary node
rs.stepDown()
sudo service mongod restart
A principle to keep the primary online
Remove transitionToAuth and restart the instance
Note: Before restarting, ensure that the configuration file has the following configuration
security: keyFile: <path-to-keyfile> replication: replSetName: <replicaSetName>
Restart secondary or arbiter first
sudo service mongod restart
Need to restart the primary node
rs.stepDown()
sudo service mongod restart
至此所有的集群认证已经添加完毕，所有客户端也需要进行认证才能进行链接。
我们这种「边开飞机，边换引擎」方式到此就已经完成了。