Add support for specifying custom credentials

[Anoupz]

Question

Getting this error

Not authorized to access resource. Possibly missing permission cloudsql.instances.get on resource

I am connecting with my service account and I verified that the user has cloudsql.admin. Any help?

Additional Context

[Anoupz]

The issue seems to be the auth being different. Can we update the connector instance to accept custom auth?

[edosrecki]

The issue seems to be the auth being different. Can we update the connector instance to accept custom auth?

I am curious, what do you mean by custom auth?

[Anoupz]

The issue seems to be the auth being different. Can we update the connector instance to accept custom auth?

I am curious, what do you mean by custom auth?

We have a service account, and our API impersonates the service account using cloud Impersonated. When we connect via the Impersonated service account using this connector we get 403 error since it defaults to application default login.

[edosrecki]

@Anoupz I don't fully understand your setup from the description that you provided.

However, Application Default Credentials support service account impersonation. For example, locally you can try it out by running:

gcloud auth application-default login --impersonate-service-account $SERVICE_ACCOUNT_EMAIL

Cloud SQL Node.js Connector uses standard google-auth-library, which supports Application Default Credentials JSON with service account impersonation.

There is also an example of Application Default Credentials file that uses impersonation.

This is something that I use and it works as expected.

[Anoupz]

Thanks @edosrecki.

I'm using a backend API in Node.js, and we make use of the Impersonated class provided by the google-auth-library. You can find more information about it here: https://cloud.google.com/nodejs/docs/reference/google-auth-library/latest/google-auth-library/impersonated

We utilize the authentication credentials generated by this instantiation of the Impersonated class across our various services to authenticate our service account. When it comes to testing our APIs locally, we establish a connection using our developer's gcloud credentials, and the API impersonates the service account, granting us access to cloud services.

To initiate this process, I execute the command gcloud auth application-default login, connecting with my developer account before starting the service. However, I've encountered an issue with the cloud-sql-nodejs-connector. It appears that even though the sqladmin-fetcher accepts loginAuth as an optional parameter, it defaults to using application default login.

https://github.com/GoogleCloudPlatform/cloud-sql-nodejs-connector/blob/main/src/sqladmin-fetcher.ts#L75

If the connector can indeed accept custom authentication and pass it down to the sqladmin-fetcher that would work. I was able to test it locally.
https://github.com/GoogleCloudPlatform/cloud-sql-nodejs-connector/blob/main/src/connector.ts#L155-L157

I am open to more ideas.

[edosrecki]

@Anoupz

Impersonated class is exactly what gets automatically instantiated by google-auth-library when you use Application Default Credentials in a way that I described. This is a feature of the google-auth-library to automatically decide which auth method to use based on the environment setup. Therefore I believe that your use case should already be supported.

loginAuth is currently accepted in the constructor only to be able to provide a mock implementation in tests.

[jackwotherspoon]

Hi @Anoupz, as @edosrecki mentioned, google-auth-library should be able to pick up impersonated credentials and set them as the Application Default Credentials.

To initiate this process, I execute the command gcloud auth application-default login

@Anoupz are you initializing this command with the --impersonate-service-account flag set as @edosrecki showed?

[Anoupz]

@edosrecki & @jackwotherspoon,
Our API operates using a service account (let's call it SA_A) to interact with our customers' Google services. We employ impersonation techniques by assuming the identity of another service account (let's call it SA_B). For each customer, SA_A connects to different SAs for enhanced security.
So here the impersonated auth is not the default auth. I need to use impersonated auth and connect to the customer cloud SQL instance.

Again thanks for all the help and info.