Autenticación interna/autogestionada de miembros

Requisitos clave

La longitud de una clave debe estar entre 6 y 1024 caracteres y solo puede contener caracteres del conjunto base64. MongoDB elimina los caracteres de espacio en blanco (por ejemplo, x0d, x09 y x20) para una cómoda integración multiplataforma. Como resultado, las siguientes operaciones producen 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,

my old secret key1

- my old secret key1
- my new secret key2

La capacidad de especificar varias claves en un archivo permite la actualización progresiva de las claves sin interrupciones. Consulte Rotar llaves para conjuntos de réplicas autogestionados y Rotar llaves 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.

Debes almacenar el archivo de claves en cada servidor donde esté alojado el nodo del conjunto de réplicas o del clúster fragmentado.

Configuración de MongoDB para Keyfile

Para especificar el archivo clave, utiliza la configuración security.keyFile o la opción de línea de comandos --keyFile.

Para un ejemplo de autenticación interna mediante keyfile, consulta Actualizar el set de réplicas autogestionado a autenticación por keyfile.

Requisitos del certificado de nodo

Utiliza los certificados de miembro para verificar la membresía a un clúster fragmentado o a un set de réplicas. Los certificados de los nodos se almacenan en net.tls.clusterFile y net.tls.certificateKeyFile. Requisitos del certificado de nodo:

• Una única Autoridad de Certificación (CA) debe emitir todos los certificados x.509 para los nodos de un clúster o un set de réplicas.

• El certificado x.509 no debe estar caducado.

  Nota

  mongod / mongos genera un registro de advertencia en la conexión si el certificado X.509 presentado caduca dentro de 30 días a partir de la hora del sistema host mongod/mongos.

• El Nombre Distinguido (DN), que se encuentra en el subject del certificado de nodo, 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)

• 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, OU y DC.

  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.

• Cada certificado de nodo de clúster debe tener Os, OUs y DCs idénticos en sus certificados net.tls.clusterFile y net.tls.certificateKeyFile. Esto también se aplica al valor tlsX509ClusterAuthDNOverride, si está configurado. El orden de los atributos no importa.

  Aquí tienes un ejemplo. Los dos DNde abajo tienen especificaciones coincidentes para O y OU, y DC no está especificado.

  CN=host1,OU=Dept1,O=MongoDB,ST=NY,C=US
  C=US, ST=CA, O=MongoDB, OU=Dept1, CN=host2

  El siguiente ejemplo es incorrecto porque los DNs no coinciden. Un DN tiene dos especificaciones de OU y el otro tiene solo una especificación de OU.

  CN=host1,OU=Dept1,OU=Sales,O=MongoDB
  CN=host2,OU=Dept1,O=MongoDB

• 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 comparar SANs, MongoDB puede comparar nombres DNS o direcciones IP. En versiones anteriores, MongoDB solo compara nombres DNS.

  Por ejemplo, los certificados de un clúster podrían tener los siguientes subjects:

  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 el certificateKeyFile incluye extendedKeyUsage, el valor debe incluir tanto clientAuth (“Autenticación de cliente web TLS”) como serverAuth (“Autenticación de servidor web TLS”).

  extendedKeyUsage = clientAuth, serverAuth

• Si el certificado utilizado como clusterFile incluye extendedKeyUsage, el valor debe incluir clientAuth.

  extendedKeyUsage = clientAuth

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.clusterAuthMode o --clusterAuthMode configurado para x509

• net.tls.clusterFile or --tlsClusterFile

Las instancias mongod y mongos utilizan sus archivos de claves de certificado para demostrar su identidad a los clientes, pero los archivos de claves de certificado también pueden usarse para la autenticación de nodos. Si no especificas un archivo de clúster, los nodos usan sus archivos de claves de certificado para la autenticación de membresía. Especifica el archivo de clave del certificado con net.tls.certificateKeyFile o --tlsCertificateKeyFile.

Para utilizar el archivo de claves de certificado tanto para la autenticación de clientes como para la autenticación de miembros, el certificado debe:

• Omite extendedKeyUsage o

• Especifica extendedKeyUsage = serverAuth, clientAuth