I can connect the Proxy from my account, but not from either of two service accounts that should also have access.

415 views
Skip to first unread message

James Lampert

unread,
Mar 22, 2018, 1:43:49 PM3/22/18
to Google Cloud SQL discuss
In all three cases, the proxy starts, and is waiting for connections. If I'm running the proxy as myself, I can connect just fine, whether from the default MySQL client, or from Sequel Pro, or from Squirrel. But if I'm running the proxy from either the default service account, or a service account I created specifically for this, the client gets:
MySQL said: Lost connection to MySQL server at 'reading initial communication packet', system error: 0
and the proxy shows: 
2018/03/22 09:38:23 New connection for "<REDACTED>"
2018/03/22 09:38:24 couldn't connect to "<REDACTED>": ensure that the account has access to "<REDACTED>" (and make sure there's no typo in that name). Error during createEphemeral for <REDACTED>: googleapi: Error 403: Access Not Configured. Cloud SQL Administration API has not been used in project 773874261491 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/sqladmin.googleapis.com/overview?project=<REDACTED> then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry., accessNotConfigured

I have:
Cloud SQL Admin
Cloud SQL Client
Compute Instance Admin (v1)
Compute Network Admin
Compute Security Admin
Deployment Manager Editor
Service Account Actor
Service Account Admin
Service Account Key Admin
Project IAM Admin
Storage Admin

The default service account has:
Cloud SQL Client
Editor

The service account I created has:
Cloud SQL Client 

At a suggestion to try re-enabling the Cloud SQL API, I had it disabled and re-enabled. No change. Still:

Jamess-Mac-mini:~ jamesl$ ./cloud_sql_proxy -instances=<REDACTED>=tcp:3306
2018/03/22 09:37:42 Listening on 127.0.0.1:3306 for <REDACTED>
2018/03/22 09:37:42 Ready for new connections
{Sequel Pro connected just fine}
2018/03/22 09:37:50 New connection for "<REDACTED>"
2018/03/22 09:37:52 New connection for "<REDACTED>"
2018/03/22 09:38:01 Client closed local connection on 127.0.0.1:3306
2018/03/22 09:38:01 Client closed local connection on 127.0.0.1:3306
^C
Jamess-Mac-mini:~ jamesl$ ./cloud_sql_proxy -instances=<REDACTED>=tcp:3306 -credential_file=<REDACTED my new service account>.json
2018/03/22 09:38:19 using credential file for authentication; email=<REDACTED my new service account>
2018/03/22 09:38:19 Listening on 127.0.0.1:3306 for <REDACTED>
2018/03/22 09:38:19 Ready for new connections
{Sequel Pro failed to connect}
2018/03/22 09:38:23 New connection for "<REDACTED>"
2018/03/22 09:38:24 couldn't connect to "<REDACTED>": ensure that the account has access to "<REDACTED>" (and make sure there's no typo in that name). Error during createEphemeral for <REDACTED>: googleapi: Error 403: Access Not Configured. Cloud SQL Administration API has not been used in project 773874261491 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/sqladmin.googleapis.com/overview?project=<REDACTED> then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry., accessNotConfigured
^C
Jamess-Mac-mini:~ jamesl$ ./cloud_sql_proxy -instances=<REDACTED>=tcp:3306 -credential_file=<REDACTED default service account>.json
2018/03/22 09:46:41 using credential file for authentication; email=<REDACTED default service account>
2018/03/22 09:46:41 Listening on 127.0.0.1:3306 for <REDACTED>
2018/03/22 09:46:41 Ready for new connections
{Sequel Pro failed to connect}
2018/03/22 09:46:45 New connection for "<REDACTED>"
2018/03/22 09:46:46 couldn't connect to "<REDACTED>": ensure that the account has access to "<REDACTED>" (and make sure there's no typo in that name). Error during createEphemeral for <REDACTED>: googleapi: Error 403: Access Not Configured. Cloud SQL Administration API has not been used in project <REDACTED> before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/sqladmin.googleapis.com/overview?project=<REDACTED> then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry., accessNotConfigured
^C

