Docs Menu
Docs Home
/ /
Interno
/ / / / /

Implementación de un clúster fragmentado autogestionado con autenticación mediante archivo de claves

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

  • Seguridad entre componentes del cluster mediante autenticación interna.

  • Seguridad entre los clientes que se conectan y el clúster mediante controles de acceso de usuario.

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

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

La autenticación interna también refuerza el control de acceso de los usuarios. Para conectarse al conjunto de réplicas, los clientes como mongosh necesitan usar una cuenta de usuario. Consulte Control de acceso.

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.

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, se mongos enlazan a localhost de forma predeterminada.

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 fragmentos específicos de un clúster fragmentado. Para realizar estas operaciones, debe conectarse directamente al fragmento y autenticarse como usuario administrativo local del fragmento.

Los usuarios locales del fragmento solo existen en el fragmento específico y solo deben usarse para tareas de mantenimiento y configuración específicas del fragmento. No es posible conectarse al mongos con usuarios locales del fragmento.

Este tutorial requiere la creación de usuarios de clúster fragmentado, pero incluye pasos opcionales para agregar usuarios locales de fragmentos.

Consulte la documentación de seguridad de Usuarios en implementaciones autoadministradas para obtener más información.

Este tutorial utiliza los programas y. Los usuarios mongod de Windows deberían usar mongos mongod.exe mongos.exe los programas y.

Los siguientes procedimientos implican la creación de un nuevo clúster fragmentado que consta de un, los servidores de configuración y dos mongos fragmentos.

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.

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

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.

Los siguientes pasos implementan un conjunto de réplicas del servidor de configuración.

Para una implementación de producción, se implementa un conjunto de réplicas del servidor de configuración con al menos tres miembros. Para realizar pruebas, se puede crear un conjunto de réplicas de un solo miembro.

1

Inicie cada mongod en el conjunto de réplicas del servidor de configuración. Incluya la keyFile configuración. La keyFile configuración aplica la autenticación interna/de membresía autogestionada y el control de acceso basado en roles en las implementaciones autogestionadas.

Puede especificar la configuración mediante un archivo de configuración o la línea de mongod comando.

archivo de configuración

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

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

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 mongod especificando --config la opción 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 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.

2

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

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.

3

El método inicia el conjunto rs.initiate() de réplicas y puede usar un documento de configuración opcional. En el documento de configuración, incluya:

  • El _id. El _id debe coincidir con el parámetro --replSet pasado al mongod.

  • El members campo. El campo es una matriz y requiere un documento por cada miembro del conjunto de members réplicas.

  • El campo configsvr. El campo configsvr debe estar configurado en true para el set de réplicas del servidor de configuración.

Consulte Configuración del conjunto de réplicas autoadministradas para obtener más información sobre los documentos de configuración del conjunto de réplicas.

Inicie el conjunto de réplicas utilizando el método y un documento de rs.initiate() configuración:

rs.initiate(
{
_id: "myReplSet",
configsvr: true,
members: [
{ _id : 0, host : "cfg1.example.net:27019" },
{ _id : 1, host : "cfg2.example.net:27019" },
{ _id : 2, host : "cfg3.example.net:27019" }
]
}
)

Nota

Para usar el conjunto de réplicas del servidor de configuración (CSRS) en este procedimiento, primero debe esperar a que se inicialice. Si el CSRS no se inicializa, se generan errores NotYetInitialized.

Una vez iniciado y en funcionamiento el set de réplicas del servidor de configuración (CSRS), procede a crear los sets de réplicas de las particiones.

Para una implementación de producción, utilice un conjunto de réplicas con al menos tres miembros. Para realizar pruebas, puede crear un conjunto de réplicas con un solo miembro.

Estos pasos incluyen procedimientos opcionales para agregar usuarios locales a cada fragmento. Su ejecución garantiza que haya usuarios disponibles en cada fragmento para realizar el mantenimiento a nivel de fragmento.

1

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.

Inicie cada mongod en el conjunto de réplicas utilizando un archivo de configuración o la línea de comando.

archivo de configuración

Si utiliza un archivo de configuración, establezca la opciónsecurity.keyFileen la ruta del archivo de clave, replication.replSetNameen el nombre deseado del conjunto de réplicas y la opciónsharding.clusterRoleen shardsvr.

security:
keyFile: <path-to-keyfile>
sharding:
clusterRole: shardsvr
replication:
replSetName: <replSetName>
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 mongod especificando --config la opción y la ruta al archivo de configuración.

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

Línea de comandos

Si utiliza la opción de línea de comando, al iniciar el componente, especifique los parámetros --keyFile, replSet y --shardsvr, como en el siguiente ejemplo:

mongod --keyFile <path-to-keyfile> --shardsvr --replSet <replSetName> --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.

2

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

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.

3

Desde mongosh, ejecuta el método rs.initiate().

rs.initiate() puede tomar un documento de configuración de Set de réplicas opcional. En el documento de configuración del Set de réplicas, incluya:

  • El campo _id se establece en el nombre del Set de réplicas especificado en el replication.replSetName o en la opción --replSet.

  • El members arreglo con un documento por cada nodo del set de réplicas.

El siguiente ejemplo inicia un Set de réplicas de tres nodos.

rs.initiate(
{
_id : "myReplSet",
members: [
{ _id : 0, host : "s1-mongo1.example.net:27018" },
{ _id : 1, host : "s1-mongo2.example.net:27018" },
{ _id : 2, host : "s1-mongo3.example.net:27018" }
]
}
)

