Puede exigir que los miembros de sets de réplicas y clústeres se autentican entre sí. Para la autenticación interna de los nodos, MongoDB puede usar archivos clave o x.509 certificados.
El método seleccionado se utiliza para toda la comunicación interna. Por ejemplo, cuando un cliente se autentica en un mongos usando uno de los mecanismos de autenticación compatibles, mongos utiliza entonces el método interno de autenticación configurado para conectarse a los mongod procesos requeridos.
Nota
Habilitar la autenticación interna también habilita la autorización de clientes.
Archivos clave
Los archivos clave utilizan el mecanismo de autenticación de desafío y respuesta SCRAM, donde los archivos clave contienen la contraseña compartida para los nodos.
Requisitos clave
La longitud de una clave debe estar entre 6 y 1024 caracteres y solo puede contener caracteres en base64. MongoDB elimina los espacios en blanco (p. ej., x0d, x09 y x20) para mayor comodidad entre plataformas. Como resultado, las siguientes operaciones generan claves idénticas:
echo -e "mysecretkey" > key1 echo -e "my secret key" > key1 echo -e "my secret key\n" > key2 echo -e "my secret key" > key3 echo -e "my\r\nsecret\r\nkey\r\n" > key4
Formato del fichero de claves
Los archivos clave para la autenticación interna de miembros utilizan el formato YAML para permitir múltiples claves en un archivo clave. El formato YAML acepta cualquiera de los siguientes:
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.
Por ejemplo,
Si el archivo clave contiene una sola clave, puedes especificar la string clave con o sin comillas:
my old secret key1
Puede especificar varias cadenas clave [1] como una secuencia de cadenas clave (opcionalmente entre comillas):
- my old secret key1 - my new secret key2
La posibilidad de especificar varias claves en un archivo permite su actualización gradual sin tiempo de inactividad.Consulte Rotar claves para conjuntos de réplicas autogestionados y Rotar claves para clústeres fragmentados autogestionados.
Todas las mongod y mongos instancias de una implementación deben compartir al menos una clave común.
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.
Debe almacenar el archivo de clave en cada servidor que aloje al miembro del conjunto de réplicas o clústeres fragmentados.
| [1] | Para el motor de almacenamiento cifrado de MongoDB, el archivo de clave utilizado para la gestión de clave local solo puede contener una única clave. |
Configuración de MongoDB para archivo de claves
Para especificar el archivo de claves, utilice la configuración o security.keyFile la --keyFile opción de línea de comando.
Para un ejemplo de autenticación interna mediante keyfile, consulta Actualizar el set de réplicas autogestionado a autenticación por keyfile.
X.509
Los miembros de un conjunto de réplicas o un clúster fragmentado pueden usar certificados x.509 para la autenticación interna en lugar de archivos de claves. Esto también se conoce como TLS mutuo o mTLS. MongoDB admite la autenticación con certificados x.509 para su uso con una conexión TLS/SSL segura.
Nota
MongoDB deshabilita el soporte para el cifrado TLS 1.0 en sistemas donde TLS 1.1+ está disponible.
Requisitos del certificado de nodo
Los certificados de miembro que utiliza para verificar la membresía a un clúster fragmentado o un conjunto de réplicas (, sinet.tls.clusterFile net.tls.certificateKeyFile se especifica, y), deben tener las siguientes propiedades:
Una única Autoridad Certificadora (CA) debe emitir todos los certificados x.509 para los nodos de un clúster o un set de réplicas.
El nombre distinguido
DN(), que se encuentra en el del certificado desubjectmiembro, debe especificar un valor no vacío para al menos uno de los siguientes atributos:la organización (
O)la Unidad Organizativa (
OU)El componente del dominio (
DC)
Los atributos de la organización (
O), los atributos de la unidad organizativa (OU) y los componentes del dominio (DC) deben coincidir con los de ambos certificadosnet.tls.clusterFileynet.tls.certificateKeyFilepara los demás miembros del clúster (o el valor detlsX509ClusterAuthDNOverride, si está configurado).Para coincidir, el certificado debe coincidir con todas las especificaciones de estos atributos, incluso la no especificación de estos atributos. El orden de los atributos no importa.
En el siguiente ejemplo, los dos
DNcontienen especificaciones coincidentes paraO,OU, así como la no especificación del atributoDC.CN=host1,OU=Dept1,O=MongoDB,ST=NY,C=US C=US, ST=CA, O=MongoDB, OU=Dept1, CN=host2 Sin embargo, los dos
DNsiguientes contienen una falta de coincidencia para el atributoOUya que uno contiene dos especificacionesOUy el otro, solo una.CN=host1,OU=Dept1,OU=Sales,O=MongoDB CN=host2,OU=Dept1,O=MongoDB En implementaciones multi-cluster, cada clúster debe usar un certificado de nodo X.509 diferente. Cada certificado debe tener valores únicos en los campos del Nombre Distinguido (ND)
O,OUyDC.Si dos clústeres tienen certificados con los mismos valores de nombre distinguido, un servidor comprometido en un clúster puede autenticarse como nodo del otro.
El Nombre Común (
CN) o una de las entradas de Nombre Alternativo del Sujeto (SAN) deben coincidir con el nombre del servidor para los demás nodos del clúster. A partir de MongoDB 4.2, al compararSANs, MongoDB puede comparar nombres DNS o direcciones IP. En versiones anteriores, MongoDB solo compara nombres DNS.Por ejemplo, los certificados para un clúster podrían tener los siguientes sujetos:
subject= CN=<myhostname1>,OU=Dept1,O=MongoDB,ST=NY,C=US subject= CN=<myhostname2>,OU=Dept1,O=MongoDB,ST=NY,C=US subject= CN=<myhostname3>,OU=Dept1,O=MongoDB,ST=NY,C=US Si el certificado utilizado como
certificateKeyFileincluyeextendedKeyUsage, el valor debe incluirclientAuth("Autenticación de cliente web TLS") yserverAuth("Autenticación de servidor web TLS").extendedKeyUsage = clientAuth, serverAuth Si el certificado utilizado como
clusterFileincluyeextendedKeyUsage, el valor debe incluirclientAuth.extendedKeyUsage = clientAuth El certificado x.509 no debe estar caducado.
mongod/mongosgenera un registro de advertencia en la conexión si el certificado X.509 presentado caduca dentro de30días a partir de la hora del sistema hostmongod/mongos.
Configuración de MongoDB
Se puede usar TLS para la autenticación interna entre cada miembro del set de réplicas (cada instancia mongod) o de un clúster particionado (cada instancia mongod y mongos).
Para utilizar TLS para la autenticación interna, utiliza la siguiente configuración:
security.clusterAuthModeo--clusterAuthModeconfigurado parax509
Las instancias mongod y mongos utilizan su archivo clave de certificado para demostrar su identidad a los clientes, pero también se puede usar para la autenticación de membresía. Si no se especifica un archivo de clúster, los nodos utilizarán sus archivos de claves de certificados para la autenticación de membresía. Especifica el archivo de clave del certificado con net.tls.certificateKeyFile o --tlsCertificateKeyFile.
Para utilizar el certificate key file tanto para la autenticación del cliente como la autenticación de membresía, el certificado debe:
Omite
extendedKeyUsageoEspecifica
extendedKeyUsage = serverAuth, clientAuth
Próximos pasos
Para ver un ejemplo de autenticación interna x.509, consulta Usar un certificado x.509 para la autenticación de membresía con MongoDB autogestionado.
Para actualizar de la autenticación interna de archivo de claves a509 la autenticación interna x., consulte Actualizar MongoDB autoadministrado de509 la autenticación de archivo de claves a la autenticación x..