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.
Consulta el tutorial Gestionar usuarios y roles en implementaciones autogestionadas para obtener instrucciones sobre cómo agregar usuarios a la implementación.
Consulte el tutorial Usar X.509 para autenticar clientes en MongoDB autoadministrado para obtener instrucciones sobre el uso de509 certificados X. para la autenticación de usuarios.
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.
Nodo X.509 Certificado
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.
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.attributesy usar valores coincidentes. El orden de los atributos no importa. El siguiente ejemplo configuraOyOU, pero noDC: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
clusterAuthModeen una opción que permita X.509 o el servidor no arrancará. El servidor solo se iniciará siclusterAuthModeestákeyFile.Un cliente puede crear un usuario en la base de datos
$externalcuyos atributos deO/OU/DCcoincidan 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 compararSAN, 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:
tlsCertificateKeyFiledeben incluirserverAuthen EKU.extendedKeyUsage = serverAuth tlsClusterFiledebes incluirclientAuthen EKU:extendedKeyUsage = clientAuth Si se omite
tlsClusterFiley solo se configuratlsCertificateKeyFile,tlsCertificateKeyFiledeben incluir tantoserverAuthcomoclientAuthen 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:
tlsCertificateKeyFiledebe contenerdigitalSignature,keyEnciphermentykeyAgreementen su extensión KU:keyUsage = digitalSignature, keyEncipherment, keyAgreement tlsClusterFiledebe contenerdigitalSignatureen su extensión KU:keyUsage = digitalSignature
Configurar set de réplicas/clúster
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.
Usa opciones de línea de comandos (tls)
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.
Usa opciones de línea de comandos (ssl)
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.
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