Cloud SQL Proxy in GKE - A Complete Guide

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> \
  --from-literal=database=<YOUR-DATABASE-NAME>

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 \

--iam-account=YOUR-SA-NAME@project-id.iam.gserviceaccount.com

Create a k8 secret from the credential file -

kubectl create secret generic YOUR-SA-SECRET \

--from-file=service_account.json=~/key.json

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

volumes:

- name: <YOUR-SA-SECRET-VOLUME>

  secret:

    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
metadata:
  name: <YOUR-DEPLOYMENT-NAME>
spec:
  selector:
    matchLabels:
      app: <YOUR-APPLICATION-NAME>
  template:
    metadata:
      labels:
        app: <YOUR-APPLICATION-NAME>
    spec:
      containers:
      - name: <YOUR-APPLICATION-NAME>
        # ... other container configuration
        env:
        - name: DB_USER
          valueFrom:
            secretKeyRef:
              name: <YOUR-DB-SECRET>
              key: username
        - name: DB_PASS
          valueFrom:
            secretKeyRef:
              name: <YOUR-DB-SECRET>
              key: password
        - name: DB_NAME
          valueFrom:
            secretKeyRef:
              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
        command:
          - "/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"
        securityContext:
          
          runAsNonRoot: true
        volumeMounts:
        - name: <YOUR-SA-SECRET-VOLUME>
          mountPath: /secrets/
          readOnly: true
        resources:
          requests:
            
            memory: "2Gi"
          
            cpu:    "1"
      volumes:
      - name: <YOUR-SA-SECRET-VOLUME>
        secret:
          secretName: <YOUR-SA-SECRET>

Conclusion

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!! 😊

References

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