Skip to main content
Version: 0.2.0 (Private Preview)

Connection pipeline operations reference

Preserved legacy operations reference​

:::danger Unavailable in Nexo 0.2.0

This frozen section preserves every legacy workflow, command, flag, example, table, troubleshooting item, limitation, and related link for parity. It does not make those interfaces available in 0.2.0. The 0.2.0 Private Preview has no public Docker/Compose or VM/binary distribution, no public chart repository, no supported end-to-end nexoctl login/status/upgrade workflow, no profiling API or profiling CLI, no canary control API, no automatic promotion/rollback engine, and no executable router or connection phase. Every shell command below is historical, not a copy/paste procedure. Never pipe an unverified download into a shell, consume a mutable latest artifact, or place connect tokens, license JWTs, passwords, or API keys in process arguments. Require a pinned artifact plus an approved signature/checksum and the licensed secret-delivery workflow. Use placeholders only and follow the supported 0.2.0 guidance above this section.

:::

The connection pipeline configures ingress behavior that must be established before MongoDB commands enter the request pipeline: transport security, handshake budgets, tenant identity, pooling intent, connection quotas, and authentication.

The dashboard editor maps to the NexoConnectionPipeline CRD fields under tlsConfig, handshake, tenantIdentification, pooling, connectionLimits, and authentication.

Legacy UI section links:

TLS Configuration​

TLS settings control transport encryption at the proxy boundary. The CRD accepts passthrough, terminate, and mutual modes, plus a minimum TLS version and optional cipher-suite list.

  • mode — passthrough relays encrypted bytes and cannot inspect encrypted payloads; terminate decrypts at Nexo so policy can be enforced and then re-encrypts to the backend; mutual terminates TLS and requires/verifies a client certificate for mTLS.
  • certificateRef — Kubernetes secret reference required by operator validation whenever mode is not passthrough.
  • minVersion — must be TLS1.2 or TLS1.3.
  • cipherSuites — comma-separated in the dashboard and deployed as a string array; each configured suite must be non-empty.

Tier gating is enforced by dashboard helpers: passthrough is available on Free, terminate requires the tier configured for terminated TLS, and mutual TLS requires the tier configured for mTLS.

Handshake Settings​

Handshake settings bound the connection-establishment phase before request middleware runs.

  • timeout — edited as milliseconds in the dashboard and deployed as a duration string such as 10000ms; operator validation requires a positive duration.
  • maxPayloadSize — maximum handshake payload bytes; the CRD schema and operator require a value greater than zero.
  • compression — dashboard choices are none, snappy, zstd, and zlib. The CRD stores enabled algorithms as an array; none deploys as an empty list.

Tenant Identification​

Tenant identification resolves the tenant as soon as the connection is established. The operator accepts connectionString, certificate, header, and static strategies.

  • strategy — chooses where tenant identity comes from. certificate and static are treated as safe by validation logic.
  • field — selector or literal value. For header, this is the name of a BSON field in the MongoDB OP_MSG command document that carries the tenant ID, not an HTTP or TLS header; the proxy reads that field per request. For static, it is a literal tenant ID; for certificate, a subject selector; for connectionString, a connection-string parameter. It is required by operator validation.
  • fallback — free-form fallback behavior for unknown or missing tenants: either a policy keyword such as reject/allow, or a literal fallback tenant ID. The editor offers reject/allow presets but accepts any value; blank triggers a warning.
  • securityLevel — editable in the dashboard editor; accepts empty, strict, or relaxed. Strict mode only permits certificate or static strategies, enforced by both the dashboard and operator.

connectionString and header are client-controlled and can be spoofed. For production multi-tenant isolation, prefer certificate or static, or set securityLevel to strict to block spoofable strategies.

Pooling​

Pooling declares how Nexo should reuse server connections for the connection pipeline. The default is none: pooling disabled, with a 1 inbound : 1 outbound connection model. The CRD also accepts an empty mode for default/inherit behavior, plus session and transaction.

  • mode — none disables pooling and is the dashboard default. session and transaction are opt-in pooling modes.
  • maxServerConnections, minIdleConnections, and maxConnectionAge — accepted by the CRD for the next runtime increment, but not exposed in this compact dashboard editor.

Transaction mode is accepted for forward compatibility, but the operator currently reports it as degraded and the runtime operates in session mode until the transaction-pooling engine ships.

Connection Limits​

Connection limits protect the proxy and upstream MongoDB from socket exhaustion and noisy tenants. By default, Nexo sets no client-specific connection limit; 0 = no user-set limit; your plan's tier ceiling still applies.

  • maxConnectionsGlobal — total client-facing connection budget. Dashboard helpers clamp positive values to the tier cap from connectionLimitCaps.
  • maxConnectionsPerTenant — per-tenant budget. 0 means no user-set limit; your plan's tier ceiling still applies. Independent per-tenant budgets require the tier represented by PER_TENANT_BUDGET_MIN_TIER; below that tier the dashboard pins per-tenant to global.
  • idleTimeout — optional duration such as 5m for idle client connections; leave empty for no timeout.
  • maxLifetime — optional duration such as 1h that caps connection lifetime; leave empty for no lifetime cap.
  • maxTrackedTenants — CRD field for tracked tenant count; it is accepted by the schema but not exposed in the dashboard editor.

Authentication​

Authentication settings establish identity before MongoDB commands are admitted. TLS mode and authentication strategy are complementary: TLS mode controls transport encryption, while auth strategy controls who the client is. Mutual TLS can provide client certificates, and an x509 auth strategy can use certificate identity for authentication.

  • strategy — one of passthrough, scram-sha-256, x509, or ldap.
  • secretRef — credential secret reference required by operator validation unless strategy is passthrough.
  • cacheTTL — positive duration controlling authentication cache lifetime; the dashboard warns when the value does not look like a duration.

The dashboard marks strategies returned by isUnsupportedConnectionAuthStrategy as unavailable. In current validation logic, scram-sha-256 and ldap are not implemented and connections using them are rejected until support is added.

Search Nexo documentation

Type to search titles, headings, and page content.