Cloud iam auth #13
Cloud iam auth #13
Conversation
|
|
||
| ### [go-cloud](https://github.com/google/go-cloud) | ||
|
|
||
| Provides [IAM auth for GCP Cloud SQL](https://github.com/google/go-cloud/blob/master/postgres/gcppostgres/gcppostgres_test.go#L54), but not [AWS RDS](https://github.com/google/go-cloud/issues/3069). |
There was a problem hiding this comment.
go-cloud does support AWS RDS. This issue is outdated and has since been closed.
There was a problem hiding this comment.
There some support for RDS, but it is not complete (see my other comment), final comment on the issue also implied that they did not intend to add the IAM auth
|
|
||
| ## Implementation | ||
|
|
||
| Authentication would need to be implemented for both databases supported by openFGA: postgres and mysql. |
There was a problem hiding this comment.
As a maintainer team we're worried about introducing these cloud specific database connection functionalities in OpenFGA, because it will be cumbersome to manage. Depending on more of a community driven and community based standard for this functionality would be preferable as it allows our maintainer team to leverage a larger community to help evolve and maintain these cloud IAM mechanisms.
For this reason, we'd like to see an exploration of the go-cloud CDK (mentioned in the Prior Art section below) before we proceed forward. Specifically,
-
Are there features/functionalities that the Go Cloud CDK does not address that are pertinent to the usage patterns for these proprietary cloud IAM protocols? If so, what are the limitations? For example, can you use the assumed role functionality of AWS IAM etc..
-
Does the usage of the cloud specific sql providers in the Go Cloud CDK necessitate a specific underlying driver (e.g. pgx, pql, etc..)? Or can you bring your own driver?
From the looks of it you can use whatever underlying driver you want (see https://github.com/google/go-cloud/blob/master/samples/guestbook/wire_gen.go#L16C34-L16C34 as an example). But this needs to be confirmed.
If you'd be willing to help with this discovery @KlausVii we'd really appreciate it. If not though, our next step as a maintainer team is to do some more discovery with the go-cloud SDK and see how it works for this use case.
We have used the go-cloud SDK elsewhere and have had positive experiences with it, so we at least have some confidence in it as a potential solution.
There was a problem hiding this comment.
The one feature missing from go-cloud is fetching the authentication token from AWS, which is used as the password for your db connection. The issue this causes is that the token is only valid for 15min and if it is not refreshed, new connections will fail after the token expires.
I dug through the go-cloud source code , and could not find any code for retrieving this token. They seem to only inject some certificates for the AWS connection and expect the user to provide the password (which will expire if not refreshed) at initialisation.
This is why the extra work is required for the AWS IAM auth.
As to using go-cloud as at the underlying db driver for all the implantations, that should work just fine, it just does not provide a full end to end solution for AWS like it does GCP (might be a bit of google bias given its a google library).
Do let me know if I missed something with go-cloud, happy to be proven wrong.
As far as the maintenance burden, it should not be too high. The auth token just needs be fetched, injected, and refreshed close to expiry; this amounts to about 80 LoC to keep up to date, and I imagine the AWS side will remain very stable.
My draft implementation is about an evening's of work away from completion, so if I've somewhat convinced you, I'd be happy get into shape and open up a PR to show what this whole thing would look like.
There was a problem hiding this comment.
Building an auth token using the AWS SDK indeed is pretty straight-forward: https://docs.aws.amazon.com/sdk-for-go/v2/developer-guide/sdk-utilities-rds.html
Adn IMO there's no need to use go-cloud for this (the related Prior Art section is more a red hering here), since pgx has the BeforeConnect and AfterRelease hooks precisely for this use-case: jackc/pgx#676
@KlausVii did you get around opening up your draft PR ? I'd be curious to have a look.
|
Nice work! Has there been any progress on adopting this? Eliminating passwords from connection strings is such a crucial task - it seems surprising to me that this isn't more of a priority for a component central to authorization! |
|
Any updates here - While I don't need AWS, I'd like to help out on using the same mechanism for Azure. |
|
Hello folks, a question about this PR came up on the CNCF Slack channel recently. I'll restate my response here to keep others informed. Basically, we have not prioritized this work. We have to ask someone new on the team to take a fresh look at the RFC and conversation because Jon Whitaker is not at Okta/Auth0 nor a maintainer anymore. This feature is still a need for us, but we will have to re-engage again before agreeing to an approach as Jon was the person most involved with this effort and we have lost some continuity without him. We currently don't have a timeline when we will pick this back up. |
4 participants
RFC for adding cloud provider auth to openfga
References
openfga/openfga#870
Review Checklist
main