Dinesh (Google Platform Support)

unread,
Mar 22, 2018, 10:15:12 PM3/22/18
to Google Cloud SQL discuss
It would be worth to verify your service account has "Cloud SQL Client" access in IAM and "Cloud SQL API" has been enabled correctly. Suggestions provided here resolved a similar issue in the past. 

James Lampert

unread,
Mar 23, 2018, 1:22:49 PM3/23/18
to Google Cloud SQL discuss
On Thursday, March 22, 2018 at 7:15:12 PM UTC-7, Dinesh (Google Platform Support) wrote:
It would be worth to verify your service account has "Cloud SQL Client" access in IAM and "Cloud SQL API" has been enabled correctly. Suggestions provided here resolved a similar issue in the past. 

As Captain Kirk so pithily said, "This is damn peculiar."

According to the "IAM Dashboard," the service accounts have "Cloud SQL Client":

But according to the "Service Accounts" tab, and according to gcloud . . . get-iam-policy, they have NOTHING:

Jamess-Mac-mini:~ jamesl$ gcloud iam service-accounts get-iam-policy REDACTED-service@REDACTED.iam.gserviceaccount.com

etag: ACAB



Updates are available for some Cloud SDK components.  To install them,

please run:

  $ gcloud components update


Jamess-Mac-mini:~ jamesl$ gcloud iam service-accounts get-iam-policy REDACTED-com...@developer.gserviceaccount.com

etag: ACAB


 That could explain what's going on with the proxy, but can somebody explain why I'm getting contradictory information here?

James Lampert

unread,
Mar 23, 2018, 1:30:33 PM3/23/18
to Google Cloud SQL discuss
And I just tried removing and re-granting the role, from the IAM Dashboard. No change.

Dinesh (Google Platform Support)

unread,
Mar 24, 2018, 1:13:11 PM3/24/18
to Google Cloud SQL discuss
I know you mentioned to have "Project IAM Admin" role above, but please verify that again too. 
Having said that only "Owner" and "Project IAM Admin" (under "Resource Manager") have the privilege to grant a role to a service account.  If you have one of these roles and still getting different output from IAM Dashboard and "gcloud iam service-accounts get-iam-policy" command for concerned service account role, I will suggest raising this as a bug on Google public issue tracker which meant for issues and feature request tracking. 

James Lampert

unread,
Mar 26, 2018, 12:48:53 PM3/26/18
to Google Cloud SQL discuss
Verified. It's all in the picture, about three posts back. And there's already an issue-tracker, started by Pia Chamberalin, https://issuetracker.google.com/issues/76011694

