Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home
/ /
Interno
/ / / / /

Actualizar el conjunto de réplicas autogestionadas para la autenticación de archivo de claves (sin tiempo de inactividad)

Para proteger contra accesos no autorizados, implemente Autenticación para sus implementaciones. La autenticación para conjuntos de réplicas consiste en la autenticación interna entre los miembros del conjunto y el control de acceso de los usuarios para los clientes que se conectan a él.

Si su implementación actualmente no exige la autenticación, puede usar el --transitionToAuth Opción para aplicar la autenticación sin tiempo de inactividad.

Este tutorial utiliza el mecanismo de autenticación interna keyfile para la seguridad interna y los roles basados en control de accesobasados en SCRAM para conexiones de clientes.

Si usas Cloud Manager u Ops Manager para gestionar tu implementación, consulta el respectivo manual de Cloud Manager o el manual de Ops Manager para aplicar la autenticación.

Este tutorial asume que su conjunto de réplicas puede elegir un nuevo miembro principal tras reemplazar al miembro principal existente. Esto requiere:

  • La mayoría de los miembros con derecho a voto del set de réplicas están disponibles después de retirarse del primario.

  • Al menos un miembro secundario que no sea retrasado, oculto o Prioridad 0.

Un mongod que --transitionToAuth se ejecuta con acepta conexiones autenticadas y no autenticadas. Los clientes conectados al durante este estado de transición pueden realizar operaciones de lectura, escritura y administración en cualquier base de mongod datos.

Al final del siguiente procedimiento, el set de réplicas rechazará cualquier cliente que intente establecer una conexión no autenticada. El procedimiento crea usuarios para aplicaciones clientes que utilicen al conectarse al set de réplicas.

Consulte ➤ Configurar el control de acceso basado en roles para conocer las mejores prácticas de creación y administración de usuarios.

Los binarios de MongoDB, mongod y mongos, se enlazan a localhost por defecto.

Importante

Las contraseñas deben ser aleatorias, largas y complejas para garantizar la seguridad del sistema y para prevenir o retrasar el acceso malicioso.

Importante

Para evitar actualizaciones de configuración debido a cambios en las direcciones IP, utilice nombres de host DNS en lugar de direcciones IP. Es particularmente importante usar un nombre de host DNS en lugar de una dirección IP al configurar miembros de set de réplicas o miembros de clústeres particionados.

Utiliza nombres de host en lugar de direcciones IP para configurar clústeres en un horizonte de red dividido. A partir de MongoDB 5.0, los nodos que solo están configurados con una dirección IP no pasan la validación de inicio y no se inician.

1

Conéctese a la base de datos principal para crear un usuario con userAdminAnyDatabase el rol. El userAdminAnyDatabase rol otorga acceso a la creación de usuarios en cualquier base de datos de la implementación.

El siguiente ejemplo crea al usuario fred con el rol userAdminAnyDatabase en la base de datos admin.

Importante

Las contraseñas deben ser aleatorias, largas y complejas para garantizar la seguridad del sistema y para prevenir o retrasar el acceso malicioso.

Tip

Puedes utilizar el método passwordPrompt() junto con varios métodos/comandos de autenticación/gestión de usuarios para solicitar la contraseña en lugar de especificarla directamente en la llamada del método/comando. Sin embargo, todavía puedes especificar la contraseña directamente como lo harías con versiones anteriores del shell de mongo.

admin = db.getSiblingDB("admin")
admin.createUser(
{
user: "fred",
pwd: " passwordPrompt(), // or cleartext password
roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
}
)

Al completar este procedimiento, cualquier cliente que administre usuarios en el set de réplicas debe autenticarse como este usuario, o como un usuario con permisos similares.

Consulta Roles de usuario de base de datos para obtener una lista completa de roles integrados y relacionados con las operaciones de administración de bases de datos.

2

Conéctate al primario para crear un usuario con el rol de clusterAdmin. El clusterAdmin rol otorga acceso a las operaciones de replicación, como la configuración del set de réplicas.

