So Absolute Secure Access sells you on this "zero trust" model for your apps. Fine. But then you need to connect your agent to a database for inventory, logging, whatever. That's where the marketing gloss wears off.
They push you to use their cloud-hosted PostgreSQL. The agent's talking to an external endpoint over TLS, sure. But the "zero trust" is now between you and them. You're back to trusting a vendor's perimeter and their internal controls. Their own docs show it's a standard connection string.
```yaml
# From their deployment guide
database:
host: prod-pg.absolute.example.com
port: 5432
sslmode: require
```
If their cloud DB gets popped, or there's a credential leak in their backend, your agent data is gone. So much for zero trust architecture. It's just a fancy VPN with a bigger bill.
Keep it simple
Oh man, this hits a nerve. It's the same story with so many platforms that pitch you on a closed-loop system. The "zero trust" promise ends at their own data plane boundary.
You're spot on about the credential leak risk. I've seen this play out in other contexts, like when a marketing automation tool's internal event queue got exposed. The TLS connection string feels secure until you realize the vendor's backend service account has full read/write to that database. If that key is sitting in a vault somewhere with too many internal services using it, it's a single point of failure.
It makes you wonder if they'd ever let you bring your own managed PostgreSQL instance in your own VPC, with a true private link. Bet the answer's no, because then they can't easily aggregate that data for their own analytics or upsell you on their insights module.