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
/ /
Interno
/ / / / /

Utilice el certificado x.509 para la autenticación de membresía con 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 en sistemas donde TLS 1.1+ 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, certificados PKI (Infraestructura de llave pública), en particular certificados x.509, y Autoridad Certificadora está más allá del alcance de este documento. Este tutorial asume conocimiento previo de TLS/SSL, así como acceso a certificados x.509 válidos.

Nota

Debes 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.

Los certificados de miembro que utiliza para verificar la membresía a un clúster fragmentado o un conjunto de réplicas (, sinet.tls.clusterFile net.tls.certificateKeyFile se especifica, y), deben tener las siguientes propiedades:

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

  • El nombre distinguidoDN (), que se encuentra en el del certificado de subject miembro, 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)

  • Los atributos de la organización (O), los atributos de la unidad organizativa (OU) y los componentes del dominio (DC) deben coincidir con los de ambos certificados net.tls.clusterFile y net.tls.certificateKeyFile para los demás miembros del clúster (o el valor de tlsX509ClusterAuthDNOverride, si está configurado).

    Para coincidir, el certificado debe coincidir con todas las especificaciones de estos atributos, incluso la no especificación de estos atributos. El orden de los atributos no importa.

    En el siguiente ejemplo, los dos DN contienen especificaciones coincidentes para O, OU, así como la no especificación del atributo DC.

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

    Sin embargo, los dos DN siguientes contienen una falta de coincidencia para el atributo OU ya que uno contiene dos especificaciones OU y el otro, solo una.

    CN=host1,OU=Dept1,OU=Sales,O=MongoDB
    CN=host2,OU=Dept1,O=MongoDB
  • 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.

  • 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 para un clúster podrían tener los siguientes sujetos:

    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 certificateKeyFile incluye extendedKeyUsage, el valor debe incluir clientAuth ("Autenticación de cliente web TLS") y 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
  • El certificado x.509 no debe estar caducado.

    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.

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> --sslCAFile <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 se 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 se 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 mongod y mongos para TLS/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 los nodos del clúster, adjunta las opciones adicionales de TLS/SSL --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 se 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 se 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 mongod y mongos para TLS/SSL.

Para actualizar de la autenticación interna de archivo de claves a509 la autenticación interna x., consulte Actualizar MongoDB autoadministrado de509 la autenticación de archivo de claves a la autenticación x..

Para realizar una actualización continua de los certificados a nuevos certificados con diferentes,DN consulte Actualización continua de x.509 certificados que contienen un nuevo DN en clústeres autoadministrados.

Volver

Rotar claves de clúster particionados

En esta página