Databases

The Bridge can broker access to seven database systems: MySQL, PostgreSQL, CockroachDB, SQL Server (MSSQL), Redis, MongoDB, and Cassandra. In every case the user reaches the database through a brokered, recorded session and never holds the real database credentials.

Each database can be offered two ways, and you can use either or both:

• Native mode - users point their normal database tool at a port on the Bridge. That can be a command-line client (mysql, psql, redis-cli, mongosh, and so on) or a graphical tool (DBeaver, TablePlus, MySQL Workbench, etc.). To the tool it looks like an ordinary database connection; the Bridge stands in the middle.
• Browser mode - users run queries in a built-in query window inside the Bridge web interface, with nothing to install.

Jump to an engine: MySQL · PostgreSQL · CockroachDB · SQL Server · Redis · MongoDB · Cassandra

The in-browser SQL client (auto-enabled)

There is no separate switch for the in-browser query window. It turns on automatically as soon as any database protocol has browser mode enabled. For example, enabling browser mode for PostgreSQL alone makes the in-browser SQL client available for it; adding MySQL browser mode extends the same client to MySQL too.

postgres:
  browser:
    enabled: true   # this alone activates the in-browser SQL client

How native mode works

Pick a port for the Bridge to listen on, then have users point their client at the Bridge instead of the real database. The default ports below match each database’s conventional port, so existing tools usually need only the address changed.

# MySQL example - connect the normal client to the Bridge
mysql -h bridge.example.com -P 3306 -u 'alice%mysql-primary.internal' -p

For native database clients, Bridge routes the session from the database username. Use <bridge-user>%<target-host> as the username so Bridge can match the checkout and connect to the approved target.

Who authenticates, and to what

By default the credential a database client sends is not checked by Bridge: the username identifies the checkout, the active checkout is the authorization, and Bridge connects to the target with the credential stored on that checkout. Clients that insist on a password can send any value. Access is controlled by which checkouts exist and by the network reaching the listener, so restrict the listener to the client ranges you expect.

PostgreSQL, CockroachDB and SQL Server checkouts can opt into ldap_auth_passthrough, which changes that for those checkouts only: Bridge then requires the connecting user to present their directory password, verifies it, and signs in to the target as them. Because it reads a real credential, it also requires the client to connect with encryption:

# PostgreSQL - the connection must be encrypted
psql "host=bridge.example.com port=5432 user=alice%pg-primary.internal dbname=appdb sslmode=require"

# SQL Server - likewise (add TrustServerCertificate=yes for a self-signed gateway cert)
sqlcmd -S bridge.example.com,1433 -U 'alice%mssql-primary.internal' -N -C

Both listeners now negotiate encryption with any client that offers it, whether or not passthrough is in use, so existing clients can encrypt their connection with no change. A client that cannot encrypt still connects in the clear - except against a passthrough checkout, which refuses it and says so.

Each database

MySQL

mysql:
  idle_timeout: 30m
  native:
    enabled: true
    listen: "3306"
  browser:
    enabled: true

PostgreSQL

postgres:
  idle_timeout: 30m
  native:
    enabled: true
    listen: "5432"
  browser:
    enabled: true

Native PostgreSQL checkouts may set ldap_auth_passthrough to sign in as the connecting user rather than a stored account. The target must accept a password: ldap in pg_hba.conf is the point of it, and password or md5 also work. scram-sha-256 is not supported for the backend login.

CockroachDB

CockroachDB speaks the PostgreSQL wire protocol but has its own conventional port.

cockroachdb:
  idle_timeout: 30m
  native:
    enabled: true
    listen: "26257"
  browser:
    enabled: true

SQL Server (MSSQL)

mssql:
  idle_timeout: 30m
  native:
    enabled: true
    listen: "1433"
  browser:
    enabled: true

Native SQL Server checkouts may set ldap_auth_passthrough to sign in with Windows Authentication as the connecting user, which suits targets that grant access by AD group and store no SQL login. Bridge verifies the user’s directory password and then uses it to compute the logon response, so the password itself is never sent to the target. Set target_domain, or put the domain in target_username as DOMAIN\user.

Redis

redis:
  idle_timeout: 30m
  native:
    enabled: true
    listen: "6379"
  browser:
    enabled: true

MongoDB

mongodb:
  idle_timeout: 30m
  native:
    enabled: true
    listen: "27017"
  browser:
    enabled: true

Cassandra

cassandra:
  idle_timeout: 30m
  native:
    enabled: true
    listen: "9042"
  browser:
    enabled: true

Mixing modes

You can enable native for some databases and browser for others, or both for the same database. This example offers PostgreSQL through users’ own tools, MySQL through the browser, and Redis through both.

postgres:
  native:
    enabled: true
    listen: "5432"

mysql:
  browser:
    enabled: true

redis:
  native:
    enabled: true
    listen: "6379"
  browser:
    enabled: true

Option reference

Each database protocol exposes the same three-part structure. The default native port differs per database.