Esta página describe la conexión que mongot abre a mongod (o mongos) para obtener datos de origen y leer el estado de replicación, para una implementación de MongoDB Search y búsqueda vectorial que gestiona con el operador de MongoDB Controllers para Kubernetes. En esta conexión, mongot es el cliente y mongod es el servidor. Esta página cubre cómo mongot se autentica en mongod (SCRAM o X.509), el rol que necesita su identidad y cómo mongot confía en el certificado de servidor mongod a través de TLS.
Los usuarios de la aplicación nunca se conectan directamente a mongot. Para la dirección opuesta —la conexión que mongod abre al servidor de escucha de mongot—, consulta Protege la conexión de MongoDB a Search.
Para ver el esquema completo de cada configuración de MongoDBSearch a la que se hace referencia en esta página, consulte Configuración de MongoDB Search y búsqueda vectorial.
Cómo se autentica mongot en mongod
Cuando mongot se conecta a mongod, se autentica como cliente de base de datos mediante uno de los dos modos mutuamente excluyentes:
Modo | Credencial | Usar cuando |
|---|---|---|
SCRAM | Nombre de usuario y contraseña | Su implementación de |
X.509 | Certificado de cliente | Su organización provisiona certificados de una PKI para los servicios de clúster, o los requisitos de cumplimiento favorecen la identidad basada en certificados sobre las contraseñas. |
Puede cambiar de modo después de actualizar el recurso MongoDBSearch y dejar que el operador de Kubernetes reinicie los pods mongot. La identidad del lado mongodcon la que se autentica mongot no necesita cambiar si tiene el rol necesario que se describe en la siguiente sección.
Nota
El cambio de SCRAM a X.509 requiere TLS en la fuente de sincronización. El operador de Kubernetes rechaza X.509 cuando la fuente mongod no ejecuta TLS. La habilitación de TLS de búsqueda por primera vez es una Interrupción del servicio de query breve pero real en lugar de un reinicio sin interrupciones. Planifique un breve tiempo de inactividad cuando realice este cambio. Consulte Proteja la conexión de MongoDB a Search para conocer el comportamiento de la transición.
El rol mongot necesita en mongod
Cualquiera que sea la moda que utilice mongot, la identidad que autentica debe tener permiso para obtener datos y mantener el catálogo de búsqueda en mongod. Esa identidad debe tener el rol searchCoordinator incorporado, que se incluye con MongoDB Server 8.2 y versiones posteriores y solo otorga los privilegios que requiere mongot.
Siempre crea esta identidad usted mismo; el controlador MongoDBSearch nunca la crea por usted. La forma de crearlo depende de si el operador de Kubernetes gestiona la fuente mongod:
Origen gestionado por el operador. Declare un usuario que tenga el rol
searchCoordinatory haga referencia a una contraseñaSecret— en la listausersde su recursoMongoDBCommunitypara Community, o como un recursoMongoDBUserindependiente para Enterprise. El operador de Kubernetes aprovisiona ese usuario enmongodpor usted. A continuación, haga referencia al mismo usuario ySecreten el recursoMongoDBSearchpara quemongotpueda autenticarse con él.Fuente externa. Cree el usuario y otórguele el rol
searchCoordinatordirectamente en su propia implementación demongod, luego haga referencia a sus credenciales en el recursoMongoDBSearchcomo se muestra a continuación.
El resto de esta página muestra cómo configurar cada modo de autenticación en el recurso MongoDBSearch y cómo confiar en el certificado de servidor mongod a través de TLS.
Configurar autenticación SCRAM
Proporcione un Kubernetes Secret que contenga la contraseña que mongot debe utilizar para autenticarse en mongod. Haga referencia al secreto en el recurso MongoDBSearch a través de spec.source.passwordSecretRef y establezca el nombre de usuario a través de spec.source.username.
spec: source: username: search-sync-source passwordSecretRef: name: my-mongot-password
El Secret referenciado debe contener la contraseña en una clave denominada password por defecto. Anule la clave a través de spec.source.passwordSecretRef.key si almacena la contraseña en una clave diferente.
El usuario identificado por spec.source.username ya debe existir en mongod y debe tener el rol searchCoordinator. Si omite spec.source.username, el operador de Kubernetes asume que el nombre de usuario es search-sync-source.
Para agregar mTLS de capa de red además de SCRAM, proporciona un Secret de Kubernetes que contenga el certificado de cliente y la llave privada y haz referencia a él a través de spec.source.tls.clientCertificateSecretRef. El Secret debe contener tls.crt y tls.key. El operador de Kubernetes presenta este certificado durante el protocolo de enlace TLS mientras se sigue autenticando mediante nombre de usuario y contraseña.
spec: source: username: search-sync-source passwordSecretRef: name: my-mongot-password tls: clientCertificateSecretRef: name: my-mongot-client-cert
Si la llave privada del cliente está cifrada, proporcione la frase de contraseña en un Secret separado y haga referencia a ella a través de spec.source.tls.keyFilePasswordSecretRef. El Secret debe contener la frase de contraseña en la llave keyFilePassword.
Configurar la autenticación X.509
La autenticación X.509 identifica mongot a mongod a través de un certificado de cliente en lugar de un nombre de usuario y una contraseña. El nombre distinguido (DN) del sujeto en el certificado se convierte en la identidad de mongot en mongod.
Nota
spec.source.x509 es mutuamente excluyente con spec.source.username y spec.source.passwordSecretRef. Si establece ambos, el operador de Kubernetes rechaza el recurso MongoDBSearch.
Proporcione un Secret de Kubernetes que contenga el certificado de cliente y la llave privada en las claves tls.crt y tls.key, y haga referencia a él en el recurso MongoDBSearch a través de spec.source.x509.clientCertificateSecretRef:
spec: source: x509: clientCertificateSecretRef: name: my-mongot-x509-cert
Si la llave privada del cliente está cifrada, proporcione la frase de contraseña en un Secret separado en la llave keyFilePassword y haga referencia a ella a través de spec.source.x509.keyFilePasswordSecretRef:
spec: source: x509: clientCertificateSecretRef: name: my-mongot-x509-cert keyFilePasswordSecretRef: name: my-mongot-key-password
El certificado de cliente por sí solo no otorga acceso: mongod debe reconocer su nombre distinguido de sujeto como una identidad autorizada. Después de crear el secreto del certificado anterior, autorice el nombre distinguido de sujeto de ese certificado en mongod como se describe a continuación.
Autorizar el nombre distinguido del sujeto X.509 en mongod
En el lado mongod, cree un usuario en la base de datos $external cuyo nombre coincida con el nombre distinguido del asunto en el certificado de cliente que aprovisionó anteriormente y conceda el rol searchCoordinator a ese usuario. mongod utiliza la base de datos $external para rastrear las identidades que se autentican a través de mecanismos externos como X.509. Para crear un usuario X.509 en una implementación que gestiona el operador de Kubernetes, consulte Autenticación segura de clientes con X.509.
También debe habilitar TLS en la implementación de mongod y configurarla para que confíe en la autoridad de certificación (CA) que firmó el certificado de cliente de mongot. Esto se configura en la propia implementación de mongod a través del recurso MongoDB o MongoDBCommunity, no del recurso MongoDBSearch. Para habilitar TLS en una implementación de mongod gestionada, consulte Asegurar las conexiones de clientes de clúster único (TLS/SSL).
Confiar en el certificado de servidor de mongod
La configuración anterior establece la identidad de mongot. Independientemente, cuando la fuente mongod utiliza TLS, mongot debe confiar en el certificado que mongod presenta cuando mongot se conecta a él. mongot es el cliente TLS en esta conexión; mongod presenta su certificado de servidor y mongot valida ese certificado con una CA que usted proporciona.
Cuando el origen mongod es externo al operador de Kubernetes (es decir, declarado a través de spec.source.external), proporcione la CA que emitió el certificado de servidor mongod:
spec: source: external: hostAndPorts: - mongod-0.example.com:27017 tls: ca: name: my-external-mongod-ca
El campo spec.source.external.tls.ca.name hace referencia a un secreto de Kubernetes ConfigMap que contiene el certificado de CA bajo la clave ca.crt. La CA debe ser la que emitió el certificado del servidor mongod.
Cuando el mongod de origen es gestionado por el operador de Kubernetes (a través de spec.source.mongodbResourceRef), el operador de Kubernetes gestiona esta confianza de CA por usted y el campo spec.source.external.tls.ca.name no se aplica.
Rotación de certificados
mongot lee su certificado de cliente al iniciar el proceso. Para rotar el certificado, actualice el Secret al que hace referencia spec.source.x509.clientCertificateSecretRef (para X.509) o spec.source.tls.clientCertificateSecretRef (para mTLS además de SCRAM) en el recurso MongoDBSearch. El operador de Kubernetes detecta el cambio y reinicia automáticamente los pods de mongot para cargar el nuevo material del certificado. Lo mismo se aplica a la contraseña SCRAM Secret a la que hace referencia spec.source.passwordSecretRef.
Para rotar un certificado de cliente X.509 en MCK:
Emita el nuevo certificado.
Emita un nuevo certificado de cliente con el mismo nombre distinguido del sujeto que el certificado que reemplaza, de modo que el usuario $external que creó en mongod no necesite cambiar. MongoDB recomienda ventanas de validez de al menos 30 días, ya que las ventanas más cortas aumentan la frecuencia de rotación.
Actualice el secreto.
Actualice el Secret al que hace referencia spec.source.x509.clientCertificateSecretRef con los nuevos valores tls.crt y tls.key. Si la llave privada está cifrada, actualice también el Secret al que hace referencia spec.source.x509.keyFilePasswordSecretRef con la nueva frase de contraseña en la llave keyFilePassword. El operador de Kubernetes detecta el cambio y reinicia automáticamente los pods mongot.
Remueve el certificado anterior.
Una vez que todos los pods se reinicien correctamente, revoca el certificado anterior en tu PKI. Si el certificado de reemplazo utiliza el mismo nombre distinguido de sujeto, no es necesario cambiar el usuario $external correspondiente en mongod. Remueva el usuario $external solo si también desea retirar esa identidad X.509 por completo.
La rotación automatizada no se puede configurar a través del CRD MongoDBSearch. Actualice el Secret al que hace referencia spec.source.x509.clientCertificateSecretRef para activar la rotación; el operador de Kubernetes reinicia los pods automáticamente.