En el proceso de desarrollo de las empresas de Internet, a menudo nos encontramos con algunos escenarios que no se consideraron al principio. Después de estar en línea o después de que el servicio haya estado funcionando durante un período de tiempo, encontramos que algunas cosas no se han hecho bien y deben optimizarse y reconstruirse.
Estos escenarios incluyen, la configuración de la contraseña del servicio es demasiado simple (o no está configurada), los datos confidenciales no están insensibilizados (transferidos), el código no tiene suficientes casos de prueba, el servicio diario rompe la vulnerabilidad y necesita ser actualizado y reparado, etc. En el proceso de optimización, todos esperamos lograr un tiempo de inactividad cero y una migración sin problemas, para minimizar el tiempo de impacto del servicio.
Hoy estoy hablando de uno de los escenarios aquí: Mongo implementa el reinicio cero para agregar control de acceso.
Escribir al frente
Este artículo se realiza en Ubuntu: 16.04, versión mongo 3.4
Requisitos: su conjunto de réplicas puede seleccionar un nuevo primario después de los miembros primarios existentes (como el tiempo de inactividad).
El clúster de Mongo realiza cero tiempo de inactividad para agregar "autenticación de identidad". La versión requerida es mongo 3.4 o superior. La razón es que mongo agregó --transitionToAuth parámetros en 3.4 . Este artículo utiliza principalmente este parámetro para lograr cero tiempo de inactividad para la autenticación de actualización.
Aquí tomamos 3 conjuntos de réplicas de nodos como ejemplo.
Crea un administrador de usuarios
userAdminAnyDatabase Usuario vinculado a primario para permiso de creación
admin = db.getSiblingDB ("admin")
admin.createUser (
{
usuario: "yourname1", pwd: "changeme1",
roles: [{role: "userAdminAnyDatabase", db: "admin"}]
}
)
Después de completar este proceso, cualquier cliente que administre usuarios en la colección de réplicas debe autenticarse como ese usuario o un usuario con permisos similares.
Crea un administrador de clúster
Conéctese al nodo principal y cree un clusterAdminusuario con un rol. clusterAdminLos roles otorgan acceso a las operaciones de replicación, como la configuración de conjuntos de réplicas.
db.getSiblingDB ("admin"). createUser (
{"user": "yourname2", "pwd": "changeme2",
roles: [{"role": "clusterAdmin", "db": "admin"}]
}
)
El usuario que creó el enlace de la aplicación cliente.
Cree usuarios para permitir que los programas cliente interactúen con el nivel de réplica. Para completar este paso, el cliente debe vincular el nivel de copia a través de la contraseña de cuenta correspondiente.
Aquí debemos prestar atención al uso de readWritepermisos para operar con los datos. Se recomienda establecer una contraseña más compleja para una base de datos específica (como yourdb) para mejorar la seguridad del sistema. Aquí, se recomienda utilizar 1password para la gestión de generación.
db.getSiblingDB ("yourdb"). createUser (
{"user": "yourname_client", "pwd": "changeme2",
roles: [{"role": "readWrite", "db": "yourdb"}]
}
)
La autenticación del cliente yourdbpuede leerlo y escribirlo.
Actualizar el código de la aplicación cliente
En este paso, el vínculo de nivel de copia no requiere autenticación, pero la aplicación cliente aún puede vincular el nivel de copia a través de la cuenta y contraseña autenticadas.
Aquí asumimos que su conjunto de replia de nivel de copia es yourRepl para pruebas
mongo -u yourname_client -password changeme2 -authenticationDatabase yourdb —host yourRepl / mongo1.example.net: 27017, mongo2.example.net:27017, mongo3.example.net:27017
Puede vincular correctamente, luego actualizar el código del cliente y publicarlo en línea.
Crear archivo de clave
openssl rand -base64 756>
<path-to-keyfile>
chmod 400<path-to-keyfile>
Aquí puede crearlo de cualquier manera, y la complejidad de la contraseña está garantizada por openssl
Se garantiza que el usuario debe mongodbpoder acceder al archivo de claves anterior (se inicia mongod)
A través del método de autenticación de archivo de claves, cada instancia de mongod en el nivel de réplica utilizará el contenido del archivo de claves como contraseña para autenticar a otros miembros. Solo la instancia correcta de mongo con el archivo de claves correcto puede unirse al nivel de réplica.
Luego copie el archivo de claves en cada nivel de copia
Agrega transiciónToAuth y reinicia la instancia
Nota: Antes de reiniciar, asegúrese de que el archivo de configuración tenga la siguiente configuración
security: keyFile: <path-to-keyfile> transitionToAuth: true # Esta configuración es muy importante replicación: replSetName: <replicaSetName>
Reinicie la secundaria o el árbitro primero
sudo service mongod restart
在重启针对primary节点需要
rs.stepDown()
sudo service mongod restart
一个原则，保持primary在线
去掉transitionToAuth，重启实例
注意：在重启之前保证配置文件中有以下配置
security: keyFile: <path-to-keyfile> replication: replSetName: <replicaSetName>
先重启secondary 或arbiter
sudo service mongod restart
重启primary节点需要
rs.stepDown()
sudo service mongod restart
至此所有的集群认证已经添加完毕，所有客户端也需要进行认证才能进行链接。
我们这种「边开飞机，边换引擎」方式到此就已经完成了。