feat: TLS support for multi-tenant connection managers (MongoDB, RabbitMQ, Redis, PostgreSQL)

[gandalf-at-lerian]

Context

The multi-tenant connection managers in commons/tenant-manager/ currently lack TLS support for production deployments. In a multi-tenant architecture where each tenant may have isolated infrastructure (dedicated databases, message brokers), TLS is required to secure inter-service communication.

This was identified during the clotilde-dev stabilization (March 2026) while fixing the AllowInsecureHTTP gap in the consumer (#357).

Current State

Component	TLS Ready	Details
MongoDB	❌ No	MongoDBConfig has no TLS fields. MongoConnection.Connect() passes only URI/Database/MaxPoolSize to mongolib.NewClient — no TLS parameters.
PostgreSQL	⚠️ Partial	PostgreSQLConfig has SSLMode field, but no enforcement when multi-tenant is active. Missing sslrootcert, sslcert, sslkey fields.
RabbitMQ	⚠️ Partial	WithTLS() option exists (switches amqp:// → amqps://), but it is global — not per-tenant. RabbitMQConfig has no certificate fields.
Redis/Valkey	❌ No	commons/tenant-manager/valkey/ only handles key prefixing. No tenant-aware connection manager exists. Each service manages its own Redis client externally.

Proposed Changes

1. MongoDB (commons/tenant-manager/core/types.go + mongo/manager.go)

Add TLS fields to MongoDBConfig:

type MongoDBConfig struct {
    // ... existing fields ...
    TLS           bool   `json:"tls,omitempty"`
    TLSCAFile     string `json:"tlsCAFile,omitempty"`
    TLSCertFile   string `json:"tlsCertFile,omitempty"`
    TLSKeyFile    string `json:"tlsKeyFile,omitempty"`
    TLSSkipVerify bool   `json:"tlsInsecureSkipVerify,omitempty"`
}

Propagate to MongoConnection.Connect() → mongolib.NewClient().

2. PostgreSQL (commons/tenant-manager/core/types.go)

Add certificate fields:

type PostgreSQLConfig struct {
    // ... existing fields ...
    SSLRootCert string `json:"sslrootcert,omitempty"`
    SSLCert     string `json:"sslcert,omitempty"`
    SSLKey      string `json:"sslkey,omitempty"`
}

Consider enforcing sslmode != "disable" when multi-tenant mode is active (at least a warning log).

3. RabbitMQ (commons/tenant-manager/rabbitmq/manager.go + core/types.go)

Add per-tenant TLS config:

type RabbitMQConfig struct {
    // ... existing fields ...
    TLS       bool   `json:"tls,omitempty"`
    TLSCAFile string `json:"tlsCAFile,omitempty"`
}

Move TLS decision from global WithTLS() to per-tenant config (fall back to global when per-tenant is not set).

4. Redis/Valkey

Evaluate whether a tenant-aware Redis connection manager is needed, or if the current model (shared Redis, tenant-scoped keys via valkey.GetKeyFromContext) is sufficient for production. If dedicated Redis per tenant is required, a manager similar to MongoDB/RabbitMQ is needed with TLS support.

Impact

• Without this: multi-tenant deployments in production use plaintext connections between services and tenant infrastructure — unacceptable for fintech/regulated environments.
• With this: each tenant's database/broker connections can enforce TLS independently, matching the isolation guarantees of the multi-tenant architecture.

Related

• feat: add AllowInsecureHTTP option to MultiTenantConsumer config #357 — AllowInsecureHTTP for consumer (HTTP layer, merged)
• fetcher-worker CrashLoopBackOff on clotilde-dev (resolved via HTTPS workaround + ServiceAPIKey fix)

[gandalf-at-lerian]

Requested by @brunobls — reach out to him for context on the production requirements and prioritization.