liveBook · Manning

Cloud SQL Auth proxy

As explained in Infrastructure as Code, Patterns and Practices: With examples in Python and Terraform

Cloud SQL Auth Proxy is software that provides authenticated connections from applications to Google Cloud SQL database instances without requiring direct database network access.

When an application connects to a database on localhost instead of using an IP address and credentials, the Cloud SQL Auth Proxy mediates the connection and authenticates to Cloud SQL. The server's service account therefore needs permission to access the database. section 11.2.2

Use the proxy as an operational dependency, not as an invisible application detail:

  • Trace the application's actual connection configuration before changing server permissions; production may use localhost through the proxy while testing connects directly with an IP address and password. section 11.2.2 section 11.2.3
  • Capture proxy installation and startup configuration in infrastructure as code so testing and production can reproduce the same dependency. section 11.3.1
  • Test the localhost configuration end to end, retain the service-account database permission the proxy requires, and push the reconciled configuration across environments. section 11.3.2

Promotions application

A production promotions application broke after its service account was removed because its application connected to localhost through the Cloud SQL Auth Proxy. Testing did not expose the dependency because it connected directly to the database. Reconstructing the production installation in a startup script, applying it through IaC, and updating testing to use localhost restored parity. section 11.2.2 section 11.2.3 section 11.3.1 section 11.3.2

Listing 11.3 Installing the Cloud SQL Auth proxy in the server startup script
class Module():
   def _startup_script(self):                                            #1
       proxy_download = 'https://dl.google.com/cloudsql/' + \            #2
           'cloud_sql_proxy.linux.amd64'                                 #2
       exec_start = '/usr/local/bin/cloud_sql_proxy ' + \                #3
           '-instances=${google_sql_database_instance.' + \              #3
           f'{self._environment}.connection_name}}=tcp:3306'             #3
 
       return f"""                                                       #4
       #!/bin/bash
       wget {proxy_download} -O /usr/local/bin/cloud_sql_proxy
       chmod +x /usr/local/bin/cloud_sql_proxy
      
       cat << EOF > /usr/lib/systemd/system/cloudsqlproxy.service        #5
       [Install]
       WantedBy=multi-user.target
 
       [Unit]
       Description=Google Cloud Compute Engine SQL Proxy
       Requires=networking.service
       After=networking.service
 
       [Service]
       Type=simple
       WorkingDirectory=/usr/local/bin
       ExecStart={exec_start}
       Restart=always
       StandardOutput=journal
       User=root
       EOF
 
       systemctl daemon-reload                                           #5
       systemctl start cloudsqlproxy                                     #5
       """
 
   def build(self):                                                      #6
       return [
           {
               'google_compute_instance': {                              #7
                   self._environment: {                                  #7
                       'metadata_startup_script': self._startup_script() #7
                   }                                                     #7
               }                                                         #7
           }
       ]

Inspect the startup-script listing to see proxy download, executable installation, TCP port configuration, and service setup represented as IaC. section 11.3.1

How Infrastructure as Code, Patterns and Practices: With examples in Python and Terraform covers it

How deep it goes
Explains connection flow, permissions, installation, and reconciliation, but stops short of proxy internals.
Examples
Uses a promotions application, localhost database configuration, service-account removal, and a startup-script installation.
What it assumes
Assumes familiarity with service accounts, database permissions, application configuration, and infrastructure as code.
What you can do after
Diagnose proxy-related failures, encode installation in IaC, and align testing and production configurations.
How it connects
Connects service accounts, least privilege, infrastructure as code, drift, and environment differences.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Infrastructure as Code, Patterns and Practices: With examples in Python and Terraform. The section links point to the parts of the book it draws on.