Cloud SQL Proxy in GKE - A Complete Guide

Published on August 3, 2022

Safa Mulani

Cloud SQL Proxy in GKE - A Complete Guide

While we believe that this content benefits our community, we have not yet thoroughly reviewed it. If you have any suggestions for improvements, please let us know by clicking the “report an issue“ button at the bottom of the tutorial.

Hello, readers! This article talks about Cloud SQL Proxy setup in GKE with a practical demonstration.

If you’re looking for a managed Kubernetes hosting service, check out our simple, managed Kubernetes service built for growth.

So, let us begin! 😊

Advantages of Cloud SQL Proxy

With the applications moving to the paved way of modernization, the components of the applications are now moving to host the resources on public Cloud environments such as Google, Azure, Amazon, etc.

Crucial components such as databases, cache storage have now paved their way towards modernization.

Most of the applications are now being containerized to optimize and reduce the carbon footprint.

Looking at this scenario, there must be a way or a path to form a connection between the applications hosted as containers and the cloud database instances.

For the same, the Cloud SQL Proxy comes into the picture.

With Cloud SQL Proxy, we can initiate the connection between the containerized application and the cloud database instance.

We can also have a connection using the private IP address of the instance, but the below advantages incline us to use Cloud SQL Proxy as the way to connect your applications to the cloud database instances.

  • Establishes secure connections- The Cloud SQL proxy enables secure connections by encrypting the traffic from and to the database instances.
  • IAM based database authentication- It enables the authentication by using service accounts/workload identity and thus replicate the access through IAM.

Practical Implementation – Set up Cloud SQL Proxy as a container/pod in GKE

Below is the list of pre-requisites which building up a cloud SQL Proxy pod.

  • A full-fledged Google Kubernetes Engine Cluster with the kubectl tool installed.
  • In case we wish to use the connections over a private IP, we need to ensure that the Cloud SQL Proxy and the database instance share the same VPC network.
  • A Cloud SQL Instance (MYSQL, PostgreSQL, SQL Server)
  • An account in the PostgreSQL instance. The application running within the GKE cluster will make use of these account credentials to connect to the database.

Step 1: Create a secret with the database configurations

For our application running in the cluster, we will be configuring the cloud SQL proxy as a sidecar. In this scenario, the application will communicate to the database instance through the proxy itself.

We thus need to populate the database configuration values to the application container for it to connect to the customized database.

To do so, we need to create a secret in the same namespace which is shared by the application container as shown below-

kubectl create secret generic <YOUR-DB-SECRET> \
  --from-literal=username=<YOUR-DATABASE-USER> \
  --from-literal=password=<YOUR-DATABASE-PASSWORD> \

Step 2: Get the Cloud SQL Instance configuration values

To connect the application to the database Instance, we need to set up the Cloud SQL proxy either as a VM or as a container (sidecar). For the same, we require the below information about the Cloud SQL Instance-

  • The instance connection name
  • Enable the Cloud SQL Admin API in the project which holds your GKE cluster
  • The JSON key (credential) file of the service account which has necessary permission on the Google Project which holds the Cloud SQL Instance resource.

Step 3: Generate a Service account used for Cloud SQL Proxy to have it in GKE

To run a Cloud SQL Proxy instance within a GKE cluster, we need to create a service account and give it the necessary permissions.

It is recommended to use a separate service account for a separate application to have a more secure experience and transition.

Requirements of the service account-

  1. It must be created in the same project that runs the Cloud SQL Instance.
  2. It must be given at least a Cloud SQL Client IAM role.
  3. In the case of private IP usage for connection, the Cloud SQL Instance and GKE must share the same VPC network.

Once you create a service account, we need to mount the key of the service account into the Cloud SQL proxy container as a volume from a secret.

Let us understand this through the below example!

Create the credential key file using the gcloud command -

gcloud iam service-accounts keys create ~/key.json \


Create a k8 secret from the credential file -

kubectl create secret generic YOUR-SA-SECRET \


Use the above secret as a volume in the proxy container -




    secretName: <YOUR-SA-SECRET>

Step 4: Execute the Cloud SQL Proxy as a sidecar/pod

Once we reach Step 4, we need to create a sidecar proxy container within the application pod because of the below advantages-

  • Because of the IAM database permissions, using the sidecar reduces the exposure of the instance to the entire cluster.
  • It reduces and prevents the local exposure to the SQL outbound traffic by encrypting it.

Code -

apiVersion: apps/v1
kind: Deployment
        # ... other container configuration
        - name: DB_USER
              name: <YOUR-DB-SECRET>
              key: username
        - name: DB_PASS
              name: <YOUR-DB-SECRET>
              key: password
        - name: DB_NAME
              name: <YOUR-DB-SECRET>
              key: database
      - name: cloud-sql-proxy
        image: gcr.io/cloudsql-docker/gce-proxy:1.28.0 # make sure the use the latest version
          - "/cloud_sql_proxy"
          - "-ip_address_types=PRIVATE"

          # Replace DB_PORT with the port the proxy should listen on
          # Defaults: MySQL: 3306, Postgres: 5432, SQLServer: 1433
          - "-instances=<INSTANCE_CONNECTION_NAME>=tcp:<DB_PORT>"

          - "-credential_file=/secrets/service_account.json"
          runAsNonRoot: true
        - name: <YOUR-SA-SECRET-VOLUME>
          mountPath: /secrets/
          readOnly: true
            memory: "2Gi"
            cpu:    "1"
      - name: <YOUR-SA-SECRET-VOLUME>
          secretName: <YOUR-SA-SECRET>


By this, we have approached the end of this topic. Feel free to comment below in case you come across any questions.

For more such posts related to Cloud databases and Kubernetes native information, Stay tuned with us.

Till then, Happy Learning!! 😊


  1. About Cloud SQL Proxy
  2. Cloud SQL Proxy in GKE

Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.

Learn more about our products

About the authors
Default avatar
Safa Mulani


Still looking for an answer?

Ask a questionSearch for more help

Was this helpful?

Try DigitalOcean for free

Click below to sign up and get $200 of credit to try our products over 60 days!

Sign up

Join the Tech Talk
Success! Thank you! Please check your email for further details.

Please complete your information!

Featured on Community

Get our biweekly newsletter

Sign up for Infrastructure as a Newsletter.

Hollie's Hub for Good

Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.

Become a contributor

Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.

Welcome to the developer cloud

DigitalOcean makes it simple to launch in the cloud and scale up as you grow — whether you're running one virtual machine or ten thousand.

Learn more
DigitalOcean Cloud Control Panel