GCP Cloud SQL

Doppler supports rotating secrets for each GCP Cloud SQL database - MySQL, Postgres, and SQL Server. Doppler utilizes the Cloud SQL Admin API to facilitate rotation. There's no need to expose your database to the internet and the GCP Service Account can be narrowly scoped.

Requirements

Overview

Configuring Doppler to facilitate rotation in Cloud SQL consists of:

  1. Creating a narrowly scoped custom GCP role
  2. Giving Doppler that role, either keylessly or with a GCP Service Account key
  3. Providing the details of the Cloud SQL users to rotate between

Doppler supports two ways to authenticate to the Cloud SQL Admin API. Workload identity federation is recommended, since it leaves no credential stored in Doppler. Follow whichever section applies, then create the rotated secret.

GCP Custom Role

In order to scope Doppler's access as narrowly as possible, you'll first create a custom role for it to use.

  1. In the GCP console, under IAM, navigate to RolesSelect Create Role
  2. Provide a Title and ID. Use General Availability for Role Launch Stage
  3. Select Add Permissions
  4. In the filter section, search for and add cloudsql.users.update, cloudsql.users.list, and cloudsql.instances.get
  1. Select Create

Note the Role ID you gave it β€” you'll reference it when granting access below.

Keyless Authentication

Doppler can authenticate to this integration without you storing a long-lived credential. Instead of a service account key or client secret, Doppler acts as an OpenID Connect (OIDC) identity provider: whenever it needs access, it mints a short-lived signed token that your cloud verifies against Doppler's public keys and exchanges for its own temporary credentials.

Doppler's OIDC Issuer

Issuerhttps://api.doppler.com
Discovery documenthttps://api.doppler.com/.well-known/openid-configuration
JWKShttps://api.doppler.com/.well-known/jwks.json
Signing algorithmRS256
Token lifetime5 minutes

Every connection gets its own identity. The sub claim of each token Doppler issues for a connection is:

workplace:<workplace-slug>:connection:<connection-id>

Tokens also carry workplace and connection claims holding those same two values. Tokens minted for a sync additionally carry sync, config, and project. Because the subject contains the connection ID, trust you grant to one connection never extends to another.

πŸ“˜

If you self-host Doppler, substitute your own API domain for api.doppler.com. Keyless options only become selectable once an administrator has configured the OIDC issuer's signing keys. If the option is greyed out in the connection dialog, that hasn't been done yet.

Setup Takes Two Passes

A connection's identity contains its connection ID, and that ID doesn't exist until the connection has been created. Configuring keyless authentication is therefore a round trip between your cloud and Doppler:

  1. In your cloud, establish the trust relationship pointing at Doppler's issuer.
  2. In Doppler, create the connection. Doppler has no permissions yet, so it skips its usual credential check and the connection is created immediately.
  3. In your cloud, grant access to the identity Doppler displays on the connection page under Federation Identity.
🚧

Because step 2 can't verify anything, a keyless connection looks healthy even when step 3 is missing or wrong. The first sync, rotation, or lease is what proves the trust works. Confirm one succeeds before you consider setup finished.

Create a Workload Identity Pool and Provider

Create a pool to hold Doppler's identity, then a provider inside it that trusts Doppler's OIDC issuer. Do this before you create the connection in Doppler.

POOL_ID="doppler";
PROVIDER_ID="doppler";

# Get the current project's ID and number
PROJECT_ID="$(gcloud config get-value project --quiet)";
PROJECT_NUMBER="$(gcloud projects describe "$PROJECT_ID" --format='value(projectNumber)')";

# Create a workload identity pool for Doppler
gcloud iam workload-identity-pools create "$POOL_ID" \
  --location="global" \
  --display-name="Doppler";

