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
/ / / / /

Actualización del clúster fragmentado autogestionado a la autenticación mediante archivo de claves

Implementar el control de acceso en un El clúster fragmentado requiere configurar:

Para este tutorial, cada nodo del clúster debe usar el mismo mecanismo de autenticación interna y configuración. Esto significa aplicar la autenticación interna en cada mongosy en el mongod clúster.

El siguiente tutorial utiliza un archivo clave para habilitar la autenticación interna.

La aplicación de la autenticación interna también aplica el control de acceso de los usuarios. Para conectarse al set de réplicas, los clientes como mongosh necesitan utilizar una cuenta de usuario. Véase Control de acceso.

Si Cloud Manager u Ops Manager están gestionando su implementación, la autenticación interna se aplica automáticamente.

Para configurar el Control de acceso en una implementación gestionada, consulta: Configure Access Control for MongoDB Deployments en el manual de Cloud Manager o en el manual de Ops Manager.

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.

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

Este tutorial se refiere principalmente al proceso de mongod. Los usuarios de Windows deberían usar el programa mongod.exe en su lugar.

Los archivos de claves son medidas de seguridad mínimas y son ideales para entornos de prueba o desarrollo. Para entornos de producción, recomendamos usar certificados X..509

Este tutorial cubre la creación del número mínimo de usuarios administrativos únicamente en la base de datos admin. Para la autenticación de usuario, el tutorial utiliza el mecanismo de autenticación SCRAM por defecto. Los mecanismos de seguridad de desafío-respuesta son más adecuados para entornos de prueba o desarrollo. Para entornos de producción, recomendamos usar certificados X.509 o Autenticación Proxy LDAP autogestionada (disponible solo para MongoDB Enterprise) o Autenticación Kerberos en implementaciones autogestionadas (disponible solo para MongoDB Enterprise).

Para obtener detalles sobre la creación de usuarios para un mecanismo de autenticación específico, consultar las páginas correspondientes a cada mecanismo de autenticación.

Consultar ➤ Configurar el Control de Acceso Basado en Roles para conocer las mejores prácticas para la creación y gestión de usuarios.

En general, para crear usuarios para un clúster fragmentado, conéctese a y agregue los usuarios del clúster mongos fragmentado.

Sin embargo, algunas operaciones de mantenimiento requieren conexiones directas a particiones específicas en un clúster. Para realizar estas operaciones, debe conectarse directamente a la partición y autenticarse como un usuario administrativo local de la partición.

Los usuarios locales de particiones existen únicamente en la partición específica y deben ser utilizados únicamente para el mantenimiento y la configuración específicos de la partición. No es posible conectarse a mongos con usuarios locales de partición.

Consulta la documentación de seguridad de Usuarios en Despliegues Autogestionados para obtener más información.

Actualizar un clúster fragmentado para aplicar el control de acceso requiere tiempo de inactividad.

1

Con la autenticación por archivo clave, cada instancia de mongod o mongos en el clúster particionado utiliza el contenido del archivo clave como la contraseña compartida para autenticar a otros nodos en la implementación. Solo las instancias mongod o mongos con el fichero de clave 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 en 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 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.

2

Cada servidor que hospeda un mongod o un mongos componente del clúster fragmentado debe contener una copia del archivo clave.

Copia el archivo de claves en cada servidor que hospede los nodos del clúster. Asegúrese de que el usuario que ejecuta las instancias mongod o mongos sea el propietario del archivo y pueda acceder al keyfile.

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.

3

Conecta mongosh a un mongos.

sh.stopBalancer()

El balanceador puede no detenerse inmediatamente si hay una migración en curso. El método sh.stopBalancer() bloquea el shell hasta que el balanceador se detiene.

A partir de MongoDB 6.0.3, la división automática de fragmentos no se realiza. Esto se debe a mejoras en la política de balanceo. Los comandos de división automática aún existen, pero no realizan ninguna operación. Para más información, consulte Cambios en la política de balanceo.

En versiones de MongoDB anteriores a 6.0.3, también deshabilita la división automática para el clústersh.stopBalancer() fragmentado.

Utiliza sh.getBalancerState() para verificar que el balanceador se haya detenido.

sh.getBalancerState()

Importante

No continúe hasta que el balanceador haya dejado de ejecutarse.

Consulta Gestor de Balanceador de clúster para tutoriales sobre cómo configurar el comportamiento del balanceador del clúster.

4

Conecte mongosh a cada mongos y apáguelos.

Utiliza el db.shutdownServer() método en la base de datos admin para apagar con seguridad el mongos:

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

Repetí hasta que todas las instancias de mongos en el clúster estén fuera de línea.

Una vez completado este paso, todas las instancias mongos en el clúster deberían estar fuera de línea.

5

Conecta mongosh a cada mongod en la implementación del servidor de configuración y apágalos.

Para implementaciones de set de réplicas de servidor de configuración, apaga el miembro primario al final.

Utiliza el db.shutdownServer() método en la base de datos admin para apagar con seguridad el mongod:

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

