Autenticación interna/de membresía autogestionada

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 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 de archivo de claves

Los archivos de claves para la autenticación de membresía interna 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.

Por ejemplo,

my old secret key1

- 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 mongod las mongos instancias y 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.

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 obtener un ejemplo de autenticación interna de archivo de claves, consulte Actualizar el conjunto de réplicas autoadministradas a autenticación de archivo de claves.

Requisitos del certificado de nodo

Cuando TLS esté habilitado, utilice certificados de nodo para verificar la pertenencia a las conexiones internas de un clúster o un set de réplicas. Puede configurar las rutas de los archivos de certificados de nodo con las opciones net.tls.clusterFile y net.tls.certificateKeyFile. Los miembros tienen los siguientes requisitos de configuración:

• La configuración del nodo del clúster debe especificar un valor no vacío para al menos uno de los atributos utilizados para la autenticación. Por defecto, MongoDB acepta:

  • la organización (O)

  • la Unidad Organizativa (OU)

  • El componente del dominio (DC)

  MongoDB verifica que las entradas coincidan exactamente en todos los certificados de nodo. Si enumeras varios valores de OU, todos los certificados deben usar una lista idéntica.

  Se pueden especificar atributos alternativos para usar en la autenticación al configurar net.tls.clusterAuthX509.extensionValue.

• La configuración de los nodos del clúster debe incluir el mismo net.tls.clusterAuthX509.attributes y usar valores coincidentes. El orden de los atributos no importa. El siguiente ejemplo configura O y OU, pero no DC:

  net:
    tls:
      clusterAuthX509:
        attributes: O=MongoDB, OU=MongoDB Server

mongod --setParameter enforceUserClusterSeparation=false

Los certificados tienen los siguientes requisitos:

• Una única Autoridad Certificadora (CA) debe emitir todos los certificados X.509 para los miembros de un clúster o de un set de réplicas.

• Al menos una de las entradas del nombre alternativo del sujeto (SAN) debe coincidir con el nombre de host del servidor usado por otros miembros del clúster. Al comparar SAN, MongoDB puede comparar nombres DNS o direcciones IP.

  Si no especificas subjectAltName, MongoDB compara el nombre común (CN) en su lugar. Sin embargo, este uso de CN está obsoleto según RFC2818

El uso de clave y el uso extendido de clave son extensiones X.509 que definen y restringen estrictamente el uso de la clave asociada a un certificado. Ambas extensiones son opcionales. Si tlsCertificateKeyFile o tlsClusterFile apuntan a certificados que omiten estas extensiones, no se aplican restricciones en el uso del certificado.

Si los certificados X.509 utilizados para tlsCertificateKeyFile o tlsClusterFile incluyen la extensión de Uso extendido de clave (EKU), estos deben cumplir con las siguientes reglas:

• tlsCertificateKeyFile deben incluir serverAuth en EKU.

  extendedKeyUsage = serverAuth

• tlsClusterFile debes incluir clientAuth en EKU:

  extendedKeyUsage = clientAuth

• Si se omite tlsClusterFile y solo se configura tlsCertificateKeyFile, tlsCertificateKeyFile deben incluir tanto serverAuth como clientAuth en EKU:

  extendedKeyUsage = clientAuth, serverAuth

Si los certificados X.509 utilizados para tlsCertificateKeyFile o tlsClusterFile incluyen la extensión de Uso de clave (KU), esta se debe configurar de la siguiente manera:

• tlsCertificateKeyFile debe contener digitalSignature, keyEncipherment y keyAgreement en su extensión KU:

  keyUsage = digitalSignature, keyEncipherment, keyAgreement

• tlsClusterFile debe contener digitalSignature en su extensión KU:

  keyUsage = digitalSignature

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