Passa al contenuto principale

mTLS topology Akira

Canonical pattern​

Akira usa mTLS per segmenti quando esiste un intermediary canonico:

Backend / workers
  |
  | TLS + client certificate
  v
PgBouncer
  |
  | TLS + client certificate
  v
PostgreSQL

PgBouncer resta parte della trust zone stateful e non viene bypassato per il traffico applicativo ordinario. Il backend, i worker e i job async continuano a usare PgBouncer sulla porta 6432; PgBouncer apre connessioni TLS proprie verso PostgreSQL 5432.

Rationale​

  • PgBouncer e' un connection pooler trusted intermediary: termina la sessione client e apre sessioni server separate verso PostgreSQL.
  • True end-to-end mTLS backend -> PostgreSQL e' incompatibile con il pooling in transaction mode, perche' PgBouncer deve vedere SQL plaintext per multiplexing e gestione delle transazioni.
  • Il placement corrente co-loca PgBouncer sui nodi DB, dentro il tier stateful raggiungibile via Tailscale.
  • Il beneficio operativo di PgBouncer, incluso il capacity gain documentato in TASK-170, prevale sulla purezza di un collegamento diretto backend -> database.

Non-pattern​

Non usare un bypass sistematico di PgBouncer per ottenere mTLS diretto backend -> PostgreSQL nel pilot. Quel pattern perderebbe il pooling in transaction mode e sposterebbe la gestione delle connessioni sui processi applicativi.

Le DSN dirette verso PostgreSQL 5432 restano ammesse per migration, DBA task e operazioni che richiedono una sessione Postgres stabile, come documentato in docs/architecture/connection-pooling.md.

Service identity​

step-ca emette certificati leaf separati per i ruoli interni:

  • backend.crt per backend e client applicativi su management;
  • pgbouncer.crt per PgBouncer come client verso PostgreSQL e server verso i client applicativi;
  • postgres.crt per PostgreSQL server TLS;
  • certificati dedicati per NATS, worker e bridge quando parlano con NATS o database.

Il controllo mTLS autentica ogni hop. Non promette cifratura applicativa end-to-end attraverso PgBouncer.