0

I am following the Google Cloud Platform's guide for connecting to a Cloud SQL instance through a GKE cluster using Cloud SQL Proxy and a Public IP address (https://cloud.google.com/sql/docs/postgres/connect-kubernetes-engine). However, after trying to deploy my application I get the following error in my container logs.

{ Error: connect ECONNREFUSED 127.0.0.1:5432
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1107:14)
  errno: 'ECONNREFUSED',
  code: 'ECONNREFUSED',
  syscall: 'connect',
  address: '127.0.0.1',
  port: 5432 }

Followed by the error message

2021/02/01 05:35:31 the default Compute Engine service account is not configured with sufficient permissions to access the Cloud SQL API from this VM. Please create a new VM with Cloud SQL access (scope) enabled under "Identity and API access". Alternatively, create a new "service account key" and specify it using the -credential_file parameter

In addition (and I assume related) when I check my compute engine for the node in the cluster I see that the Cloud SQL Cloud API access scope is disabled. Is there a way to enable this?

I am aware that there are multiple ways to connect to a Cloud SQL Instance through a GKE cluster, however, I would like to use workload identity over a credentials file.

Jest Games
  • 365
  • 3
  • 11

2 Answers2

2

I've faced the similar exception while following the guide Connect to Cloud SQL for MySQL from Google Kubernetes Engine

Finally, it has turned out, that Workload Identity was not enabled fully on my Kubernetes cluster. So, in case of using Workload Identity approach, you should ensure:

  1. Workload Identity is enabled in your cluster settings. This was turned on in my case.

  2. Your node pool is also updated to use Workload Identity. If not, execute the following:

gcloud container node-pools update NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --zone=YOUR_CLUSTER_ZONE or --region=YOUR_CLUSTER_REGION \
    --workload-metadata=GKE_METADATA

After these steps my gke-sql deployment became green.

kolya_metallist
  • 589
  • 9
  • 20
0

If you don't use the default service account on your Compute Engine VM, you don't need to play with the scope of the VM. The scope are enforced only with the Compute engine default service account, with custom service account, they aren't.

If you use Workload identity on your cluster, it's the same thing (because it's not the Compute Engine default service account which is used but a custom one). And yes prefer this to Service Account key file.

guillaume blaquiere
  • 66,369
  • 2
  • 47
  • 76
  • 2
    I am using a kubernetes deployment similar to what is shown in GCP's guide and I have `serviceAccountName: `. My GSA is bound to my KSA and my KSA is annotated properly. Shouldn't this be specifying to use that service account instead of the default? – Jest Games Feb 02 '21 at 14:30
  • 1
    Is the Workload Identity installed on your Cluster? – guillaume blaquiere Feb 02 '21 at 15:59
  • 2
    It was, my issue was a typo in my deployment.yml... I was using `serviceAccount: ` instead of `serviceAccountName: `. – Jest Games Feb 03 '21 at 00:29
  • 1
    @JestGames Weird, I made the same exact mistake. Can't find an error in the documentation though – David Kamer May 13 '21 at 01:19