I can't help wondering if there's something I need to do (but can't find), to grant specific access to the MySQL server. Or there's something needed besides "Cloud SQL Client."

James Lampert

unread,
Mar 26, 2018, 1:25:34 PM3/26/18
to Google Cloud SQL discuss

And as to my own permissions, 


James Lampert

unread,
Mar 26, 2018, 5:44:10 PM3/26/18
to Google Cloud SQL discuss
For lack of anything else to try, I tried creating a service account with exactly the same roles as my own account (listed in my previous post).

I got a "You do not have permission. . . ." message, and yet the service account got created ANYWAY, and the IAM Dashboard page shows all eleven roles for it.

But it didn't download a key on creation. I was, however, able to create and download a key from the "Create Key" function on the Service Programs page.

Same results as before.

James Lampert

unread,
Mar 27, 2018, 12:40:35 PM3/27/18
to Google Cloud SQL discuss
In Issue Tracker 76011694kv...@google.com asked:

James,

Did you enable the 'Cloud SQL' API, or the 'Cloud SQL Admin' API? I believe the second is needed for the proxy to authenticate.

That did it.

But the descriptive names of the APIs, as shown in both the Library page and the dashboard, are VERY confusing.

"sqladmin.googleapis.com" is called "Google Cloud SQL API," while "sql-component.googleapis.com" is called "Google Cloud SQL."

If the descriptive names were a better match for the actual service names, this probably would have been resolved last week.

Also, I'll note that the icons given in the API Library page are a bit confusing as well: the fact that some icons are in full color, while others are gray (and the lack of any other indication of enablement/disablement), gave both me and my boss the impression of indicating which ones were enabled and which ones were not, and the fact that it contradicted what was shown on the API Dashboard only added to the confusion.

Dinesh (Google Platform Support)

unread,
Mar 27, 2018, 12:54:10 PM3/27/18
to Google Cloud SQL discuss
You may want to try the solution provided by the development team on this PIT thread for the same issue. Try to enable 'Cloud SQL Admin' APIand let us know if that resolves proxy connection issue. If you are unable to do that with own account, I will suggest that to try to enable it with project owner account as described in this document. 

The PIT thread you suggested above seems for the same proxy connection issue as you reported on this group thread. If you getting inconsistent results from the gcloud command line and IAM console for the service account roles, I will suggest raising a fresh issue on PIT specifically from IAM roles to avoid any ambiguity. 

Dinesh (Google Platform Support)

unread,
Mar 27, 2018, 1:06:50 PM3/27/18
to Google Cloud SQL discuss
Seems like over posts just overlaps. I am glad your issue is resolved now.  
For the documentation naming issue, please report it via separate PIT thread.  

James Lampert

unread,
Mar 27, 2018, 1:08:59 PM3/27/18
to Google Cloud SQL discuss
On Tuesday, March 27, 2018 at 9:54:10 AM UTC-7, Dinesh (Google Platform Support) wrote:
You may want to try the solution provided by the development team on this PIT thread for the same issue. Try to enable 'Cloud SQL Admin' APIand let us know if that resolves proxy connection issue. If you are unable to do that with own account, I will suggest that to try to enable it with project owner account as described in this document. 

Yes. That's one of my Issue Trackers, and it solved the problem. And I've copied the solution over to a second Issue Tracker I'd started on that specific aspect of the problem, and commented that both could be marked as resolved, and I copied it back to this thread.

This problem was stagnant for so many days, it was a pleasant shock to see it suddenly get unstuck and resolved.

Thanks.

James Lampert

unread,
Mar 27, 2018, 5:50:52 PM3/27/18
to Google Cloud SQL discuss
Well, everything seems to work, both connecting via the Proxy from my desktop, and connecting via the Proxy from the template Compute instance.

Pia Chamberlain mentioned (in the Issue Tracker) that
The good news is that if your Compute Engine instance is in the same project as your Cloud SQL instance, authentication is taken care of.

Not quite "taken care of," because the Compute instance produced by the Google Click-to-Deploy Tomcat deployment didn't come with the "Cloud SQL" API Access Scope enabled. I had to stop the instance (thereby releasing its ephemeral external IP address), enable the needed access scope, restart it, and update my SSH session to point to the new ephemeral IP address. But at least that part was easy to figure out (and add to my own docs).

Once that small change was made, the Proxy no longer needed a credential to connect. Nice.

Dinesh (Google Platform Support)

unread,
Mar 28, 2018, 4:04:02 PM3/28/18
to Google Cloud SQL discuss
This is true as per the documentation. To change an instance's service account and access scopes, the instance must be temporarily stopped and restarted after the change. 

James Lampert

unread,
Mar 28, 2018, 4:10:45 PM3/28/18
to Google Cloud SQL discuss
On Wednesday, March 28, 2018 at 1:04:02 PM UTC-7, Dinesh (Google Platform Support) wrote:
This is true as per the documentation. To change an instance's service account and access scopes, the instance must be temporarily stopped and restarted after the change.

That was easy to find, probably the easiest part of this whole exercise. Didn't even need to look at the docs; The error messages told me what was wrong, and the "edit" page for the instance told me I had to stop the instance in order to add the scope.

Nonetheless, access from a Compute instance in the same project is only "taken care of" if you've got the requisite access scope enabled. :p
Reply all
Reply to author
Forward
0 new messages