rs.initiate() activa una elección y elige a uno de los miembros para que sea el primario.

Conéctate al primario antes de continuar. Utiliza rs.status() para localizar al miembro primario.

4

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, es posible que no se pueda crear o modificar usuarios con nuevos privilegios y, por lo tanto, no se pueda acceder a 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.

Debe estar conectado al primario para crear usuarios.

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

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: "fred",
pwd: passwordPrompt(), // or cleartext password
roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
}
)

Se debe ingresar la contraseña cuando se indique. Se debe consultar Roles de usuario de base de datos para ver una lista completa de los roles incorporados relacionados con las operaciones de administración de bases de datos.

5

Autentícate en la base de datos admin.

En mongosh, utiliza db.auth() para autenticarte. Por ejemplo, los siguientes se autentican como el usuario administrador fred:

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.

db.getSiblingDB("admin").auth("fred", passwordPrompt()) // or cleartext password

Como alternativa, conecta||||||| una nueva mongosh instancia al miembro primario del Set de réplicas utilizando los parámetros -u <username>, -p <password> y --authenticationDatabase.

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.

6

El usuario administrador del clúster local del fragmento tiene el clusterAdmin rol, que proporciona privilegios que permiten el acceso a las operaciones de replicación.

Para obtener una lista completa de roles relacionados con las operaciones del conjunto de réplicas, consulte Roles de administración de clúster.

Cree un usuario administrador del clúster y asígnele el rol de clusterAdmin en la base de datos admin:

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.

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

Introduzca la contraseña cuando se lo pidan.

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.

1

Inicie un especificando el archivo de claves mediante un archivo de configuración o un parámetro de línea de mongos comando.

archivo de configuración

Si utiliza un archivo de configuración, establezca security.keyFile en la ruta del archivo de clave y en sharding.configDB el nombre del conjunto de réplicas y al menos un miembro del conjunto de réplicas en <replSetName>/<host:port> formato.

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 mongos especificando --config la opción y la ruta al archivo de configuración.

mongos --config <path-to-config>

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.

2

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.

3

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 cierra la excepción localhost, no podrá crear ni modificar usuarios y, por lo tanto, es posible que no pueda realizar 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

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: "fred",
pwd: passwordPrompt(), // or cleartext password
roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
}
)

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

4

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

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.

db.getSiblingDB("admin").auth("fred", passwordPrompt()) // or cleartext password

Introduzca la contraseña cuando se lo pidan.

Como alternativa, conecte una nueva sesión al miembro del conjunto de réplicas de mongosh destino -u <username> mediante-p <password> los parámetros,--authenticationDatabase "admin" y. Debe usar la excepción de host local en las implementaciones autoadministradas para conectarse mongos a.

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.

5

El usuario administrador del clúster tiene el rol, que otorga acceso a las operaciones de replicación y clusterAdmin fragmentación.

Crea un usuario clusterAdmin en la base de datos admin.

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

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.

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.

6

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 continuar, debe estar conectado al y autenticado como usuario administrador del clúster para el clúster mongos fragmentado.

Nota

Este es el administrador del clúster para el clúster fragmentado y no el administrador del clúster local del fragmento.

Para agregar cada fragmento al clúster, utilice el método. Si el fragmento es un conjunto de réplicas, especifique el sh.addShard() nombre del conjunto y un miembro del mismo. En implementaciones de producción, todos los fragmentos deben ser conjuntos de réplicas.

La siguiente operación agrega un único conjunto de réplicas de fragmentos al clúster:

sh.addShard( "<replSetName>/s1-mongo1.example.net:27017")

La siguiente operación es un ejemplo de cómo agregar un fragmento independiente al mongod clúster:

sh.addShard( "s1-mongo1.example.net:27017")

Repita estos pasos hasta que el clúster incluya todos los fragmentos. En este punto, el clúster fragmentado aplica el control de acceso tanto al clúster como a las comunicaciones internas entre cada componente.

Para continuar, debe estar conectado al y autenticado como usuario administrador del clúster para el clúster mongos fragmentado.

Nota

Este es el administrador del clúster para el clúster fragmentado y no el administrador del clúster local del fragmento.

Para fragmentar una colección, utilice el método. Debe especificar el espacio de nombres completo de la colección y un documento que contenga la clave de sh.shardCollection() fragmentación.

La selección de la clave de fragmentación afecta la eficiencia de la fragmentación, así como su capacidad para aprovechar ciertas funciones de fragmentación, como las zonas. Consulte las consideraciones de selección en la sección "Elegir una clave de fragmentación".

Si la colección ya contiene datos, debe crear un índice en la clave de fragmento utilizando el método antes db.collection.createIndex() de shardCollection() usar.

Si la colección está vacía, MongoDB crea el índice como parte sh.shardCollection() de.

El siguiente es un ejemplo del sh.shardCollection() método:

sh.shardCollection("<database>.<collection>", { <key> : <direction> } )

Cree usuarios para permitir que los clientes se conecten e interactúen con el clúster fragmentado.

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.

Para obtener detalles sobre el uso de X.509 para la autenticación interna, consulte Usar509 el certificado X. para la autenticación de membresía con MongoDB autoadministrado.

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

Actualiza el Set de réplicas (sin tiempo de inactividad)

En esta página