Repita hasta que todos los servidores de configuración estén fuera de línea.

6

Para cada mongosh de mongod de partición, conecta a cada nodo en el set de réplicas y apágalos. Apague por último el principal.

Utiliza el db.shutdownServer() método en la base de datos admin para apagar con seguridad el mongod:

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

Repite este paso para cada mongod set de réplicas de partición hasta que todas las instancias en todos los sets de réplicas de partición estén desconectadas.

Una vez realizado este paso, todo el clúster fragmentado debe quedar fuera de línea.

7

Inicia cada mongod en el set de réplicas del servidor de configuración. Incluye la configuración keyFile. El ajuste keyFile aplica tanto la autenticación interna/autenticación de membresía autogestionada como el control de acceso basado en roles en implementaciones autogestionadas.

Puedes especificar la configuración de mongod ya sea a través de un archivo de configuración o de la línea de comandos.

archivo de configuración

Si utiliza un archivo de security.keyFile configuración, sharding.clusterRole para un conjunto configsvr de réplicas del servidor de configuración, establezca en la ruta del archivo de clave, en y en el nombre del conjunto de réplicas del servidor de configuración.replication.replSetName

security:
keyFile: <path-to-keyfile>
sharding:
clusterRole: configsvr
replication:
replSetName: <setname>
storage:
dbpath: <path>

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.

Inicie el mongod especificando la opción --config y la ruta al archivo de configuración.

mongod --config <path-to-config>

Línea de comandos

Si utiliza los parámetros de la línea de comandos, para un conjunto de réplicas del servidor de configuración, inicie con mongod los -keyFile parámetros, --configsvr --replSet y.

mongod --keyFile <path-to-keyfile> --configsvr --replSet <setname> --dbpath <path>

Incluir opciones adicionales según sea necesario para la configuración. Por ejemplo, si se desea que los clientes remotos se conecten a su implementación o si los miembros de su implementación se ejecutan en hosts diferentes, especificar el --bind_ip.

Para obtener más información sobre las opciones de la línea de comandos, consulte la página de mongod referencia.

Asegúrate de usar el nombre original del set de réplicas al reiniciar cada nodo. No puedes cambiar el nombre de un set de réplicas.

8

Al ejecutar un con mongod el keyFile parámetro se aplica tanto la autenticación interna/de membresía autoadministrada como el control de acceso basado en roles en implementaciones autoadministradas.

Inicia cada mongod en el set de réplicas mediante un archivo de configuración o la línea de comandos.

archivo de configuración

Si se utiliza un archivo de configuración, establezca la opción security.keyFile en la ruta del archivo clave y la opción replication.replSetName en el nombre original del set de réplicas.

security:
keyFile: <path-to-keyfile>
replication:
replSetName: <setname>
storage:
dbPath: <path>

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.

Inicie el mongod especificando la opción --config y la ruta al archivo de configuración.

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

Línea de comandos

Si utiliza los parámetros de la línea de comando, inicie mongod y especifique los parámetros --keyFile --replSet y.

mongod --keyfile <path-to-keyfile> --replSet <setname> --dbpath <path>

Incluir opciones adicionales según sea necesario para la configuración. Por ejemplo, si se desea que los clientes remotos se conecten a su implementación o si los miembros de su implementación se ejecutan en hosts diferentes, especificar el --bind_ip.

Para obtener más información sobre los parámetros de inicio, consulte la página de referencia mongod.

Asegúrate de usar el nombre original del set de réplicas al reiniciar cada nodo. No puedes cambiar el nombre de un set de réplicas.

Repita este paso hasta que todos los fragmentos del clúster estén en línea.

9

Importante

La excepción de Localhost en implementaciones autogestionadas permite a los clientes conectados a través de la interfaz localhost crear usuarios en un, lo que aplica mongod control de acceso. Tras crear el primer usuario, la excepción de Localhost en implementaciones autogestionadas se cierra.

El primer usuario debe tener privilegios para crear otros usuarios, como un usuario con el userAdminAnyDatabase. Esto asegura que puedas crear usuarios adicionales después de que se cierre la Excepción de Localhost en Implementaciones Autogestionadas.

Si al menos un usuario no tiene privilegios para crear usuarios, una vez que se cierre la excepción localhost, es posible que no pueda crear ni modificar usuarios con nuevos privilegios y, por lo tanto, no pueda acceder a ciertas funciones u operaciones.

Para cada conjunto de set de réplicas de partición en el clúster, conectar mongosh al miembro primario a través de la interfaz localhost. Debes ejecutar mongosh en la misma máquina que el mongod de destino para usar la interfaz localhost.

Crea un usuario con el rol userAdminAnyDatabase en la base de datos admin. Este usuario puede crear usuarios adicionales para el set de réplicas de la partición según sea necesario. La creación de este usuario también cierra la Excepción de localhost en implementaciones autogestionadas.

El siguiente ejemplo crea el usuario local del fragmento fred 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" } ]
}
)
10

