You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using the Connector in serverless environments where the CPU is throttled outside of request processing, the refresh cycle can break. This is a feature request to support a lazy refresh where the Connector retrieves a new certificate when the existing one is expired and a new connection attempt has started.
Reacted by fuelkoy, Rhys Streefland, Dinko Osrecki and Averi Kitsch
Hi @hessjcg, I'm just wondering if you'd be able to provide any indication of when this might be available please?
This is currently blocking us adopting the connector because we deploy lots of cloud functions and the cost to always allocate the CPU for all our functions would be prohibitive.
Hi @hessjcg, I'm just wondering if you'd be able to provide any indication of when this might be available please?
This is currently blocking us adopting the connector because we deploy lots of cloud functions and the cost to always allocate the CPU for all our functions would be prohibitive.
Hi @rstreefland! We just implemented this change in Java and Python, Node is up next on our list. We should be getting to it in the coming week or two. Once we do merge it, we will cut an immediate release to unblock you 😄
Hi @jackwotherspoon. Sorry to nag, but do you have an update on this one please? It's the last issue blocking us adopting this and IAM database authentication 🙏
Hi @jackwotherspoon. Sorry to nag, but do you have an update on this one please? It's the last issue blocking us adopting this and IAM database authentication 🙏
@hessjcg will be the one working on this, he has had some higher priority things take precedence recently. He should be able to give a more accurate timeline of when he will get to this. Hopefully soon 😄
@rstreefland are you connecting over Public IP or Private IP to your Cloud SQL instance(s)?
If you are connecting over Private IP I would recommend just connecting directly to the Private IP address (or DNS name if using PSC), it will give you reduced latency compared to using the Connector and I can even show you how to still get IAM database authentication with a direct connection. Let me know if this would help in the meantime.
I can even show you how to still get IAM database authentication with a direct connection
@jackwotherspoon We are connecting using Public IP currently, but could switch to Private IP if necessary. We're using Cloud Run and 2nd Generation Cloud Functions to serve our workloads and my current understanding is that IAM database authentication is not currently possible without using the connector? If you're able to share an alternative solution, that would be incredibly useful please.
We are connecting using Public IP currently, but could switch to Private IP if necessary.
For Public IP, we recommend using a Connector or the Cloud SQL Proxy for the security benefits so that is valid.
We're using Cloud Run and 2nd Generation Cloud Functions to serve our workloads and my current understanding is that IAM database authentication is not currently possible without using the connector? If you're able to share an alternative solution, that would be incredibly useful please.
While we haven't added these samples to our official Google Cloud docs (but we will be soon), for Private IP connections there is a way to do direct connections and configure IAM database authentication.
Essentially IAM database authentication boils down to using an IAM Principal's OAuth2 token as the database password. Most popular database drivers/packages allow having the password be a callable/function, we can use this to get a fresh OAuth2 token hence accomplishing IAM database authentication.
@jackwotherspoon Thanks for this. With this method, would the OAuth2 access token expiry need to be handled by my application code or does the node-postgres pool handle this?
I believe the pool will hopefully recycle the connection if the token is expired but I'm not 100% sure if it will.
You could guarantee a fresh token with a 3600s lifetime by creating a new GoogleAuth object inside the password function (not ideal but works).
This coupled with setting the maxLifetimeSeconds for the Pool to like 45 minutes should guarantee the token is valid for the lifetime of the connection. brianc/node-postgres#2698
Hello all. Unfortunately this feature will not be available in the near future. The implementation is not as straightforward as we anticipated.
The connector configures the database driver options to use the connector to create new sockets to the database. Currently, the Postgres and Mysql database drivers allow you to configure a function that returns a net.Socket. To create the socket, the connector needs to finish getting the connection info about the database instance. This is an asynchronous operation.
In order to make lazy refresh work, the connector would need to asynchronously check if the connection info is valid, loading it if needed, and then instantiate the net.TlsSocket. That would turn this into an
constoptions={stream: asyncfunction(){// Not Allowed!constconnectionInfo=awaitConnector.getOrLoadConnectionInfo(instanceName)returnnet.connect(connectionInfo.ipAddress)}}
Unfortunately the Postgres and MySQL database drivers can't use an async function here. Also, we don't want to implement a busy-wait loop for the connectionInfo promise, as it would be anti-idiomatic.
We are open to suggestions on how to implement this.
Hi again. We figured out how to wrap the socket returned from the stream() function so that the connector asynchronously refresh the instance connection info and then open a real socket. This is currently a work in progress in #426.
This will allow us to implement Lazy Refresh in the node connector soon.
Hello @hessjcg
Thanks for the provided explanation. However, it's been already over 1.5 years since we got the last update.
Can we expect the lazy refresh strategy to be implemented?
Activity
rstreefland commentedon Jun 12, 2024
Hi @hessjcg, I'm just wondering if you'd be able to provide any indication of when this might be available please?
This is currently blocking us adopting the connector because we deploy lots of cloud functions and the cost to always allocate the CPU for all our functions would be prohibitive.
jackwotherspoon commentedon Jun 12, 2024
Hi @rstreefland! We just implemented this change in Java and Python, Node is up next on our list. We should be getting to it in the coming week or two. Once we do merge it, we will cut an immediate release to unblock you 😄
rstreefland commentedon Jun 12, 2024
@jackwotherspoon Amazing, thank you!
rstreefland commentedon Jun 26, 2024
Hi @jackwotherspoon. Sorry to nag, but do you have an update on this one please? It's the last issue blocking us adopting this and IAM database authentication 🙏
jackwotherspoon commentedon Jun 26, 2024
@hessjcg will be the one working on this, he has had some higher priority things take precedence recently. He should be able to give a more accurate timeline of when he will get to this. Hopefully soon 😄
@rstreefland are you connecting over Public IP or Private IP to your Cloud SQL instance(s)?
If you are connecting over Private IP I would recommend just connecting directly to the Private IP address (or DNS name if using PSC), it will give you reduced latency compared to using the Connector and I can even show you how to still get IAM database authentication with a direct connection. Let me know if this would help in the meantime.
rstreefland commentedon Jun 26, 2024
@jackwotherspoon We are connecting using Public IP currently, but could switch to Private IP if necessary. We're using Cloud Run and 2nd Generation Cloud Functions to serve our workloads and my current understanding is that IAM database authentication is not currently possible without using the connector? If you're able to share an alternative solution, that would be incredibly useful please.
jackwotherspoon commentedon Jun 26, 2024
For Public IP, we recommend using a Connector or the Cloud SQL Proxy for the security benefits so that is valid.
While we haven't added these samples to our official Google Cloud docs (but we will be soon), for Private IP connections there is a way to do direct connections and configure IAM database authentication.
Here is an example for Postgres using the
node-postgrespackage.Essentially IAM database authentication boils down to using an IAM Principal's OAuth2 token as the database
password. Most popular database drivers/packages allow having thepasswordbe a callable/function, we can use this to get a fresh OAuth2 token hence accomplishing IAM database authentication.Hope this helps 😄
rstreefland commentedon Jun 26, 2024
@jackwotherspoon Thanks for this. With this method, would the OAuth2 access token expiry need to be handled by my application code or does the node-postgres pool handle this?
jackwotherspoon commentedon Jun 26, 2024
@rstreefland Great question!
I believe the pool will hopefully recycle the connection if the token is expired but I'm not 100% sure if it will.
You could guarantee a fresh token with a 3600s lifetime by creating a new
GoogleAuthobject inside the password function (not ideal but works).This coupled with setting the
maxLifetimeSecondsfor the Pool to like 45 minutes should guarantee the token is valid for the lifetime of the connection. brianc/node-postgres#2698hessjcg commentedon Jul 11, 2024
Hello all. Unfortunately this feature will not be available in the near future. The implementation is not as straightforward as we anticipated.
The connector configures the database driver options to use the connector to create new sockets to the database. Currently, the Postgres and Mysql database drivers allow you to configure a function that returns a
net.Socket. To create the socket, the connector needs to finish getting the connection info about the database instance. This is an asynchronous operation.To summarize the code as-is today:
In order to make lazy refresh work, the connector would need to asynchronously check if the connection info is valid, loading it if needed, and then instantiate the
net.TlsSocket. That would turn this into anUnfortunately the Postgres and MySQL database drivers can't use an async function here. Also, we don't want to implement a busy-wait loop for the connectionInfo promise, as it would be anti-idiomatic.
We are open to suggestions on how to implement this.
hessjcg commentedon Mar 11, 2025
Hi again. We figured out how to wrap the socket returned from the
stream()function so that the connector asynchronously refresh the instance connection info and then open a real socket. This is currently a work in progress in #426.This will allow us to implement Lazy Refresh in the node connector soon.
Vearthtek commentedon Feb 13, 2026
Hello @hessjcg
Thanks for the provided explanation. However, it's been already over 1.5 years since we got the last update.
Can we expect the lazy refresh strategy to be implemented?
DomGeoT commentedon Feb 26, 2026
Hi, any update on this?
prakashchokalingam commentedon Jul 3, 2026
Bumping this thread for an update.
yyzou-bot commentedon Jul 7, 2026
Hi we are evaluating the priority and will work on this issue soon.
fix: rebuild the Cloud SQL connector before its client cert goes stale
feat(server): add IAM database helpers to the server stacks (#6)