Make user optional when passing enable_iam_auth

[aebrahim]

Feature Description

If I'm using this in an environment like cloud run, there really only is one account - the currently active service account. I think the default assumption is that the user that is going to be doing the proxying is also the one that is being logged in, so it's quite redundant to have to get the current service account, and then chop off the gserviceaccount.com as required.

A cleaner API would be to simply no longer have user required when enable_iam_auth is passed, and have the connector correctly detect service account emails and appropriately chop them, cleanly abstracting away the internals.

That would take the common use case from

account = detect_account()
if account.endswith(".iam.gserviceaccount.com"): 
    account = account.replace(".gserviceaccount.com", "")
connector.connect(MY_DB_STR, "pg8000", user=account, db=MY_DB, enable_iam_auth=True)

to the extremely elegant connector.connect(MY_DB_STR, "pg8000", db=MY_DB, enable_iam_auth=True)

Alternatives Considered

We could continue to keep this redundant, but it's forcing the calling code to still be dealing with GCP internals.

Thank you for your consideration :P

[jackwotherspoon]

Hi @aebrahim, thanks so much for raising the feature request! We appreciate you taking the time in helping to better the Python Connector :)

This is a very interesting idea that I definitely see the benefit in having. Not only would it make it easier to use IAM AuthN but it would also allow for us to abstract away certain database specific IAM email considerations (Postgres removes the .gserviceaccount.com, MySQL removes everything after the @ symbol) allowing the user to interact with each in the same way.

However, implementation wise this is slightly trickier to achieve. The default credentials object used by the connector for authentication don't always have an email attribute associated with them. It does for service account credentials (so would work for Cloud Run, Cloud Functions, or when someone uses a service account key directly) but for credentials sourced from users logged in via gcloud etc. there is not an email attribute.

I will discuss with the rest of the team if the service account use-case justifies the feature and how we would handle the user case.

I will keep you posted if the feature begins to be worked on and if I have any further questions regarding the feature request.

Thanks again for raising this and have a great day!

Jack