While I enjoyed the read and protocol parsing is always an interesting exercise, I'm still left wondering why a proxy was deemed necessary. Why not parse the logs instead?
In my experience there is often shared users, e.g. a readonly user or even for maintenance/operational tasks ("I need to fix prod real quick") a shared admin user.
The idea of Kviklet as a tool is to not share the password for such a user but instead use Single Sign on for authentication. Meaning multiple users can use the same DB user but the execution of statements is still linked to their individual accounts (e.g. Google Account) in the audit-log.
Hope this makes sense?
Of course Kviklet isn't as mature yet but since I just want to target databases I think it has a bit of it's own niche.
Starting v16 they are switching to a commercial license.
It’s quite interesting to see how the market around access tooling is evolving. Especially now with the platform shift with AI
Teleport puts out 3 major releases a year (every 4 months) and supports versions back to N-2. So the v13 will be updated until May (v16's release) and v14 until September-ish (v17's release). Using v14 and prior is not a viable strategy for AGPL averse companies in the long run... unless they want to fork.
After September 2024, the Teleport options that will get updates are:
1. Compiling Teleport yourself under the terms of the AGPL
2. Use the pre-compiled Community Edition under its new commercial license (<100 employees and <$10MM)
3. Purchase a license (or Teleport Cloud tenant) under enterprise terms
The recent Teleport licensing changes are designed to:
1. Push business users in category 1 and 2 into category 3 and
2. Preempt having Teleport's value resold by a big cloud player like the AWS Elasticsearch/OpenSearch kerfuffle a while back.
Source: I work at Teleport, and while I had no say in the license change, I did keep an ear out as I care about our open source stance. It is part of what brought me to the company.