# Create an OIDC provider in that pool which trusts Doppler's issuer
gcloud iam workload-identity-pools providers create-oidc "$PROVIDER_ID" \
  --location="global" \
  --workload-identity-pool="$POOL_ID" \
  --issuer-uri="https://api.doppler.com" \
  --attribute-mapping="google.subject=assertion.sub" \
  --display-name="Doppler";

# Print the provider resource name to paste into Doppler
echo "//iam.googleapis.com/projects/$PROJECT_NUMBER/locations/global/workloadIdentityPools/$POOL_ID/providers/$PROVIDER_ID";
πŸ“˜

Doppler uses the provider's full resource name as the token audience, which is the audience GCP accepts by default. You don't need to set --allowed-audiences.

Connect Doppler

In the connection dialog, choose Workload identity federation, then provide:

  • Workload identity provider β€” the resource name printed by the last command above. It begins with //iam.googleapis.com/ and uses your numeric project number, not the project ID.
  • Project ID β€” your project's ID, the human-readable one (e.g. my-gcp-project).

Doppler creates the connection without checking its access, since it has none yet.

Grant Access to the Doppler Principal

Open the connection in Doppler and copy the IAM principal shown under Federation Identity. It looks like this:

principal://iam.googleapis.com/projects/123456789012/locations/global/workloadIdentityPools/doppler/subject/workplace:my-workplace:connection:00000000-0000-0000-0000-000000000000

That principal is what you grant roles to below. Until you do, Doppler can authenticate but can't do anything.

For Cloud SQL, the Connect Doppler step above happens inside the Add Rotated Secret wizard described in Create the Rotated Secret in Doppler. Once that wizard finishes, come back here and grant the principal the custom role:

PROJECT_ID="$(gcloud config get-value project --quiet)";

# The Role ID of the custom role created above
ROLE_ID="dopplerCloudSQLRotation";

# The IAM principal shown under "Federation Identity" on the Doppler connection page
PRINCIPAL="principal://iam.googleapis.com/projects/.../subject/workplace:...:connection:...";

gcloud projects add-iam-policy-binding "$PROJECT_ID" \
  --member="$PRINCIPAL" \
  --role="projects/$PROJECT_ID/roles/$ROLE_ID";

Service Account Key Authentication

Use this method if you'd rather give Doppler a service account key than set up federation.

GCP Service Account

  1. In the GCP console, navigate to Service Accounts
  2. Select Create Service Account
  3. Name your service account and provide an ID
  4. Select Create and Continue
  5. Under Grant this service account access to project, select the custom role you created above
  6. Select Continue and then select Done

GCP Service Account Key

  1. On GCP Service Account page, select the Service Account you just created above
  2. Select the Keys tab
  3. Select Add Key then Create New Key
  4. Leave JSON selected and click Create. You will use the generated key below

Create the Rotated Secret in Doppler

  1. Navigate to the Doppler config you would like to add a rotated secret to
  2. Click the dropdown next to Add Secret and select Add Rotated Secret
  1. Select the engine you'd like to rotate - MySQL, SQL Server, or Postgres
  2. Choose how Doppler should authenticate:
    • Workload identity federation β€” name your integration, then enter the Workload identity provider resource name and Project ID
    • Service account key β€” name your integration and enter the Service Account key you created above

Cloud SQL Database Details

  • Rotated Secret Name: The name of the rotated secret object; it will also prefix each of the secrets that Doppler injects into your config. For example, if DB_USER is entered, the following secrets would be injected into your config:
    • DB_USER_USER_HOST_NAME (MySQL only)
    • DB_USER_DATABASE_INSTANCE
    • DB_USER_DATABASE
    • DB_USER_USERNAME
    • DB_USER_PASSWORD
  • Interval: How often your database passwords are rotated
  • Database Instance: The name of your database

Users

During the rotation process, Doppler rotates between the database users you provide during the rotation configuration process. By providing the users to Doppler, Doppler doesn't need the ability to create new users - just update user passwords.

There are no requirements related to the users you provide.


Did this page help you?