Esta página describe cómo configurar TLS para la conexión que mongod (o mongos) abre a mongot cuando ejecuta MongoDB Search y búsqueda vectorial con los controladores de MongoDB para el operador de Kubernetes. En esta conexión, mongot ejecuta el servidor de escucha y mongod es el cliente. Lo configura a través del bloque spec.security.tls del recurso MongoDBSearch.
Esta página no cubre la conexión que mongot abre a mongod para obtener datos. Para esa dirección, incluida la forma en que mongot se autentica y confía en el certificado de la fuente mongod, consulte Proteja la conexión de Search a MongoDB.
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.
Modos TLS
El servidor de escucha mongot admite tres modos conceptuales:
Modo | Comportamiento |
|---|---|
Desactivado | El servidor de escucha solo acepta conexiones de texto plano. Este es el valor por defecto cuando se omite |
TLS | El servidor de escucha requiere conexiones cifradas con TLS desde |
mTLS | El servidor de escucha requiere TLS y también requiere que el cliente ( |
El operador de Kubernetes muestra esta configuración como un único bloque spec.security.tls. El servidor de escucha se ejecuta en modo mTLS cuando el origen mongod también utiliza TLS. En ese caso, mongot valida el certificado de cliente con la CA del origen mongod, no con una CA configurada en spec.security.tls. Para configurar esa confianza, consulta Proteger la conexión de Search a MongoDB.
Configurar el certificado del servidor de escucha
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 de los recursos de Kubernetes Secret en el mismo namespace, por prefijo de nombre:
spec: security: tls: certsSecretPrefix: my-mongot
Con el prefijo anterior, el operador de Kubernetes deriva los nombres secretos de TLS agregando sufijos fijos al prefijo. Para un set de réplicas, lee el par tls.crt y tls.key de un secreto llamado my-mongot-<name>-search-cert, donde <name> es metadata.name del recurso MongoDBSearch. Para todos los patrones de nomenclatura, incluidas las implementaciones de clústeres particionados, consulte spec.security.tls.certsSecretPrefix. En el modo mTLS, la CA que mongot utiliza para validar el certificado de cliente de mongod proviene de la configuración TLS de la fuente mongod, no de spec.security.tls. Consulte Proteja 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 todavía es compatible y tiene prioridad cuando ambos se establecen en el mismo recurso MongoDBSearch. Las implementaciones existentes en el campo heredado continúan funcionando sin cambios.
Limitaciones conocidas
Se aplican las siguientes limitaciones a mongot TLS:
No hay conjuntos de cifrado configurables. Los conjuntos de cifrado que
mongotnegocia no se pueden configurar a través del CRDMongoDBSearcho la configuraciónmongot. El conjunto se fija en los valores con los que se envíamongot.Sin compatibilidad con FIPS.
mongotno proporciona un modo TLS validado por FIPS en esta versión.Sin validación de nombre de host o SAN en el servidor de escucha.
mongotvalida 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 en el certificado. La autenticación en la ruta de escucha se basa en la autoridad de certificación y en la autorización de nombre distinguido del sujeto X.509 configurada en Proteja la conexión de Search a MongoDB.La versión mínima de TLS es 1.2.
mongotno acepta conexiones TLS 1.0 o 1.1.
La rotación de material TLS es el mismo flujo que la rotación de certificados de cliente: actualice el Secret al que se hace referencia y reinicie los pods de mongot. Consulte Proteger la conexión de la búsqueda a MongoDB para conocer el procedimiento.
Advertencia
Habilitar TLS en una implementación en ejecución supone una breve pero real interrupción del servicio, no un cambio sin interrupciones. El listener gRPC de mongot es binario: acepta texto plano o TLS, pero nunca ambos. El cambio de deshabilitado a TLS fusiona mongot y el searchTLSMode de mongod, 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 esta brecha, ya que la moda del oyente no cambia. Planifica un periodo de mantenimiento para la habilitación inicial de TLS.