cloud-sql-proxy: Client fails on createEphemeral

I’m getting an odd failure from following these instructions:

https://github.com/GoogleCloudPlatform/cloudsql-proxy#to-use-from-kubernetes

2016/05/17 23:59:41 Listening on 127.0.0.1:3306 for <project>:<region>:<instance>
2016/05/17 23:59:41 Ready for new connections
2016/05/17 23:59:51 New connection for "<project>:<region>:<instance>"
2016/05/17 23:59:52 couldn't connect to "<project>:<region>:<instance>": ensure that the account has access to "<project>:<region>:<instance>" (and make sure there's no typo in that name). Error during createEphemeral for <project>:<region>:<instance>: googleapi: Error 403: The client is not authorized to make this request., notAuthorized

Looking at the code, createEphemeral is failing, but I’m at a loss as to what is going on with the randomized key that’s being created there.

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Reactions: 1
  • Comments: 54 (10 by maintainers)

Most upvoted comments

Thanks to the cloud-sql@google.com people it’s now working for me. The steps that fix it are:

1.- Go to the Cloud Project IAM page (Left Menu > IAM & Admin > IAM) 2.- Look for the row with the robot account that is having the issue. 3.- It should say “Cloud SQL Client” on the role column. 4.- Click on it to open the dropdown 5.- Click on the ‘Cloud SQL Client’ role that is checked to uncheck it. 6.- Click the blue save button above. 7.- Verify that the service account is removed from the IAM page. 8.- Click the Add button above in the same page. 9.- Enter the service account email address and select the Cloud SQL Client role 10.- Click Add 11.- The service account should appear again in the the list.

With this we are removing and then adding again the permissions for the service account.

It seems that you may have encountered a bug in our backend that is triggered when there is an old service account with the same name. We are investigating the issue and will work on a fix.

Maybe this can help somebody who still runs into this before the root cause gets fixed.

Just putting my voice out there, I was following this: https://cloud.google.com/sql/docs/mysql/connect-external-app#proxy

And was receiving the same error on the recommended role, only worked when I changed to Project Owner role.

@robbertvancaem - The problem for me was that service account related to the credentials file I was using was not added to the project. Once I added it the problem was gone.

Tow years later, and @chees solution is still relevant ! Thanks a lot!

@hfwang : Does the closing of this issue mean that it should be fixed? We are still having this problem, and I could solve it by following the steps that @chees wrote above.

@chees That “11 step process” you posted on Apr 26, 2017 fixed it for me. Thank you so much. I lost like 4 hours on this, taking apart my fucking cluster and putting it back together again over and over.

Please file a new issue since it appears to be a different issue (the given workarounds in this thread didn’t work); we can debug there.

I can confirm that the steps @chees just mentioned worked for me!! THANK GOD, a day lost but I’m GLAD it finally works. THANKS! ( plz fix so less people will throw themselves out of the window )

Ok, I understand. github issues here are about the sql proxy code, and not about operational issues in GCP.

I have reported this now here: https://issuetracker.google.com/issues/77939928

@chees god damn it you save me man

In IAM, the Service Account related to the project only had access to the Cloud SQL with a role of Editor. It did not yet have access to the actual project where the Service Account was used. A bit confusing, but adding the Service Account as a Project Editor as well resolved all my issues. Thanks for the help guys 😃

I’ve also been seeing this error over the past several days (running the proxy within Google Kubernetes Engine):

couldn't connect to "project:region:cloudsql-instance": ensure that the account has access to "project:region:cloudsql-instance" (and make sure there's no typo in that name). Error during createEphemeral for project:region:cloudsql-instance: googleapi: Error 403: The client is not authorized to make this request., notAuthorized

What’s odd is that it only crops up after the sql proxy instance has been running - successfully - for a while. Most recently, my service account had both roles/cloudsql.admin and roles/cloudsql.editor access on my project.

After the error began occurring, restarting the proxy didn’t change anything. Then I added roles/cloudsql.client and restarted my proxy and consumer, and I was able to successfully connect.

However, it seems like cloudsql.admin should have all of the access that cloudsql.client does. Furthermore, I then removed cloudsql.client (so my roles were exactly as they had been before), restarted the proxy, and things continued to work.

I wonder if this error could be caused by something independent of the permissions of the service account?

I have same problem. I’m sure project:region:cloudsql-instance is right format. My instance is second gen. MySQL 5.6

cloud_sql_proxy -dir=/tmp/cloudsql -instances=project:region:cloudsql-instance=tcp:3306 -credential_file=CloudSQL.json
2016/06/09 23:00:17 Listening on 127.0.0.1:3306 for project:region:cloudsql-instance
2016/06/09 23:00:17 Ready for new connections
2016/06/09 23:00:22 New connection for "project:region:cloudsql-instance"
2016/06/09 23:00:24 couldn't connect to "project:region:cloudsql-instance": ensure that the account has access to "project:region:cloudsql-instance" (and make sure there's no typo in that name). Error during createEphemeral for project:region:cloudsql-instance: googleapi: Error 403: The client is not authorized to make this request., notAuthorized

Client role should be sufficient. Did you save between removing & re-adding the Client role? The issue reported by others in this thread occurs when the name of a deleted service account is reused. Are you using a service account and if so, do you recall if you have previously delete one with the same name?

@laixer Thank you very much. Is there something else that Cloud SQL Viewer has that would make it work? It seems like there is something else in addition to Client (at least in my case).

I am just glad adding Viewer fixed the problem and hopefully that helps someone else out. I wish I had the time to fiddle with the custom roles and figure out what Viewer added that made it work. Sadly, I don’t think I’ll be able to do it within my deadline.

Thanks again.

Confirming @chees steps fixed the issue too, glad I found this post as I was stuck on this for a while. This really needs to be fixed asap !

Some clarification: ‘Cloud SQL Client’ is the right role to use for Proxy access. The initial release of the role was missing a permission which is why you might have run into issues when you first tried it. At this point, you should be able to switch back to using only the Cloud SQL Client role.

None of the other Cloud SQL roles include connectivity access, you always need Cloud SQL Client role if you plan to connect via the Proxy.