Actualización del clúster fragmentado autogestionado a la autenticación mediante archivo clave (sin tiempo de inactividad)
Overview
Importante
El siguiente procedimiento se aplica a clústeres fragmentados que utilizan MongoDB 3.4 o posterior.
Las versiones anteriores de MongoDB no admiten actualizaciones sin tiempo de inactividad. Para clústeres fragmentados que utilizan versiones anteriores de MongoDB, consulte Actualizar el clúster fragmentado autoadministrado a la autenticación de archivo de claves.
Un clúster fragmentado de MongoDB puede aplicar la autenticación de usuarios, así como la autenticación interna de sus componentes para protegerlos contra el acceso no autorizado.
El siguiente tutorial describe un procedimiento que utiliza
security.transitionToAuth para realizar la transición de un clúster fragmentado existente para aplicar la autenticación sin incurrir en tiempo de inactividad.
Antes de intentar este tutorial, familiarícese con el contenido de este documento.
Considerations
Cloud Manager y Ops Manager
Si utiliza Cloud Manager u Ops Manager para administrar su implementación, consulte Configurar el control de acceso para implementaciones de MongoDB en el manual de Cloud Manager o el manual de Ops Manager para aplicar la autenticación.
Asociación de IP
Los binarios de MongoDB, mongod y, se mongos enlazan a localhost de forma predeterminada.
Mecanismos de autenticación interna y de cliente
Este tutorial configura la autenticación utilizando SCRAM para la autenticación del cliente y un archivo de claves para la autenticación interna.
Consulte la documentación de Autenticación en implementaciones autoadministradas para obtener una lista completa de los mecanismos de autenticación internos y de cliente disponibles.
Arquitectura
Este tutorial supone que cada conjunto de réplicas de fragmentos, así como el conjunto de réplicas del servidor de configuración, pueden elegir un nuevo servidor principal después de reemplazar a su servidor principal existente.
Un conjunto de réplicas puede elegir un primario solo si se cumplen ambas condiciones siguientes:
La mayoría de los miembros del conjunto de réplicas de votación están disponibles después de renunciar a la primaria.
Hay al menos un miembro secundario disponible que no está retrasado, oculto 0 o es Prioritario.
Número mínimo de mongos instancias
Asegúrese de que su clúster fragmentado tenga al menos dos instancias de Mongos disponibles. Este tutorial requiere reiniciar cada mongos del clúster. Si su clúster fragmentado solo tiene una mongos instancia, esto provocará tiempo de inactividad durante el periodo en que la mongos instancia esté desconectada.
Implementar el control de acceso a archivos de claves en un clúster fragmentado existente
Crear y distribuir el archivo de claves
Con la autenticación mediante archivo de claves, cada mongod o mongos instancia del clúster fragmentado utiliza el contenido del archivo de claves como contraseña compartida para autenticar a otros miembros de la implementación. Solo mongod las o instancias con el archivo mongos de claves correcto pueden unirse al clúster fragmentado.
Nota
Los archivos de claves para la autenticación interna de miembros utilizan el formato YAML para permitir múltiples claves en un archivo de claves. El formato YAML acepta:
Una string de clave única (igual que en versiones anteriores)
Una secuencia de cadenas clave
El formato YAML es compatible con los archivos de claves de una sola clave existentes que utilizan el formato de archivo de texto.
La longitud de una clave debe estar entre 6 y 1024 caracteres y solo puede contener caracteres del conjunto base64. Todos los miembros del clúster fragmentado deben compartir al menos una clave común.
Nota
En los sistemas UNIX, el archivo de claves no debe tener permisos de grupo ni de otros. En los sistemas Windows, no se verifican los permisos de los archivos de claves.
Se puede generar un archivo de claves utilizando cualquier método que se elija. Por ejemplo, la siguiente operación utiliza openssl para generar un string de caracteres complejo pseudoaleatorio de 1024 caracteres que se utilizará como contraseña compartida. Luego utiliza chmod para cambiar los permisos del archivo para proporcionar permisos de lectura solo al propietario del archivo:
openssl rand -base64 755 > <path-to-keyfile> chmod 400 <path-to-keyfile>
Copie el archivo de claves en cada servidor que aloje los miembros del clúster fragmentado. Asegúrese de que el usuario que ejecuta las mongod instancias o sea el propietario del archivo y pueda acceder a él.mongos
Evita almacenar el archivo de claves en medios de almacenamiento que puedan desconectarse fácilmente del hardware que aloja las instancias de mongod o mongos, como una unidad USB o un dispositivo de almacenamiento conectado a la red.
Para obtener más información sobre el uso de archivos de claves para la autenticación interna, consulte Archivos de claves.
Configurar Usuario administrador del clúster particionado y usuarios clientes
Debe conectarse a un para completar los pasos de esta sección. Los usuarios creados en estos pasos son usuarios de nivel de clúster y no pueden usarse para acceder a conjuntos de réplicas de fragmentos mongos individuales.
Crear el usuario administrador.
Utilice el método para crear un usuario administrador y asignarle los siguientes db.createUser() roles:
clusterAdminen laadminbase de datosuserAdminroles en laadminbase de datos
Los clientes que realicen operaciones de mantenimiento o administración de usuarios en el clúster fragmentado deben autenticarse con este usuario al finalizar este tutorial. Cree este usuario ahora para garantizar el acceso al clúster después de aplicar la autenticación.
admin = db.getSiblingDB("admin"); admin.createUser( { user: "admin", pwd: "<password>", roles: [ { role: "clusterAdmin", db: "admin" }, { role: "userAdmin", db: "admin" } ] } );
Importante
Las contraseñas deben ser aleatorias, largas y complejas para evitar o dificultar el acceso malicioso.
Opcional: Cree usuarios adicionales para aplicaciones cliente.
Además del usuario administrador, puede crear usuarios adicionales antes de aplicar la autenticación. Esto garantiza el acceso al clúster fragmentado una vez que aplique completamente la autenticación.
Ejemplo
La siguiente operación crea el usuario joe en la marketing base de datos y le asigna el rol en readWrite la marketing base de datos.
db.getSiblingDB("marketing").createUser( { "user": "joe", "pwd": "<password>", "roles": [ { "role" : "readWrite", "db" : "marketing" } ] } )
Los clientes que se autentican como "joe" pueden realizar operaciones de lectura y escritura en la base de datos marketing.
Consulte Roles de usuario de la base de datos para conocer los roles proporcionados por MongoDB.
Consulta el tutorial "Añadir usuarios"para obtener más información sobre cómo añadir usuarios. Ten en cuenta las prácticas recomendadas de seguridad al añadir nuevos usuarios.
Opcional: actualice las aplicaciones cliente para especificar las credenciales de autenticación.
Aunque el clúster fragmentado no aplica actualmente la autenticación, puede actualizar las aplicaciones cliente para que especifiquen las credenciales de autenticación al conectarse al clúster. Esto puede evitar la pérdida de conectividad al finalizar este tutorial.
Ejemplo
La siguiente operación se conecta al clúster fragmentado mediante mongosh joe marketing y se autentica como el usuario en la base de datos.
mongosh --username "joe" --password "<password>" \ --authenticationDatabase "marketing" --host mongos1.example.net:27017
Si su aplicación utiliza un controlador MongoDB, consulte la documentación del controlador asociado para obtener instrucciones sobre cómo crear una conexión autenticada.
Transición de cada mongos instancia para aplicar la autenticación
Cree un nuevo mongos archivo de configuración.
Para mongos cada:
Copie el
mongosarchivo de configuración existente y asígnele un nombre distintivo, como<filename>-secure.conf(o.cfgsi usa Windows). Utilizará este nuevo archivo de configuración para la transición de y aplicarmongosla autenticación en el clúster fragmentado. Conserve el archivo de configuración original como copia de seguridad.Al nuevo archivo de configuración, agregue las siguientes configuraciones:
security.transitionToAuthfijar entruesecurity.keyFileestablecer en la ruta del archivo clave.Si utiliza un mecanismo de autenticación interna diferente, especifique la configuración adecuada para el mecanismo.
security: transitionToAuth: true keyFile: <path-to-keyfile> El nuevo archivo de configuración debe contener todas las configuraciones utilizadas anteriormente por, así como las nuevas configuraciones de
mongosseguridad.
Uno a la vez, reinicie el mongos con el nuevo archivo de configuración.
Nota
Siga el procedimiento para reiniciar la mongos instancia, una a la mongos vez:
Conéctese al para
mongosapagar.Utilice el método contra
db.shutdownServer()laadminbase de datos para apagar de forma seguramongosel.db.getSiblingDB("admin").shutdownServer() Reiniciar
mongoscon el nuevo archivo de configuración, especificando la ruta al archivo de configuración usando--config. Por ejemplo, si el nuevo archivo de configuración se llamaramongos-secure.conf:mongos --config <path>/mongos-secure.conf donde
<path>representa la ruta del sistema a la carpeta que contiene el nuevo archivo de configuración.
Repetí el proceso de reinicio para la siguiente instancia mongos hasta que todas las instancias mongos en el clúster fragmentado hayan sido reiniciadas.
Al final de esta sección, todas las instancias del clúster mongos security.transitionToAuth security.keyFile fragmentado se ejecutan con autenticación interna y.
Miembros del conjunto de réplicas del servidor de configuración de transición para aplicar la autenticación
Cree un nuevo mongod archivo de configuración.
Para cada en el conjunto de réplicas del servidor de mongod configuración,
Copie el
mongodarchivo de configuración existente y asígnele un nombre distintivo, como<filename>-secure.conf(o.cfgsi usa Windows). Utilizará este nuevo archivo de configuración para la transición de y aplicarmongodla autenticación en el clúster fragmentado. Conserve el archivo de configuración original como copia de seguridad.Al nuevo archivo de configuración, agregue las siguientes configuraciones:
security.transitionToAuthfijar entruesecurity.keyFileestablecer en la ruta del archivo clave.Si utiliza un mecanismo de autenticación interna diferente, especifique la configuración adecuada para el mecanismo.
security: transitionToAuth: true keyFile: <path-to-keyfile>
Uno a la vez, reinicie el mongod con el nuevo archivo de configuración.
Reinicie el conjunto de réplicas, un miembro a la vez, comenzando con los miembros secundarios.
Para reiniciar los miembros secundarios uno a la vez,
Conéctese al
mongody utilice el método contradb.shutdownServer()laadminbase de datos para apagar de forma seguramongodel.db.getSiblingDB("admin").shutdownServer() Reinicie
mongodcon el nuevo archivo de configuración, especificando la ruta del archivo con--config. Por ejemplo, si el nuevo archivo de configuración se llamaramongod-secure.conf:mongod --config <path>/mongod-secure.conf donde
<path>representa la ruta del sistema a la carpeta que contiene el nuevo archivo de configuración.
Una vez que este miembro esté levantado, repita el procedimiento para el siguiente miembro secundario.
Una vez que todos los miembros secundarios se hayan reiniciado y estén en funcionamiento, reinicie el primario:
Conectarse
mongodal.Utilice el método para retirar las primarias y activar una
rs.stepDown()elección.rs.stepDown() Puede utilizar el método para asegurarse de que el conjunto de réplicas haya elegido un nuevo servidor
rs.status()principal.Una vez que se haya eliminado la primaria y se haya elegido una nueva, cierre la primaria anterior utilizando el método contra
db.shutdownServer()laadminbase de datos.db.getSiblingDB("admin").shutdownServer() Reinicie
mongodcon el nuevo archivo de configuración, especificando la ruta del archivo con--config. Por ejemplo, si el nuevo archivo de configuración se llamaramongod-secure.conf:mongod --config <path>/mongod-secure.conf donde
<path>representa la ruta del sistema a la carpeta que contiene el nuevo archivo de configuración.
Al final de esta sección, todas las mongod instancias en el conjunto de réplicas del servidor de configuración se ejecutan con security.transitionToAuth security.keyFile autenticación interna y.
Transición de cada miembro del conjunto de réplicas de fragmentos para aplicar la autenticación
Crear el administrador local del fragmento
En un clúster fragmentado que aplica autenticación, cada conjunto de réplicas de fragmentos debe tener su propio administrador local. No se puede usar un administrador local para que un fragmento acceda a otro fragmento ni al clúster fragmentado.
Conéctese al miembro principal de cada conjunto de réplicas de fragmentos y cree un usuario con el método, asignándole los siguientes db.createUser() roles:
clusterAdminen laadminbase de datosuserAdminroles en laadminbase de datos
Tip
Puede usar el método junto con varios métodos o comandos de autenticación/gestión de usuarios para solicitar la contraseña en lugar de especificarla directamente en la llamada al método/comando. Sin embargo, puede especificarla directamente como lo hacía con versiones anteriores passwordPrompt() del mongo shell.
admin = db.getSiblingDB("admin") admin.createUser( { user: "admin", pwd: passwordPrompt(), // or cleartext password roles: [ { role: "clusterAdmin", db: "admin" }, { role: "userAdmin", db: "admin" } ] } )
Al finalizar este tutorial, si deseas conectarte a la partición para realizar operaciones de mantenimiento que requieran una conexión directa a una partición, debes autenticarte como administrador local de la partición.
Nota
Las conexiones directas a un fragmento solo deben realizarse para el mantenimiento y la configuración específicos del fragmento. En general, los clientes deben conectarse al clúster fragmentado a través mongos de.
Procedimiento
Para realizar la transición de un conjunto de réplicas de fragmentos a la vez, repita estos pasos para cada conjunto de réplicas de fragmentos en el clúster fragmentado.
Cree un nuevo mongod archivo de configuración.
Para cada en el conjunto de réplicas de mongod fragmentos,
Copie el
mongodarchivo de configuración existente y asígnele un nombre distintivo, como<filename>-secure.conf(o.cfgsi usa Windows). Utilizará este nuevo archivo de configuración para la transición de y aplicarmongodla autenticación en el clúster fragmentado. Conserve el archivo de configuración original como copia de seguridad.Al nuevo archivo de configuración, agregue las siguientes configuraciones:
security.transitionToAuthfijar entruesecurity.keyFileestablecer en la ruta del archivo clave.Si utiliza un mecanismo de autenticación interna diferente, especifique la configuración adecuada para el mecanismo.
security: transitionToAuth: true keyFile: <path-to-keyfile>
Uno a la vez, reinicie el mongod con el nuevo archivo de configuración.
Reinicie el conjunto de réplicas, un miembro a la vez, comenzando con los miembros secundarios.
Para reiniciar los miembros secundarios uno a la vez,
Conéctese al
mongody utilice el método contradb.shutdownServer()laadminbase de datos para apagar de forma seguramongodel.db.getSiblingDB("admin").shutdownServer() Reinicie
mongodcon el nuevo archivo de configuración, especificando la ruta del archivo con--config. Por ejemplo, si el nuevo archivo de configuración se llamaramongod-secure.conf:mongod --config <path>/mongod-secure.conf donde
<path>representa la ruta del sistema a la carpeta que contiene el nuevo archivo de configuración.
Una vez que este miembro esté activo, repita el procedimiento para el siguiente miembro secundario del conjunto de réplicas hasta que se hayan actualizado todos los secundarios.
Una vez que todos los miembros secundarios se hayan reiniciado y estén en funcionamiento, reinicie el primario:
Conectarse
mongodal.Utilice el método para retirar las primarias y activar una
rs.stepDown()elección.rs.stepDown() Puede utilizar el método para asegurarse de que el conjunto de réplicas haya elegido un nuevo servidor
rs.status()principal.Una vez que se haya eliminado la primaria y se haya elegido una nueva, cierre la primaria anterior utilizando el método contra
db.shutdownServer()laadminbase de datos.db.getSiblingDB("admin").shutdownServer() Reinicie
mongodcon el nuevo archivo de configuración, especificando la ruta del archivo con--config. Por ejemplo, si el nuevo archivo de configuración se llamaramongod-secure.conf:mongod --config <path>/mongod-secure.conf donde
<path>representa la ruta del sistema a la carpeta que contiene el nuevo archivo de configuración.
En este punto del tutorial, todos los componentes del clúster fragmentado se ejecutan con --transitionToAuth security.keyFile autenticación interna y. El clúster fragmentado tiene al menos un usuario administrativo, y cada conjunto de réplicas de fragmentos tiene un usuario administrativo local.
Las secciones restantes implican sacar el clúster fragmentado del estado de transición para aplicar completamente la autenticación.
Reiniciar cada mongos instancia sin transitionToAuth
Importante
Al final de esta sección, los clientes deben especificar las credenciales de autenticación para conectarse al clúster fragmentado. Actualice las credenciales de autenticación de los clientes antes de completar esta sección para evitar la pérdida de conectividad.
Para completar la transición hacia la aplicación total de la autenticación en el clúster fragmentado, debe reiniciar cada instancia mongos security.transitionToAuth sin la configuración.
Remover transitionToAuth de los archivos de configuración mongos.
Elimine la security.transitionToAuth clave y su valor de los mongos archivos de configuración creados durante este tutorial. Conserve la configuración agregada en el security.keyFile tutorial.
security: keyFile: <path-to-keyfile>
Reinicie el mongos con el archivo de configuración actualizado.
Nota
Siga el procedimiento para reiniciar mongos instancias, una a la mongos vez:
Conéctese al para
mongosapagar.Utilice el método contra
db.shutdownServer()laadminbase de datos para apagar de forma seguramongosel.db.getSiblingDB("admin").shutdownServer() Reinicie
mongoscon el archivo de configuración actualizado, especificando la ruta al archivo de configuración con--config. Por ejemplo, si el archivo de configuración actualizado se llamaramongos-secure.conf:mongos --config <path>/mongos-secure.conf
Al final de esta sección, todas las instancias aplican la autenticación mongos security.keyFile del cliente y la autenticación interna.
Reinicie cada miembro del conjunto de réplicas del servidor de configuración sin transitionToAuth
Importante
Al finalizar este paso, los clientes deben especificar las credenciales de autenticación para conectarse al conjunto de réplicas del servidor de configuración. Actualice a los clientes para que especifiquen las credenciales de autenticación antes de completar esta sección para evitar la pérdida de conectividad.
Para completar la transición hacia la aplicación total de la autenticación en el clúster fragmentado, debe reiniciar cada instancia mongod security.transitionToAuth sin la configuración.
Remover transitionToAuth de los archivos de configuración mongod.
Elimine la security.transitionToAuth clave y su valor de los archivos de configuración del servidor creados durante este tutorial. Conserve la configuración agregada en el security.keyFile tutorial.
security: keyFile: <path-to-keyfile>
Uno a la vez, reinicie el mongod con el archivo de configuración actualizado.
Reinicie el conjunto de réplicas, un miembro a la vez, comenzando con los miembros secundarios.
Para reiniciar los miembros secundarios uno a la vez,
Conéctese al
mongody utilice el método contradb.shutdownServer()laadminbase de datos para apagar de forma seguramongodel.db.getSiblingDB("admin").shutdownServer() Reinicie
mongodcon el archivo de configuración actualizado, especificando la ruta del archivo de configuración con--config. Por ejemplo, si el nuevo archivo de configuración se llamaramongod-secure.conf:mongod --config <path>/mongod-secure.conf donde
<path>representa la ruta del sistema a la carpeta que contiene el archivo de configuración actualizado.
Una vez que este miembro esté levantado, repita el procedimiento para el siguiente miembro secundario.
Una vez que todos los miembros secundarios se hayan reiniciado y estén en funcionamiento, reinicie el primario:
Conectarse
mongodal.Utilice el método para retirar las primarias y activar una
rs.stepDown()elección.rs.stepDown() Puede utilizar el método para asegurarse de que el conjunto de réplicas haya elegido un nuevo servidor
rs.status()principal.Una vez que se haya eliminado la primaria y se haya elegido una nueva, cierre la primaria anterior utilizando el método contra
db.shutdownServer()laadminbase de datos.db.getSiblingDB("admin").shutdownServer() Reinicie
mongodcon el archivo de configuración actualizado, especificando la ruta del archivo de configuración con--config. Por ejemplo, si el nuevo archivo de configuración se llamaramongod-secure.conf:mongod --config <path>/mongod-secure.conf donde
<path>representa la ruta del sistema a la carpeta que contiene el archivo de configuración actualizado.
Al final de esta sección, todas las mongod instancias en el conjunto de réplicas del servidor de configuración aplican la autenticación del cliente y la autenticación security.keyFile interna.
Reiniciar cada miembro en cada conjunto de réplicas de fragmentos sin transitionToAuth
Importante
Al finalizar este paso, los clientes deben especificar las credenciales de autenticación para conectarse al conjunto de réplicas de fragmentos. Actualice las credenciales de autenticación de los clientes antes de completar esta sección para evitar la pérdida de conectividad.
Para completar la transición hacia la aplicación total de la autenticación en el clúster fragmentado, debe reiniciar cada miembro de cada conjunto de réplicas de fragmentos en el clúster fragmentado sin la security.transitionToAuth configuración.
Para realizar la transición de un conjunto de réplicas de fragmentos a la vez, repita estos pasos para cada conjunto de réplicas de fragmentos en el clúster fragmentado.
Remover transitionToAuth de los archivos de configuración mongod.
Elimine la security.transitionToAuth clave y su valor de los archivos de configuración del servidor creados durante este tutorial. Conserve la configuración agregada en el security.keyFile tutorial.
security: keyFile: <path-to-keyfile>
Uno a la vez, reinicie el mongod con el archivo de configuración actualizado.
Reinicie el conjunto de réplicas, un miembro a la vez, comenzando con los miembros secundarios.
Para reiniciar los miembros secundarios uno a la vez,
Conéctese al
mongody utilice el método contradb.shutdownServer()laadminbase de datos para apagar de forma seguramongodel.db.getSiblingDB("admin").shutdownServer() Reinicie
mongodcon el archivo de configuración actualizado, especificando la ruta del archivo de configuración con--config. Por ejemplo, si el nuevo archivo de configuración se llamaramongod-secure.conf:mongod --config <path>/mongod-secure.conf donde
<path>representa la ruta del sistema a la carpeta que contiene el archivo de configuración actualizado.
Una vez que este miembro esté levantado, repita el procedimiento para el siguiente miembro secundario.
Una vez que todos los miembros secundarios se hayan reiniciado y estén en funcionamiento, reinicie el primario:
Conectarse
mongodal.Utilice el método para retirar las primarias y activar una
rs.stepDown()elección.rs.stepDown() Puede utilizar el método para asegurarse de que el conjunto de réplicas haya elegido un nuevo servidor
rs.status()principal.Una vez que se haya eliminado la primaria y se haya elegido una nueva, cierre la primaria anterior utilizando el método contra
db.shutdownServer()laadminbase de datos.db.getSiblingDB("admin").shutdownServer() Reinicie
mongodcon el archivo de configuración actualizado, especificando la ruta del archivo de configuración con--config. Por ejemplo, si el nuevo archivo de configuración se llamaramongod-secure.conf:mongod --config <path>/mongod-secure.conf donde
<path>representa la ruta del sistema a la carpeta que contiene el archivo de configuración actualizado.
Al final de esta sección, todas las mongos instancias y mongod del clúster fragmentado aplican la autenticación de cliente y la security.keyFile autenticación interna. Los clientes solo pueden conectarse al clúster fragmentado mediante el mecanismo de autenticación de cliente configurado. Los componentes adicionales solo pueden unirse al clúster especificando el archivo de claves correcto.
Autenticación interna del certificado X.509
MongoDB admite509 la autenticación con certificados X. para su uso con una conexión TLS/SSL segura. Los miembros del clúster fragmentado y del conjunto de réplicas pueden usar509 certificados X. para verificar su pertenencia al clúster o al conjunto de réplicas en lugar de usar archivos de claves.
Para obtener detalles sobre el uso de509 certificados X. para la autenticación interna, consulte Usar509 el certificado X. para la autenticación de membresía con MongoDB autoadministrado.
Actualizar MongoDB autoadministrado509 de la autenticación de archivo de claves a la autenticación X. describe cómo actualizar el mecanismo de autenticación interno de una implementación de la autenticación basada en archivo de claves a509 la autenticación basada en certificado X..