Al ejecutar un con mongod el keyFile parámetro se aplica tanto la autenticación interna/de membresía autoadministrada como el control de acceso basado en roles en implementaciones autoadministradas.

Inicia cada mongos en el set de réplicas mediante un archivo de configuración o la línea de comandos.

archivo de configuración

Si usa un archivo de configuración, configure el security.keyFile a la ruta del keyfile y el sharding.configDB al nombre del set de réplicas y al menos un nodo del set de réplicas en el formato <replSetName>/<host:port>.

security:
keyFile: <path-to-keyfile>
sharding:
configDB: <configReplSetName>/cfg1.example.net:27019,cfg2.example.net:27019,...

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.

Inicie el mongos especificando la opción --config y la ruta al archivo de configuración.

mongos --config <path-to-config-file>

Línea de comandos

Si utilizas parámetros de línea de comandos, inicia el mongos y especifica los parámetros --keyFile y --configdb.

mongos --keyFile <path-to-keyfile> --configdb <configReplSetName>/cfg1.example.net:27019,cfg2.example.net:27019,...

Incluir opciones adicionales según sea necesario para la configuración. Por ejemplo, si se desea que los clientes remotos se conecten a su implementación o si los miembros de su implementación se ejecutan en hosts diferentes, especificar el --bind_ip.

En este punto, todo el clúster fragmentado vuelve a estar en línea y puede comunicarse internamente mediante el archivo de claves especificado. Sin embargo, los programas externos como mongosh necesitan usar un usuario correctamente aprovisionado para leer o escribir en el clúster.

11

Conecta mongosh a una de las instancias de mongos a través de la interfaz localhost. Debes ejecutar mongosh en la misma máquina física que la instancia mongos.

La interfaz de localhost solo está disponible porque no se han creado usuarios para la implementación. La interfaz localhost se cierra después de la creación del primer usuario.

12

Importante

Después de que se cree el primer usuario, la excepción localhost ya no está disponible.

El primer usuario debe tener privilegios para crear otros usuarios, como un usuario con el userAdminAnyDatabase. Esto asegura que puedas crear usuarios adicionales después de que se cierre la Excepción de Localhost en Implementaciones Autogestionadas.

Si al menos un usuario no tiene privilegios para crear usuarios, una vez que se cierre la excepción de localhost, no se podrán crear ni modificar usuarios y, por lo tanto, es posible que no se puedan ejecutar las operaciones necesarias.

Añadir un usuario usando el método db.createUser(). El usuario debe tener como mínimo 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.

El siguiente ejemplo crea el usuario fred en la base de datos admin:

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" } ]
}
)

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.

13

Utilice para autenticarse como administrador de usuarios para crear usuarios db.auth() adicionales:

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").auth("fred", passwordPrompt()) // or cleartext password

Introduzca la contraseña cuando se lo pidan.

Alternativamente, conecta una nueva mongosh sesión al miembro de réplica objetivo utilizando los parámetros -u <username>, -p <password> y --authenticationDatabase "admin". Debes usar la excepción de localhost en implementaciones autogestionadas para conectar con la mongos.

mongosh -u "fred" -p --authenticationDatabase "admin"

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

14

El usuario administrador del clúster tiene el clusterAdmin rol para el clúster fragmentado y no el administrador del clúster local del fragmento.

El siguiente ejemplo crea el usuario ravi 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" } ]
}
)

Consultar Roles de administración de clústeres para obtener una lista completa de los roles incorporados relacionados con las operaciones de sets de réplicas y clústeres.

15

Para realizar operaciones de particionamiento, autentíquese como un usuario clusterAdmin con el método db.auth() o una nueva sesión mongosh con los parámetros username, password y authenticationDatabase.

Nota

Este es el administrador del clúster para el cluster fragmentado y no el administrador del clúster local de la partición.

16

Inicia el balanceador.

sh.startBalancer()

A partir de MongoDB 6.0.3, la división automática de fragmentos no se realiza. Esto se debe a mejoras en la política de balanceo. Los comandos de división automática aún existen, pero no realizan ninguna operación. Para más información, consulte Cambios en la política de balanceo.

En las versiones de MongoDB anteriores a la 6.0.3, sh.startBalancer() también habilita la división automática para el clúster particionado.

Use el sh.getBalancerState() para verificar que el balanceador haya comenzado.

Consulta Gestionar Balanceador de Clúster Fragmentado para tutoriales sobre el balanceador de clústeres fragmentados.

17

Cree usuarios para permitir que los clientes se conecten y accedan al clúster fragmentado. Consulte Roles de usuario de base de datos para ver los roles integrados disponibles, como read readWritey. También puede necesitar usuarios administrativos adicionales. Para obtener más información sobre los usuarios,consulte Usuarios en implementaciones autoadministradas.

Para crear usuarios adicionales, debes autenticarte como un usuario con los roles userAdminAnyDatabase o userAdmin.

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

Desplegar clúster particionado

En esta página