Esta página describe la conexión que mongot abre con mongod (o) mongos para obtener datos de origen y leer el estado de replicación, para una implementación de MongoDB Search y Vector Search que se administra con el operador de controladores de MongoDB para Kubernetes. En esta conexión, mongot es el cliente y mongod es el servidor. Esta página explica cómo mongot se autentica con mongod (SCRAM o X.), el509 rol que mongot necesita su identidad y cómo confía mongod en el certificado del servidor a través de TLS.
Los usuarios de la aplicación nunca se conectan mongot directamente a. Para la conexión en sentido contrario (la que mongod abre al mongot servidor de escucha de), consulte la sección "Proteger la conexión de MongoDB a la búsqueda".
Para ver el esquema completo de cada MongoDBSearch configuración a la que se hace referencia en esta página, consulte la sección "Configuración de búsqueda de MongoDB y búsqueda vectorial".
Cómo mongot se autentica en mongod
Cuando mongot se conecta a mongod, se autentica como cliente de base de datos utilizando uno de dos modos mutuamente excluyentes:
Modo | Credencial | Utilizar cuando |
|---|---|---|
SCRAM | Nombre de usuario y contraseña | Tu despliegue |
X.509 | Certificado de cliente | Su organización proporciona certificados desde una infraestructura de clave pública (PKI) para los servicios de clúster, o bien los requisitos de cumplimiento dan preferencia a la identidad basada en certificados sobre las contraseñas. |
Puedes cambiar de modo posteriormente actualizando el recurso MongoDBSearch y permitiendo que el operador de Kubernetes reinicie los pods mongot. La identidad del lado mongodcon la que mongot se autentica no necesita cambiar si posee el rol requerido descrito 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 utiliza TLS. La activación de TLS para la búsqueda por primera vez provoca una interrupción breve pero real de las consultas, en lugar de un reinicio sin interrupciones. Prevea un breve tiempo de inactividad al realizar este cambio.Consulte la sección "Proteger la conexión de MongoDB a la búsqueda" para obtener información sobre el comportamiento durante la transición.
El rol que mongot necesita en mongod
Cualquiera que sea el modo que use mongot, la identidad con la que se autentica debe tener permiso para obtener datos y mantener el catálogo de búsqueda en mongod. Esa identidad debe tener el rol integrado searchCoordinator, que viene con MongoDB Server 8.2 y versiones posteriores, y que otorga solo los privilegios que requiere mongot.
Siempre creas esta identidad tú mismo; el controlador MongoDBSearch nunca la crea por ti. La forma en que la creas depende de si el operador de Kubernetes administra la fuente mongod:
Fuente administrada por el operador. Declara un usuario con el
searchCoordinatorrol y referencia una contraseñaSecret— en lauserslista de tuMongoDBCommunityrecurso para Community, o como unMongoDBUserrecurso independiente para Enterprise. El operador de Kubernetes aprovisiona ese usuario enmongodpor ti. Luego, referencias el mismo usuario ySecreten elMongoDBSearchrecurso paramongotque pueda autenticarse con él.Fuente externa. Cree el usuario y asígnele el
searchCoordinatorrol directamente en su propiamongodimplementación, luego haga referencia a sus credenciales en elMongoDBSearchrecurso como 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 del servidor mongod a través de TLS.
Configurar la autenticación SCRAM
Proporcione un Kubernetes Secret que contenga la contraseña que mongot debe usar 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 campo Secret al que se hace referencia debe contener la contraseña bajo una clave denominada password por defecto. Sobrescriba la clave mediante spec.source.passwordSecretRef.key si almacena la contraseña bajo una clave diferente.
El usuario identificado por spec.source.username debe existir previamente en mongod y debe tener el rol.searchCoordinator Si spec.source.username omite, el operador de Kubernetes asume que el nombre de usuario search-sync-source es.
Para agregar mTLS a nivel de red sobre SCRAM, proporcione un objeto Kubernetes Secret que contenga el certificado del cliente y la clave privada, y haga referencia a él a través de spec.source.tls.clientCertificateSecretRef. El objeto Secret debe contener tls.crt y tls.key. El operador de Kubernetes presenta este certificado durante el protocolo de enlace TLS, autenticándose 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 clave privada del cliente está cifrada, proporcione la frase de contraseña en un campo Secret separado y haga referencia a ella a través de spec.source.tls.keyFilePasswordSecretRef. El campo Secret debe contener la frase de contraseña de la clave keyFilePassword.
Configurar la autenticación X.509
La autenticación X.509 identifica a mongot ante mongod mediante 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 configura ambos, el operador de Kubernetes rechaza el recurso MongoDBSearch.
Proporcione un Kubernetes Secret que contenga el certificado de cliente y la clave privada bajo 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 clave privada del cliente está cifrada, proporcione la frase de contraseña en un campo Secret separado bajo la clave 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 del cliente por sí solo no otorga acceso: mongod debe reconocer su DN de sujeto como una identidad autorizada. Después de crear el secreto del certificado mencionado anteriormente, autorice el DN de sujeto de ese certificado en mongod como se describe a continuación.
Autorizar el DN del sujeto X.509 en mongod
En el mongod lado, cree un usuario en la $external base de datos cuyo nombre coincida con el DN del sujeto en el certificado de cliente que aprovisionó anteriormente y otorgue el searchCoordinator rol a ese usuario. mongod utiliza la $external base de datos para rastrear las identidades que se autentican a través de mecanismos externos como X..509 Para crear un509 usuario X. en una implementación administrada por el operador de Kubernetes, consulte Autenticación segura de cliente con X..509
También debe habilitar TLS en la mongod implementación y configurarla para que confíe en la autoridad de certificación (CA) que firmó el mongot certificado de cliente. Esto se configura en la mongod propia implementación a través del MongoDB MongoDBCommunity recurso o, no del MongoDBSearch recurso. Para habilitar TLS en una mongod implementación administrada, consulte Conexiones seguras de cliente de clúster único (TLS/SSL).
Confíe en el mongod certificado del servidor
La configuración anterior establece la identidad de mongot. De forma independiente, cuando la fuente mongod utiliza TLS, mongot debe confiar en el certificado que mongod presenta cuando mongot se conecta a ella. 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 proporcione.
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 del 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 ConfigMap de Kubernetes que contiene el certificado CA bajo la clave ca.crt. La CA debe ser la que emitió el certificado del servidor mongod.
Cuando la fuente mongod es administrada 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 referenciado por spec.source.x509.clientCertificateSecretRef (para X.509) o spec.source.tls.clientCertificateSecretRef (para mTLS sobre SCRAM) en el recurso MongoDBSearch. El operador de Kubernetes detecta el cambio y reinicia automáticamente los pods mongot para cargar el nuevo material del certificado. Lo mismo se aplica a la contraseña SCRAM Secret referenciada por spec.source.passwordSecretRef.
Para rotar un certificado de cliente X.509 bajo MCK:
Emitir el nuevo certificado.
Emita un nuevo certificado de cliente con el mismo nombre distintivo (DN) del sujeto que el certificado que reemplaza, para que el usuario $external que creó en mongod no necesite cambiar. MongoDB recomienda ventanas de validez de al menos 30 días, ya que ventanas más cortas aumentan la frecuencia de rotación.
Actualiza el secreto.
Actualiza el valor Secret al que hace referencia spec.source.x509.clientCertificateSecretRef con los nuevos valores tls.crt y tls.key. Si la clave privada está cifrada, actualiza también el valor Secret al que hace referencia spec.source.x509.keyFilePasswordSecretRef con la nueva contraseña de la clave keyFilePassword. El operador de Kubernetes detecta el cambio y reinicia automáticamente los pods mongot.
Retire el certificado antiguo.
Una vez que todos los pods se hayan reiniciado correctamente, revoque el certificado antiguo en su PKI. Si el certificado de reemplazo utiliza el mismo DN de sujeto, no es necesario cambiar el usuario $external correspondiente en mongod. Elimine el usuario $external solo si también desea retirar por completo esa identidad X.509.
La rotación automática 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 reiniciará los pods automáticamente.