Overview

Managing your sensitive information correctly is an essential part of creating asecure development workflow. For Cloud SQL, we recommend that you store your pieces of sensitive information as secrets that you create inSecret Manager. Secrets include API keys, passwords, sensitive information, or credentialsthat you might use to access a confidential system.

Secret Manager provides convenience and improves security. You canalso apply versioning to your secrets and share them across your team.To learn more about how to share secrets with your team, seeAccess control (IAM).

This page describes four use cases for using Secret Manager to manage secrets with Cloud SQL:

• Storingusernames and passwords
• Connecting toCloud SQL instances
• ManagingSSL/TLS certificates
• Coordinatingdisaster recovery scenarios

Before you begin

Before you begin using Secret Manager to handle secrets in Cloud SQL:

• Familiarize yourself with bothCloud SQLandSecret Manager.
• Get started with Cloud SQL by learning how toconnect to your first Cloud SQL instance from your local computer.

Usernames and passwords

Using Secret Manager to store the usernames and passwords of your Cloud SQLuser accounts as secrets is a safe and reliable way to manage this sensitive information.

First, you have to create a user in Cloud SQL. As part of creating this user, you have to supply a username and password. For more information about creating a user in Cloud SQL, seeCreate and manage users.

After the user is created, create a secret in Secret Manager to store the usernameand password. This ensures that this sensitive information won't be lost. Formore information about creating and accessing secrets in Secret Manager, seeCreating and accessing secrets.

Cloud SQL instances

When connecting to your Cloud SQL instance, you can use Secret Managerto manage secrets to create a secure development workflow.

Start by connecting to your Cloud SQL instance from your local computer. Afterthe instance is running, use environment variables to connect to it. Some valuesasociated with the variables are more sensitive, such as the instanceconnection name. For each value, you can create a secret in Secret Managerto store and manage this information. To learn more about using environmentvariables to connect to your Cloud SQL instance, seeConfigure and run sample app.

You can retrieve the instance connection name that's stored as a secret directlyfrom Secret Manager. This provides a flexible workflow that can help yourteam share this sensitive information across multiple applications and manage itfrom a centralized location. For more information on retrieving secretsfrom Secret Manager, seeCreate a secret with Secret Manager.

An application requires the information in the secrets to start. This informationincludes the values associated with the environment variables that are used to connect to theapplication. Your application accesses the secrets when it starts, and then uses the secretsto configure a connection to Cloud SQL. If any relevant secrets are updated in Secret Manager, then you might have to restart the application.

SSL/TLS certificates

If you connect to a Cloud SQL instance using a public or private IP address, then youshould use a Transport Layer Security (TLS) certificate which secures data whileit's transmitted. Each TLS certificate includes a public key certificate and aprivate key. For more information on configuring TLS certificates, seeConfigure SSL/TLS certificates.

You can save the TLS certificate, public key certificate, and private key assecrets to keep them safe and share them with your team. For more information on creating and accessing secrets, seeCreate a secret with Secret Manager. For more information onsharing secrets, seeAccess control (IAM).

Disaster recovery scenarios

If a primary instance in Cloud SQL fails, then you might promote a read replicato the primary instance. After the read replica becomes the primary instance, you mustupdate the instance connection name to reflect this promotion. If the instance connectionname is stored in a secret, then you must update the secret with the nameof the new primary instance. For more information, seeEdit a secret.

One way to use Secret Manager for failovers is to store the name of yourprimary instance in a secret, and then configure your Cloud SQL connector tobe updated whenever the secret is updated.

You can use the following bash wrapper script with the Cloud SQL Auth proxy todetect when the value for the instance connection name is updated, and then restartthe proxy with the new value:

#!/bin/bashSECRET_ID="my-secret-id"# TODO(developer): replace this valueREFRESH_INTERVAL=5PORT=5432# TODO(developer): change this port as needed# Get the latest version of the secret and start the proxyINSTANCE=$(gcloudsecretsversionsaccess"latest"--secret="$SECRET_ID")cloud_sql_proxy-instances="$INSTANCE"=tcp:"$PORT"&PID=$!# Every 5s, get the latest version of the secret. If it's changed, restart the# proxy with the new value.whiletrue;dosleep$REFRESH_INTERVALNEW=$(gcloudsecretsversionsaccess"latest"--secret="$SECRET_ID")if["$INSTANCE"!="$NEW"];thenINSTANCE=$NEWkill$PIDwait$PIDcloud_sql_proxy-instances="$INSTANCE"=tcp:"$PORT"&PID=$!fidone

For more information on creating and accessing a secret that contains the instance connection name of the primary replica, seeCreate a secret with Secret Manager. For more information on using the Cloud SQL Auth proxy, seeConnect to Cloud SQL using the Cloud SQL Auth proxy.

What's next

• You can integrate Secret Manager with other Google Cloud products such as Cloud Run.
  • For more information about how to secure your secrets in container environments, see Use secrets.
  • For a list of other Google Cloud products that integrate with Secret Manager, seeUsing Secret Manager with other products.
• To learn how to integrate Secret Manager with your development environment, see the various samples available in theAll Secret Manager code samples page.