El siguiente ejemplo crea al usuario ravi con el rol clusterAdmin en la base de datos admin.

Importante

Las contraseñas deben ser aleatorias, largas y complejas para garantizar la seguridad del sistema y para prevenir o retrasar el acceso malicioso.

Tip

Puedes utilizar el método passwordPrompt() junto con varios métodos/comandos de autenticación/gestión de usuarios para solicitar la contraseña en lugar de especificarla directamente en la llamada del método/comando. Sin embargo, todavía puedes especificar la contraseña directamente como lo harías con versiones anteriores del shell de mongo.

db.getSiblingDB("admin").createUser(
{
"user" : "ravi",
"pwd" : passwordPrompt(), // or cleartext password
roles: [ { "role" : "clusterAdmin", "db" : "admin" } ]
}
)

Al finalizar este procedimiento, cualquier cliente que administre o mantenga el set de réplicas debe autenticarse como este usuario, o un usuario con permisos similares.

Consulta Roles de administración del clúster para obtener una lista completa de los roles incorporados relacionados con las operaciones del set de réplicas.

3

Cree usuarios para permitir que la aplicación cliente se conecte e interactúe con el set de réplicas. Al finalizar este tutorial, los clientes deben autenticarse como un usuario configurado para conectarse al set de réplicas.

Consultar Roles de usuario de base de datos para roles básicos incorporados que se pueden utilizar en la creación de usuarios de solo lectura y lectura-escritura.

Lo siguiente crea un usuario con permisos de lectura y guardar en la base de datos foo.

Importante

Las contraseñas deben ser aleatorias, largas y complejas para garantizar la seguridad del sistema y para prevenir o retrasar el acceso malicioso.

Crear un usuario con el rol readWrite en la base de datos foo.

Tip

Puedes utilizar el método passwordPrompt() junto con varios métodos/comandos de autenticación/gestión de usuarios para solicitar la contraseña en lugar de especificarla directamente en la llamada del método/comando. Sin embargo, todavía puedes especificar la contraseña directamente como lo harías con versiones anteriores del shell de mongo.

db.getSiblingDB("foo").createUser(
{
"user" : "joe",
"pwd" : passwordPrompt(), // or cleartext password
roles: [ { "role" : "readWrite", "db" : "foo" } ]
}
)

Los clientes que se autentican como este usuario pueden realizar operaciones de lectura y escritura en la base de datos foo. Consulta Autenticar a un usuario con implementaciones autogestionadas para obtener más información sobre cómo crear una conexión autenticada al set de réplicas.

Consulta el tutorial Agregar Usuarios para obtener más información sobre cómo añadir usuarios. Considera las mejores prácticas de seguridad al agregar nuevos usuarios.

4

En este punto del procedimiento, el set de réplicas no aplica la autenticación. Sin embargo, las aplicaciones cliente aún pueden especificar credenciales de autenticación y conectarse al set de réplicas.

Actualice las aplicaciones cliente para autenticarse con el set de réplicas utilizando un usuario configurado. Las conexiones autenticadas requieren un nombre de usuario, una contraseña y la base de datos de autenticación. Consulta Autenticar a un usuario mediante implementaciones autogestionadas.

Por ejemplo, la siguiente se conecta a un set de réplicas llamado mongoRepl y se autentica como el usuario joe.

mongosh -u joe -password -authenticationDatabase foo --host mongoRepl/mongo1.example.net:27017, mongo2.example.net:27017, mongo3.example.net:27017

Si no especificas la contraseña para la opción de línea de comandos -p, mongosh solicita la contraseña.

Si tu aplicación utiliza un controlador de MongoDB, consulta la documentación del controlador asociado para obtener instrucciones sobre cómo crear una conexión autenticada.

Al finalizar este tutorial, el set de réplicas rechaza las conexiones de clientes no autenticados. Realizar este paso garantiza ahora que los clientes puedan conectarse al set de réplicas antes y después de la transición.

