For those that connect locally hosted data sources to Retool cloud, what are you doing to sleep at night, and not stay awake worried that your SQL Server or whatever is exposed to the internet? I've always just used on-prem retool to address this very concern, but I have some new use cases (thanks to the new pricing) that have me very very tempted to migrate to cloud.
I'm aware there is whitelisting Retool IPs. That's good, but I don't think good enough. I'm aware Retool can SSH tunnel through a Bastion server to a resource. Perhaps that, in combination with whitelisting, and using non-standard ports, is secure enough? That's what I'm trying to convince myself.
Are there any other approaches or counter-measures you guys are taking?
Generally, we've found that setting a strict allow-list of IPs with SSL/TLS and enforced certificates to avoid spoofing is sufficient.
Adding an SSH tunnel via bastion can absolutely work for extra buffer, though it does add a little extra risk to be vigilant of (for example, if that connection is compromised, would it allow the attacker to access other resources in the same network later?).
The use of non-standard ports can be helpful to evade general scanners just searching for e.g. 5432 across as many domains as possible.
An additional example here with Postgres, for instance, would be to spawn a limited user (only the read/write perms you would want to access via Retool, on the exact tables or schemas you want visible) with strong authentication, and edit the pg_hba.conf so that only the allowed IPs or CIDR ranges are trusted for that exact user - of course updating the firewalls similarly if you proxy through a bastion. That way, if those credentials were to be brute-forced, it still would fail off the IP check (and hopefully the added certificate verification). Naturally, this process will vary depending on the flavor of SQL or other resources you use, but it can be helpful for additional protection.
Hopefully this helps and let me know if you have any questions at all!
Thanks for the reply Victoria. I've arrived at the following setup in case it helps anyone else:
- Main data source is SQL Server within corporate intranet
- Linux Bastion server resides in DMZ, still behind firewall but on separate subnet
- Bastion server hardened (change SSH port, disable root user, disable terminal, disable password login, create retool user with no password using Retool public key authentication)
- Hole in firewall for traffic on non-standard SSH port to Bastion server, only from traffic originating from Retool IP whitelist
- Hole in firewall for only SQL traffic from only Bastion server to jump subnets to SQL server
- Retool resource set up to connect to Bastion before jumping to internal ip of SQL server
I'm sharing in case it helps someone else, but also if you or anyone sees a flaw please speak up.
I've got a test deployment up and running, now I need to try to get used to the additional query latency going from on-prem to cloud. Might have to be a little more careful with how often I hit the SQL server in my app design going forwards!