deepthi
commented
3 years ago As long as there is a default non-cloud option (which we provide with static auth), I don't see any objection to building optional dependencies on cloud specific libs. We should do plugin_xxx.go for the dependencies so that they can be turned off at build time if desired.
For users coming from RDS or Cloud SQL (and presumably Azure), there's a good chance that they are using native cloud IAM to connect to their db via proxy.
The benefits are that rather than forcing users to manually provision users or integrate Vault, we can increase ease of use and security by offloading that to the cloud provider. Rather than rotating passwords, this can use short-lived tokens. We already have the proxy layer, though typically not deployed as a sidecar as in some of these models.
We already have a similar plugin in spirit for LDAP auth https://github.com/vitessio/vitess/blob/9b09bfa2e4e208c58c9c3311ebc616d9bfa31a79/go/mysql/ldapauthserver/auth_server_ldap.go
A similar open source project was just released, written in Go, and targeting GCP. We should be able to either import some of their libraries directly, or at a minimum use it as a guide for implementation.
Are there any objections towards providing this built-in? Are there things I'm not considering? We're already importing both the AWS and GCP SDK, so there should be minimal increases in dependencies or cloud specific lock-in.