/ /

Secure the Connection from MongoDB to Search

This page describes how to configure TLS for the connection that mongod (or mongos) opens to mongot when you run MongoDB Search and Vector Search with the MongoDB Controllers for Kubernetes Operator. On this connection, mongot runs the listen server and mongod is the client. You configure it through the spec.security.tls block of the MongoDBSearch resource.

This page does not cover the connection that mongot opens to mongod to source data. For that direction, including how mongot authenticates and how it trusts the source mongod's certificate, see Secure the Connection from Search to MongoDB.

For the full schema of each MongoDBSearch setting referenced on this page, see MongoDB Search and Vector Search Settings.

TLS Modes

The mongot listen server supports three conceptual modes:

Mode	Behavior
Disabled	The listen server accepts plaintext connections only. This is the default when `spec.security.tls` is omitted.
TLS	The listen server requires TLS-encrypted connections from `mongod` and presents a server certificate. Clients validate the certificate but do not present client certificates of their own.
mTLS	The listen server requires TLS and also requires the client (`mongod`) to present a certificate that `mongot` validates against a trusted certificate authority. mTLS is required when `mongod` authenticates to `mongot` with X.509, because X.509 authentication is the client presenting a certificate. See Secure the Connection from Search to MongoDB.

The Kubernetes Operator surfaces this configuration as a single spec.security.tls block. The listen server runs in mTLS mode when the source mongod also uses TLS. In that case, mongot validates the client certificate against the source mongod's CA, not against a CA configured on spec.security.tls. To configure that trust, see Secure the Connection from Search to MongoDB.

Configure the Listen Server Certificate

To enable TLS on the mongot listen server, set spec.security.tls.certsSecretPrefix on the MongoDBSearch resource. The Kubernetes Operator looks up TLS material from Kubernetes Secret resources in the same namespace, by name prefix:

spec:
  security:
    tls:
      certsSecretPrefix: my-mongot

With the prefix above, the Kubernetes Operator derives TLS secret names by appending fixed suffixes to the prefix. For a replica set, it reads the tls.crt and tls.key pair from a secret named my-mongot-<name>-search-cert, where <name> is metadata.name of the MongoDBSearch resource. For all naming patterns, including sharded cluster deployments, see spec.security.tls.certsSecretPrefix. In mTLS mode, the CA that mongot uses to validate mongod's client certificate comes from the source mongod's TLS configuration, not from spec.security.tls. See Secure the Connection from Search to MongoDB.

Note

spec.security.tls.certsSecretPrefix is the recommended field for new deployments. The legacy spec.security.tls.certificateKeySecretRef.name field is still supported and takes precedence when both are set on the same MongoDBSearch resource. Existing deployments on the legacy field continue to work without changes.

Known Limitations

The following limitations apply to mongot TLS:

No configurable cipher suites. The cipher suites that mongot negotiates are not configurable through the MongoDBSearch CRD or the mongot configuration. The set is fixed at the values mongot ships with.
No FIPS support. mongot does not provide a FIPS-validated TLS mode at this release.
No hostname or SAN validation on the listen server. mongot validates that incoming client certificates are signed by a trusted CA, but does not validate the subject hostname or SAN entries on the certificate. Authentication on the listen path relies on the certificate authority and on the X.509 subject DN authorization configured in Secure the Connection from Search to MongoDB.
Minimum TLS version is 1.2. mongot does not accept TLS 1.0 or 1.1 connections.

Rotating TLS material is the same flow as rotating client certificates: update the referenced Secret and restart the mongot pods. See Secure the Connection from Search to MongoDB for the procedure.

Warning

Enabling TLS on a running deployment is a brief but real outage, not a seamless change. mongot's gRPC listener is binary: it accepts either plaintext or TLS, never both. Switching from disabled to TLS rolls mongot and mongod's searchTLSMode together, and new search queries fail temporarily during the cutover. Rotating certificates on a deployment that already has TLS enabled does not have this gap, because the listener mode does not change. Plan a maintenance window for the initial TLS enablement.

Back

Configure Automated Embedding

Configure Security: Search to MongoDB