Before establishing a connection between the Cloud Run service and the Cloud SQL database, it’s necessary to create a secret in Secret Manager to safely store the database user’s password.
Secret Manager is a secure and convenient solution provided by Google Cloud for managing sensitive information like passwords, API keys, and other secrets. It ensures that these secrets are accessible only to authenticated services and users, thereby helping to keep your application secure. It also offers versioning and audit logging, enabling you to keep track of who accessed what secret and when.
By using Secret Manager to store the database password, you are making sure that it’s kept safe and can be accessed securely by your Cloud Run service when it needs to connect to the database.
Here, you are taking the database password stored in the environment variable and passing it to the gcloud command using the <(echo -n $DATABASE_PASSWORD) syntax.
Tip
It is important to use the -n option to echo to avoid storing a newline character at the end of the password, making it invalid.
You now have a secret to which you can give a service account access, rather than sitting unencrypted in an environment variable. You will then use that service account with the Cloud Run service.
Creating a Service Account
In line with the principle of least privilege, you can now create a dedicated service account that has only the necessary permissions to perform its tasks.
To enable your service account with the access it needs, you need to assign it two specific roles.
The first role is the Cloud SQL Client. This role grants the service account the necessary permissions to connect and interact with the Cloud SQL database. It’s like giving the service account the keys to the database room.
The second role is the Secret Manager Secret Accessor. This role allows your service account to access and retrieve the secret you stored in the Secret Manager. Think of this as giving your service account the combination to the safe where you keep your most valuable secrets.
By assigning these roles, you empower your service account to perform its tasks, while still adhering to the principle of least privilege.