5

Con la autenticación keyfile, cada instanciasmongod del set de réplicas utiliza el contenido del keyfile como contraseña compartida para autenticar a otros miembros en la implementación. Solo mongod instancias con el archivo de clave correcto pueden unirse al set de réplicas.

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 set de réplicas 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 756 > <path-to-keyfile>
chmod 400 <path-to-keyfile>

Consultar Keyfiles para obtener más información y requisitos para el uso de los keyfiles.

6

Copia el archivo de claves en cada servidor que aloje a los miembros del Set de réplicas. Asegúrate de que el usuario que ejecuta las instancias de mongod sea el propietario del archivo y pueda acceder al archivo de claves.

Evitar almacenar el archivo de claves en medios de almacenamiento que puedan desconectarse fácilmente del hardware que aloja las instancias de mongod, como una unidad USB o un dispositivo de almacenamiento conectado a la red.

7

Reinicia cada secundario o árbitro en el set de réplicas, incluyendo en la configuración:

Debes reiniciar cada nodo uno a la vez para asegurar que la mayoría de los nodos del conjunto de réplicas permanezcan en línea.

Desde una sesión mongosh conectada al secundario o árbitro, emite el db.shutdownServer() contra la base de datos admin.

admin = db.getSiblingDB("admin")
admin.shutdownServer()

Especifica la siguiente configuración en tu archivo de configuración.

mongod y mongos se vinculan a localhost por defecto. Si los nodos de su implementación se ejecutan en distintos hosts o si desea que clientes remotos se conecten a su implementación, debe especificar el ajuste net.bindIp.

security:
keyFile: <path-to-keyfile>
transitionToAuth: true
replication:
replSetName: <replicaSetName>

Especifique la opción --config con la ruta al archivo de configuración al iniciar el mongod.

mongod --config <path-to-config-file>

Para obtener más información sobre el archivo de configuración, consultar opciones del archivo de configuración.

Alternativamente, puedes utilizar las opciones de línea de comandos equivalentes mongod (por ejemplo, --transitionToAuth y --keyFile) al iniciar tu mongod. Consulta la mongod página de referencia para obtener una lista completa de las opciones.

Incluye configuraciones adicionales según corresponda para tu implementación.

Al finalizar este paso, todos los secundarios y árbitros deberían estar en funcionamiento con security.transitionToAuth configurados en true.

8

Reducir a un primario en el set de réplicas y reinicie el nodo, incluso en su configuración:

Conéctese al primario utilizando mongosh y degrade el primario utilizando el método rs.stepDown().

rs.stepDown()

Una vez que el primario se retira y el set de réplicas elige un nuevo primario, apague el antiguo primario mongod.

Desde una mongosh sesión que esté conectada a la antigua principal, ejecuta el db.shutdownServer() en la base de datos admin.

admin = db.getSiblingDB("admin")
admin.shutdownServer()

Especifica la siguiente configuración en tu archivo de configuración.

Incluye opciones adicionales según sea necesario para la configuración. Por ejemplo, si se desea que los clientes remotos se conecten a la implementación o si los miembros de la implementación se ejecutan en diferentes hosts, se debe especificar la configuración net.bindIp.

security:
keyFile: <path-to-keyfile>
transitionToAuth: true
replication:
replSetName: <replicaSetName>

Inicie el mongod utilizando el archivo de configuración.

mongod --config <path-to-config-file>

Para obtener más información sobre el archivo de configuración, consultar opciones del archivo de configuración.

Alternativamente, puedes utilizar las opciones de línea de comandos equivalentes mongod (por ejemplo, --transitionToAuth y --keyFile) al iniciar tu mongod. Consulta la mongod página de referencia para obtener una lista completa de las opciones.

Incluye configuraciones adicionales según corresponda para tu implementación.

Al final de este paso, todos los miembros del conjunto de réplicas deben estar en funcionamiento con establecido security.transitionToAuth en true y security.keyFile establecido en la ruta del archivo clave.

