Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home
/ /

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

MongoDB admite autenticación con certificado X.509 para uso con un Conexión TLS/SSL. Los nodos de clústeres y los nodos de sets de réplicas pueden usar certificados X.509 para verificar su membresía en el clúster o en el set de réplicas en lugar de utilizar archivos clave. La autenticación de membresía 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.

Habilitar la autenticación interna también habilita el Control de acceso basado en roles en implementaciones autogestionadas. Los clientes deben autenticarse como usuario para poder conectarse y realizar operaciones en la implementación.

Importante

Una descripción completa de TLS/SSL, los certificados PKI (Infraestructura de clave pública), en particular los certificados X.509, y la Autoridad de certificación está fuera del alcance de este documento. Este tutorial asume que se tiene un conocimiento previo de TLS/SSL y también acceso a certificados X.509 válidos.

Nota

Debe tener certificados X.509 válidos.

Si especificas --tlsAllowInvalidCertificates o net.tls.allowInvalidCertificates: true, un certificado inválido es suficiente solo para establecer una conexión TLS, pero es insuficiente para la autenticación.

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 se especifica subjectAltName, MongoDB compara el Nombre Común (CN) en su lugar. Sin embargo, este uso de CN está en desuso 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

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 set de réplicas, esto incluye todos los mongod nodos del set 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.

Nota

Los procedimientos en esta sección usan la configuración/opción tls. Para procedimientos que usen los alias obsoletos ssl, consulta Usar opciones de línea de comandos (ssl).

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 estés utilizando --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 estés utilizando --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 despliegues autogestionados.

Nota

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

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 interna de nodos del clúster, añade las opciones TLS/SSL adicionales --clusterAuthMode y --sslClusterFile, como en el siguiente ejemplo para un nodo de un set 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 estés utilizando --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 estés utilizando --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 despliegues autogestionados.

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

En esta página