Docs Menu
Docs Home
/ /
Interno
Docs Home
/ /
Autenticación
/
Interno
Docs Home
/
Gestión
/
Seguridad
/
Usuarios
/
Autenticación
/
Interno

Verifique la pertenencia al clúster con X.509 en MongoDB autogestionado

MongoDB admite la autenticación de certificado X.509 para su uso con un servidor seguro. Conexión TLS/SSL. Los miembros del clúster fragmentado y del conjunto de réplicas pueden usar509 certificados X. para verificar su pertenencia al clúster o al conjunto de réplicas en lugar de usar archivos de claves. La autenticación de la pertenencia es un proceso interno.

Nota

MongoDB deshabilita el soporte para el cifrado TLS 1.0 y TLS 1.1 en sistemas donde TLS 1.2+ está disponible.

Al habilitar la autenticación interna, también se habilita el control de acceso basado en roles en implementaciones autogestionadas. Los clientes deben autenticarse como usuarios para conectarse y realizar operaciones en la implementación.

Importante

Una descripción completa de los certificados TLS/SSL, PKI (Infraestructura de Clave Pública), en particular los certificados X.509, y la autoridad de certificación queda fuera del alcance de este documento. Este tutorial presupone conocimientos previos de TLS/SSL y acceso a certificados X.509 válidos.

Certificado del miembro X.509

Nota

Debe tener certificados X.509 válidos.

Si lo especifica --tlsAllowInvalidCertificates net.tls.allowInvalidCertificates: trueo, un certificado no válido solo es suficiente para establecer una conexión TLS, pero es insuficiente para la autenticación.

Requisitos del certificado

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

Nota

Si estableces el parámetro enforceUserClusterSeparation en false, se aplican los siguientes comportamientos:

  • No puedes establecer clusterAuthMode en una opción que permita X.509 o el servidor no arrancará. El servidor solo se iniciará si clusterAuthMode está keyFile.

  • Un cliente puede crear un usuario en la base de datos $external cuyos atributos de O/OU/DC coincidan con los atributos configurados del servidor para la pertenencia al clúster.

  • Un cliente que presenta un certificado del nodo ahora puede intentar la autenticación MONGODB-X509 como usuario en la base de datos $external.

Para establecer el parámetro enforceUserClusterSeparation en false, ejecute el siguiente comando durante el inicio:

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 especifica subjectAltName, MongoDB compara el nombre común (CN). Sin embargo, este uso del CN ​​está obsoleto. 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

Configurar un conjunto de réplicas/clúster fragmentado

Fuera de los procedimientos de actualización continua, cada componente de un conjunto de réplicas o un clúster fragmentado debe usar la misma --clusterAuthMode configuración para garantizar que pueda conectarse de forma segura a todos los demás componentes en la implementación.

Para las implementaciones de conjuntos de réplicas, esto incluye todos los mongod miembros del conjunto de réplicas.

Para implementaciones de clúster, esto incluye todas las instancias de mongod o mongos.

Nota

mongod y mongos se enlazan a localhost por defecto. Si los miembros de la implementación se ejecutan en hosts diferentes o si se desea que clientes remotos se conecten a la implementación, se debe especificar --bind_ip o net.bindIp.

Usar opciones de línea de comandostls ()

Nota

Los procedimientos de esta sección utilizan la tls configuración/opción. Para conocer los procedimientos que utilizan los ssl alias obsoletos, consulte Usar opcionesssl de línea de comandos ().

Los ajustes/opciones de tls proporcionan una funcionalidad idéntica a las opciones de ssl ya que MongoDB siempre ha admitido TLS 1.0 y posteriores.

mongod --replSet <name> --tlsMode requireTLS --clusterAuthMode x509 --tlsClusterFile <path to membership certificate and key PEM file> --tlsCertificateKeyFile <path to TLS/SSL certificate and key file> --tlsCAFile <path to root CA file> --bind_ip localhost,<hostname(s)|ip address(es)>

Importante

Para utilizar la autenticación X.509, se debe especificar --tlsCAFile o net.tls.CAFile a menos que utilice --tlsCertificateSelector o --net.tls.certificateSelector.

Incluya cualquier opción adicional, TLS/SSL o de otro tipo, que sea necesaria para su configuración específica. Para

security:
   clusterAuthMode: x509
net:
   tls:
      mode: requireTLS
      certificateKeyFile: <path to its TLS/SSL certificate and key file>
      CAFile: <path to root CA PEM file to verify received certificate>
      clusterFile: <path to its certificate key file for membership authentication>
   bindIp: localhost,<hostname(s)|ip address(es)>

Importante

Para utilizar la autenticación X.509, se debe especificar --tlsCAFile o net.tls.CAFile a menos que utilice --tlsCertificateSelector o --net.tls.certificateSelector.

Incluye cualquier opción adicional, ya sea TLS/SSL u otra, que sea necesaria para tu configuración específica.

Para obtener más información,consulte Configurar instancias de MongoDB para TLS/SSL en implementaciones autoadministradas.

Usar opciones de línea de comandosssl ()

Nota

Los procedimientos de esta sección utilizan la ssl configuración/opción obsoleta. Para procedimientos que utilizan tls alias, consulte Usar opcionestls de línea de comandos ().

Los ajustes/opciones de tls proporcionan una funcionalidad idéntica a las opciones de ssl ya que MongoDB siempre ha admitido TLS 1.0 y posteriores.

Para especificar el certificado X.509 para la autenticación de miembros del clúster interno, agregue las opciones TLS/SSL adicionales --clusterAuthMode y --sslClusterFile, como en el siguiente ejemplo para un miembro de un conjunto de réplicas:

mongod --replSet <name> --sslMode requireSSL --clusterAuthMode x509 --sslClusterFile <path to membership certificate and key PEM file> --sslPEMKeyFile <path to TLS/SSL certificate and key PEM file> --sslCAFile <path to root CA PEM file> --bind_ip localhost,<hostname(s)|ip address(es)>

Importante

Para utilizar la autenticación X.509, se debe especificar --tlsCAFile o net.tls.CAFile a menos que utilice --tlsCertificateSelector o --net.tls.certificateSelector.

Incluye cualquier opción adicional, ya sea TLS/SSL u otra, que sea necesaria para tu configuración específica.

security:
   clusterAuthMode: x509
net:
   ssl:
      mode: requireSSL
      PEMKeyFile: <path to TLS/SSL certificate and key PEM file>
      CAFile: <path to root CA PEM file>
      clusterFile: <path to X.509 membership certificate and key PEM file>
   bindIp: localhost,<hostname(s)|ip address(es)>

Importante

Para utilizar la autenticación X.509, se debe especificar --tlsCAFile o net.tls.CAFile a menos que utilice --tlsCertificateSelector o --net.tls.certificateSelector.

Incluye cualquier opción adicional, ya sea TLS/SSL u otra, que sea necesaria para tu configuración específica.

Para obtener más información,consulte Configurar instancias de MongoDB para TLS/SSL en implementaciones autoadministradas.

Información Adicional

Para actualizar de la autenticación interna del archivo de claves a la autenticación interna X.509, consultar Actualización de la autenticación del archivo de claves a la autenticación X.509.

Para realizar una actualización continua de los certificados a nuevos certificados con diferentes,DN consulte Rotar certificados en clústeres autoadministrados sin clusterAuthX.509

Volver

Rotar claves de clúster particionados

Next

Actualizar a X.509 desde Keyfile.

En esta página