9

Reinicie cada nodo secundario o árbitro en el set de réplicas, removiendo la opción security.transitionToAuth al reiniciar. Debes hacer esto uno a la vez para asegurarte de que la mayoría de los miembros del set de réplicas permanezcan en línea.

Si la mayoría de los miembros del conjunto de réplicas están fuera de línea al mismo tiempo, el conjunto de réplicas puede pasar al modo de solo lectura.

Conecte mongosh al secundario o árbitro, y emita db.shutdownServer() en la base de datos admin.

admin = db.getSiblingDB("admin")
admin.shutdownServer()

Reinicie el,mongod esta vez sin la security.transitionToAuth opción pero con un mecanismo de autenticación interno security.keyFile como.

Especifica la siguiente configuración en tu archivo de configuración.

Incluye opciones adicionales según sea necesario para la configuración. Por ejemplo, si se desea que los clientes remotos se conecten a la implementación o si los miembros de la implementación se ejecutan en diferentes hosts, se debe especificar la configuración net.bindIp.

security:
keyFile: <path-to-keyfile>
replication:
replSetName: <replicaSetName>

Inicia la mongod usando el archivo de configuración:

mongod --config <path-to-config-file>

Para obtener más información sobre el archivo de configuración, consultar opciones del archivo de configuración.

También puede usar las mongod opciones equivalentes al iniciar su.mongod Consulte la página de referencia para obtener una lista completa de opciones.mongod

Incluye configuraciones adicionales según corresponda para tu implementación.

Al finalizar este paso, todos los secundarios y árbitros deberían estar en funcionamiento con la autenticación interna configurada, pero security.transitionToAuthsin. Los clientes solo pueden conectarse a estas mongod instancias mediante el mecanismo de autenticación de cliente configurado.

10

Despromociona al miembro principal en el set de réplicas y luego reinícialo sin la opción security.transitionToAuth.

Importante

Al finalizar este paso, los clientes que no se conectan con autenticación no podrán conectarse al conjunto de réplicas. Actualice los clientes para que se conecten con autenticación antes de completar este paso para evitar la pérdida de conectividad.

Conéctese al primario utilizando mongosh y degrade el primario utilizando el método rs.stepDown().

rs.stepDown()

Una vez que el primario se retira y el set de réplicas elige un nuevo primario, apague el antiguo primario mongod.

Desde una mongosh sesión que esté conectada a la antigua principal, ejecuta el db.shutdownServer() en la base de datos admin.

admin = db.getSiblingDB("admin")
admin.shutdownServer()

Reinicie el,mongod esta vez sin la security.transitionToAuth opción pero con el mecanismo de autenticación interno security.keyFile como.

Especifica la siguiente configuración en tu archivo de configuración.

security:
keyFile: <path-to-keyfile>
replication:
replSetName: <replicaSetName>

Inicia la mongod usando el archivo de configuración:

mongod --config <path-to-config-file>

Para obtener más información sobre el archivo de configuración, consultar opciones del archivo de configuración.

También puedes utilizar las opciones equivalentes mongod al iniciar tu mongod. Consulta la página de referencia de mongod para ver la lista completa de opciones.

Incluye configuraciones adicionales según corresponda para tu implementación.

Al finalizar este paso, todos los miembros del conjunto de réplicas deberían estar en funcionamiento con la autenticación activada. Los clientes solo pueden conectarse a estas instancias mediante el mecanismo de autenticación de cliente mongod configurado.

Para obtener detalles sobre el uso de X.509 para la autenticación interna, consulte Utilice el certificado X.509 para la autenticación de membresía en MongoDB autogestionado.

Para actualizar de la autenticación interna de archivo de claves a509 la autenticación interna X.,consulte Actualizar MongoDB autoadministrado de la autenticación de archivo de claves a la autenticación X..509

Volver

Actualizar el Set de réplicas

En esta página