Allowlists, SSH tunnels and read-only logins

For your IT team. What Halo needs to reach a database, what's available and what's planned, what Halo stores and how, and what it never does.

This page is for whoever looks after your organization's databases and network. Halo needs a read-only login and a host and port its servers can reach. Connections go out from Halo to your database, and there's nothing to install on your side.

Read-only logins

For PostgreSQL:

create role halo_reader login password 'use-a-long-random-password';
alter role halo_reader set default_transaction_read_only = on;

grant connect on database analytics to halo_reader;
grant usage on schema sales to halo_reader;
grant select on all tables in schema sales to halo_reader;
alter default privileges in schema sales grant select on tables to halo_reader;

Halo reads only what this role can read, so views and narrower grants limit it further. Pointing Halo at a read replica, if you have one, keeps its queries off your primary. For other sources, see Connect Amazon Redshift and Connect Dremio.

On PostgreSQL and Redshift, the connection test warns if the login is a superuser or can change data. To rotate the password, change it in your database, then type the new one on the connection's Settings tab.

IP allowlists

Decided: allowing Halo by IP address is a supported way to reach a database.

Not decided: the addresses. Halo doesn't have fixed outbound IP addresses yet, because they depend on how production hosting is finished, so there's no list for your firewall today.

If your policy requires an allowlist, use Contact Halo before connecting a production database. You can upload files with nothing open at all.

SSH tunnels

For a database Halo can't reach directly, a connection can go through a bastion host. It works for PostgreSQL, Redshift and Dremio. On the bastion, make a dedicated, unprivileged user that can only forward to your database's host and port.

1. In the connection's settings, open SSH tunnel and enter the Bastion host, Bastion port (22 by default) and Bastion user. The connection's host is then the database's address as the bastion sees it.

2. Add the Public key the section shows to that user's authorized_keys. Each organization has its own key, made the first time it's needed, and the private half stays sealed in Halo. To use your own instead, paste it into Your own private key, in OpenSSH or PEM format.

   restrict,port-forwarding,permitopen="db.internal:5432" ssh-ed25519 AAAA… halo

3. Choose Test connection. The first test stops and shows the fingerprint the bastion presented. Compare it with the bastion's own, from ssh-keygen -lf on its host key, and choose Trust this key only if they match.

4. On a new connection, test again, then save. On a saved one, save, then test.

Halo won't connect through a bastion until you've confirmed its key. If the key changes later, the connection stops and says so ("the bastion's host key changed, so Halo didn't connect"), until someone confirms the new one. If you replaced the key on purpose, that's all it needs. If you didn't, treat it as a warning.

TLS

TLS on a PostgreSQL or Redshift connection takes four modes. require, the default, encrypts without checking who the server is. verify-ca also checks the certificate, and verify-full also checks the host name. disable turns encryption off.

The verifying modes check against public certificate authorities, unless you add your own under TLS certificates:

What Halo stores

When Halo itself reads a connection's credentials, to open a connection for discovery or a job, the organization's audit log records it.

Storage and processing are in the US. Snapshots behind public links and embeds are also served through a global edge cache.

Halo doesn't hold a compliance certification such as SOC 2 yet. An external penetration test is planned before v1.

What Halo never does

• Write to your database. Every PostgreSQL and Redshift statement runs in a read-only transaction, so it's refused even if the login could write. On Dremio, Halo sends only reads, and the login's own rights are what Dremio enforces.

• Put values into SQL. Filters and parameters are bound separately from the statement.

• Show your password again, to you or to Halo's staff.

• Run without limits. Every statement has a timeout: 60 to 300 seconds for interactive queries, depending on plan, which also caps their rows.

What you'll see

On your database: on PostgreSQL and Redshift, sessions named halo, in application_name. Halo tests each connection about once an hour. When discovery runs, because someone started it or on its schedule, it profiles each table for up to a minute, sampling those over 100,000 rows.

In Halo: Owners and Admins can see connections being created, changed, tested and run through discovery in the audit log, with who did it. SQL previewed on a connection is recorded too, without its rows. So are Halo's staff opening your organization's content or viewing Halo Data as one of your members.