Para agentes de IA: hay un índice de documentación disponible en https://www.mongodb.com/es/docs/llms.txt — versiones en markdown de todas las páginas están disponibles agregando .md a cualquier ruta URL.
Docs Menu

Asegurar la conexión de MongoDB a la búsqueda

Esta página describe cómo configurar TLS para la conexión que mongod (o) mongos abre a mongot al ejecutar MongoDB Search y Vector Search con el operador de controladores de MongoDB para Kubernetes. En esta conexión, mongot ejecuta el servidor de escucha y mongod es el cliente. Se configura mediante el spec.security.tls bloque del MongoDBSearch recurso.

Esta página no describe la conexión que mongot establece con mongod para acceder a los datos de origen. Para obtener información sobre esa parte, incluyendo cómo mongot se autentica y cómo confía en el mongod certificado de origen, consulte la sección "Proteger la conexión entre la búsqueda y MongoDB".

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

El servidor de escucha mongot admite tres modos conceptuales:

Modo
Comportamiento

Desactivado

El servidor de escucha solo acepta conexiones en texto plano. Este es el comportamiento predeterminado cuando se omite spec.security.tls.

TLS

El servidor de escucha requiere conexiones cifradas con TLS desde mongod y presenta un certificado de servidor. Los clientes validan el certificado, pero no presentan sus propios certificados de cliente.

mTLS

El servidor de escucha requiere TLS y también que el cliente ()mongod presente un certificado que valide con una autoridad de certificación de mongot confianza. Se requiere mTLS cuando se mongod autentica en mongot con X.,509 ya que509 la autenticación X. implica que el cliente presente un certificado. Consulte la sección "Proteger la conexión de la búsqueda a MongoDB".

El operador de Kubernetes muestra esta configuración como un único spec.security.tls bloque. El servidor de escucha se ejecuta en modo mTLS cuando el origen mongod también utiliza TLS. En ese caso, mongot valida el certificado del cliente con la mongod CA del origen, no con una CA configurada spec.security.tls en. Para configurar esta relación de confianza, consulte la sección "Proteger la conexión de Search a MongoDB".

Para habilitar TLS en el servidor de escucha mongot, configure spec.security.tls.certsSecretPrefix en el recurso MongoDBSearch. El operador de Kubernetes busca material TLS en los recursos Secret de Kubernetes en el mismo espacio de nombres, por prefijo de nombre:

spec:
security:
tls:
certsSecretPrefix: my-mongot

Con el prefijo anterior, el operador de Kubernetes deriva los nombres de los secretos TLS agregando sufijos fijos al prefijo. Para un conjunto de réplicas, lee el par tls.crt y tls.key de un secreto my-mongot-<name>-search-cert llamado, donde <name> es metadata.name del recurso.MongoDBSearch Para todos los patrones de nomenclatura, incluidas las implementaciones de clústeres fragmentados, consulte spec.security.tls.certsSecretPrefix. En el modo mTLS, la CA que mongot usa para validar el mongod certificado de cliente de proviene de la mongod configuración TLS de la fuente, no de.spec.security.tls Consulte Proteger la conexión de Search a MongoDB.

Nota

spec.security.tls.certsSecretPrefix es el campo recomendado para nuevas implementaciones. El campo heredado spec.security.tls.certificateKeySecretRef.name sigue siendo compatible y tiene prioridad cuando ambos se configuran en el mismo recurso MongoDBSearch. Las implementaciones existentes en el campo heredado continúan funcionando sin cambios.

Las siguientes limitaciones se aplican a mongot TLS:

  • No hay conjuntos de cifrado configurables. Los conjuntos de cifrado que mongot negocia no se pueden configurar mediante el MongoDBSearch CRD ni la mongot configuración. El conjunto está fijo con los valores mongot con los que viene.

  • Sin soporte FIPS. mongot Esta versión no ofrece un modo TLS validado por FIPS.

  • No se requiere validación de nombre de host ni SAN en el servidor de escucha. mongot Valida que los certificados de cliente entrantes estén firmados por una CA de confianza, pero no valida el nombre de host del sujeto ni las entradas SAN del certificado. La autenticación en la ruta de escucha depende de la autoridad de certificación y de la autorización del DN del sujeto X.509 configurada en "Proteger la conexión de Search a MongoDB".

  • La versión mínima de TLS es 1.2. mongot No acepta conexiones TLS 1.0 ni 1.1.

La rotación de material TLS sigue el mismo procedimiento que la rotación de certificados de cliente: se actualiza el referenciado Secret y se reinician los mongot pods.Consulte la sección "Proteger la conexión de Search a MongoDB" para obtener más información sobre el procedimiento.

Advertencia

Habilitar TLS en una implementación en funcionamiento supone una interrupción breve pero real, no un cambio sinmongot problemas. El oyente gRPC de es binario: acepta texto plano o TLS, nunca ambos. El cambio de deshabilitado mongot a mongod searchTLSMode TLS combina y, y las nuevas consultas de búsqueda fallan temporalmente durante la transición. La rotación de certificados en una implementación que ya tiene TLS habilitado no presenta este problema, ya que el modo del oyente no cambia. Planifique una ventana de mantenimiento para la habilitación inicial de TLS.