Ir al contenido

TLS entre Odoo y PgBouncer: cuándo vale la pena (y cómo hacerlo bien)

22 de noviembre de 2025 por
TLS entre Odoo y PgBouncer: cuándo vale la pena (y cómo hacerlo bien)
Juan Manuel De Castro
| Todavía no hay comentarios

Cuando pones PgBouncer entre Odoo y PostgreSQL, ganas rendimiento y control… pero también agregas otro salto de red. La pregunta correcta no es “¿puedo activar TLS?”, sino:

¿me aporta seguridad real o solo complejidad?


1) Cuándo SÍ vale la pena activar TLS (Odoo → PgBouncer)

Actívalo si se cumple cualquiera de estos casos:

  • Odoo y PgBouncer están en hosts distintos y la red entre ellos no es 100% confiable (VPC compartida, red corporativa grande, cross-subnet, cross-AZ, cross-DC).

  • Hay requisitos de compliance (auditoría, SOC2/ISO, clientes enterprise): “encryption in transit”.

  • Estás en Kubernetes/infra multi-tenant y te preocupa sniffing lateral.

  • Tu threat model incluye MITM (DNS poisoning, route hijack). Para esto, TLS con verificación es clave. PostgreSQL explica que require cifra pero no protege contra MITM; verify-full sí. PostgreSQL


2) Cuándo NO vale la pena (o puedes simplificar)

  • Odoo y PgBouncer en el mismo host y puedes usar Unix socket (no hay tráfico “en red” como tal). En ese caso, normalmente priorizas hardening del host + permisos + firewall.

  • Tienes un túnel ya establecido (VPN/Service Mesh) que ya cifra y verifica identidades: TLS adicional puede ser redundante (aunque a veces compliance igual lo exige).


3) El punto diferencial: TLS “cifra” vs TLS “seguro de verdad”

En el mundo PostgreSQL/libpq (que es lo que usa Odoo/psycopg), los modos importan:

  • require: cifra, pero no valida el servidor → no previene MITM. PostgreSQL

  • verify-ca: cifra + valida CA (sin comprobar hostname) → mitigación parcial. PostgreSQL

  • verify-full: cifra + valida CA + valida hostname → el estándar recomendado en entornos sensibles. PostgreSQL

Odoo te deja elegir esto con db_sslmode (disable/allow/prefer/require/verify-ca/verify-full). Odoo


4) Configuración mínima recomendada (server TLS en PgBouncer + verify-full en Odoo)

A) PgBouncer: habilitar TLS para clientes (Odoo → PgBouncer)

En pgbouncer.ini:

[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432

# TLS desde clientes hacia PgBouncer
client_tls_sslmode = require
client_tls_key_file  = /etc/pgbouncer/tls/pgbouncer.key
client_tls_cert_file = /etc/pgbouncer/tls/pgbouncer.crt

# (opcional pero recomendado) limita protocolos
client_tls_protocols = secure

PgBouncer documenta que TLS de entrada está deshabilitado por defecto, y que al activarlo necesitas client_tls_key_file + client_tls_cert_file. PgBouncer

Si quieres mTLS (Odoo presenta certificado y PgBouncer lo valida), subes a client_tls_sslmode=verify-ca y defines client_tls_ca_file. PgBouncer


B) Odoo: forzar TLS y (idealmente) verificar el servidor

En odoo.conf:

[options]
db_host = pgbouncer.tu-dominio-interno
db_port = 6432
db_user = odoo
db_password = ********
db_sslmode = verify-full

Odoo soporta db_sslmode con esos valores desde hace años. Odoo


C) Entregar CA (y opcionalmente cert/llave) al cliente Odoo

Para verify-full necesitas que el cliente tenga el root CA. En libpq puedes pasarlo por parámetros o variables de entorno; el doc menciona sslrootcert/PGSSLROOTCERT y también sslcert/sslkey (PGSSLCERT/PGSSLKEY) si usas certificados cliente. PostgreSQL

Ejemplo (systemd para el servicio de Odoo):

Environment="PGSSLROOTCERT=/etc/odoo/tls/ca.crt"
# Si haces mTLS:
# Environment="PGSSLCERT=/etc/odoo/tls/client.crt"
# Environment="PGSSLKEY=/etc/odoo/tls/client.key"


5) “¿Y el segundo salto?” (PgBouncer → PostgreSQL)

Aunque el post es Odoo→PgBouncer, si PgBouncer y Postgres están separados, lo coherente es cifrar ambos saltos.

PgBouncer trae server_tls_sslmode para TLS hacia PostgreSQL (con verify-ca/verify-full y server_tls_ca_file). PgBouncer

Ejemplo:

[pgbouncer]
server_tls_sslmode = verify-full
server_tls_ca_file = /etc/pgbouncer/tls/pg-ca.crt


6) Coste real: el overhead existe (pero casi siempre compensa)

PostgreSQL lo dice claro: TLS añade overhead de cifrado y key-exchange; es un trade-off entre rendimiento y seguridad. PostgreSQL

En la práctica:

  • Si Odoo↔PgBouncer es LAN, el costo suele ser marginal.

  • Si estás en un entorno donde MITM o sniffing son amenazas reales, el costo vale la pena.

  • Si tu cuello de botella es DB/queries, TLS rara vez será “el” problema.


7) Checklist rápido para publicar (y no llevarte sorpresas)

  • En PgBouncer, client_tls_sslmode está activo y tienes client_tls_key_file + client_tls_cert_file. PgBouncer

  • En Odoo, db_sslmode=verify-full (o al menos require). Odoo+1

  • El hostname de db_host coincide con el SAN/CN del cert (si usas verify-full). PostgreSQL

  • El CA está disponible en Odoo (PGSSLROOTCERT o equivalente). PostgreSQL

  • Si también cifras PgBouncer→Postgres, configuraste server_tls_sslmode + CA. PgBouncer


Siguiente capítulo ->

TLS entre Odoo y PgBouncer: cuándo vale la pena (y cómo hacerlo bien)
Juan Manuel De Castro 22 de noviembre de 2025
Menos tareas repetitivas. Más Inteligencia Artificial.
Compartir
Etiquetas
Archivo
Iniciar sesión dejar un comentario