GCP Secret Manager

Secret Store integrations allow you to use your existing third-party secret stores with StrongDM. Your credentials are stored in a tool that is controlled by you, and those credentials are never transmitted to StrongDM in any form. If you would like to learn more about how this integration works and why you might wish to use it, please read the Secret Stores Reference.

This guide will walk you through how to integrate Google Cloud Platform (GCP) Secret Manager with StrongDM and how to use it to connect to Resources.

Set up GCP Secret Manager

To get started with GCP Secret Manager, store credentials in it and ensure your relay can authenticate to read them.

1. Set up your credentials in GCP Secret Manager (if you have not already). You can store your credentials as plaintext, one value per secret (e.g., username as one secret, key as one secret, etc.) or you can store them as a JSON object, with multiple items in one secret, arranged as key-value pairs.

2. Grant the identity your relay will use these IAM roles on the project: roles/secretmanager.secretAccessor and roles/browser.

3. Configure how the relay authenticates to GCP. StrongDM resolves credentials via Google's Application Default Credentials (ADC) chain. Choose one of the following:

   • Workload identity (recommended) — No credentials on disk; short-lived tokens are minted at runtime by the environment.

     • On GCE, GKE, or Cloud Run: Attach a service account to the VM or workload and the relay picks up tokens from the metadata server automatically. On GKE, Workload Identity gives each pod its own service account.

     • Outside GCP: Configure Workload Identity Federation to map your existing identity (AWS IAM role, OIDC token, Azure managed identity, etc.) to a GCP service account. Place the WIF configuration file in the standard ADC location or point GOOGLE_APPLICATION_CREDENTIALS at it.

   • Node credential provisioning (recommended) — You may provision credentials through the node instead of writing it to disk. Set GOOGLE_APPLICATION_CREDENTIALS_JSON to the contents of the service-account key (not a path to it), as with GOOGLE_APPLICATION_CREDENTIALS above:

     sdm nodesecrets set GOOGLE_APPLICATION_CREDENTIALS_JSON --from-file key.json

     When done, restart the service. A key provided this way takes precedence over GOOGLE_APPLICATION_CREDENTIALS. With nothing provided, behavior is exactly as before. All existing GCP authentication methods keep working unchanged. For more information, please see Provision Node Credentials.

   • Static key file (fallback, not recommended) — For environments where no workload identity is available. Set GOOGLE_APPLICATION_CREDENTIALS in /etc/sysconfig/sdm-proxy (or /etc/sysconfig/sdm-worker for proxy clusters) to a service-account JSON key file and restart the service. Key files are long-lived and must be rotated manually. Prefer the ambient methods above where your environment supports them.

     GOOGLE_APPLICATION_CREDENTIALS="/home/service/keys/gcp-key.json"

Configure the Secret Store in the Admin UI

Once you have GCP Secret Manager set up, credentials stored, and your Relay server able to access said credentials, it's time to integrate the Secret Store with StrongDM.

Add a Secret Store

1. In the Admin UI, go to Settings > Secrets Management and to the Secret Stores tab.

2. Click the add secret store button.

3. On the Add Secret Store form, set the following:

1. Display Name: Enter a name. This name will show up in the Admin UI.

2. Secret Store Type: Select GCP Secret Manager.

3. Project ID: Add your GCP project ID.

The project ID is a value generated by GCP when you create a new project. You can find your project ID in the GCP Console by clicking your project name in the top left of the screen, which opens a project selection window:

In this example, the project ID to fill in to the Admin UI field is dogwood-envoy-311614.

Now that you have set up your Secret Store integration, if you've configured your Gateway/Relay server correctly to use this secret store for access and authorization, the green online indicator should display. If it does not, you can set up a Gateway/Relay now and tell it to use GCP for its secret storage.

Create a Resource

Create a Resource that uses the secret store, assign it to a role that is assigned to a user, and verify that you can connect.

1. In the Admin UI, add a new Resource such as a Server or Datasource.

2. On the configuration dialog for that Resource, fill out the information for a Resource whose credentials you have stored in your secret store, paying particular attention to the following properties:

   1. Secret Store: Select GCP Secret Manager.

   2. Username (path): Enter the path to the secret in GCP Secret Manager (e.g., path/to/credential?key=optionalKeyName) The key argument is optional.

   3. Password (path): Enter the path to the secret in GCP Secret Manager (e.g., path/to/credential?key=optionalKeyName). The key argument is optional.

   Please note the following about your GCP secret paths:

   • Your secret path, when copied from GCP, will look similar to this: projects/111222333444/secrets/demo-postgres?key=username. Note that StrongDM will automatically prepend your project ID, versioning, and secrets/ to the path when interpreting it, so the value needed here is simply demo-postgres?key=username.

   • If your secret is stored as plaintext, with each credential in a different secret, you may just reference the secret's path. The secret input does accept JSON, so you can store a username/password or key id/key value pair using JSON within a single secret if you desire.

   • If you store your credentials as a JSON object rather than as individual plaintext secrets, you will need to also append ?key=credentialname (e.g., ?key=username) to fetch the specific item you are looking for.

   • To reference a Base64-encoded certificate, you will need to append a ?encoding=base64 to your path. If the certificate is in a text field, the path looks like example-secret?encoding=base64. If the certificate was stored as part of a JSON object, the path looks like example-secret?key=certificate&encoding=base64.

3. Click create to submit the form.

Grant access and test

1. In the Admin UI, go to Access > Roles.

2. Create a role with an access rule that grants access to the resource.

3. Assign the role to the user.

4. Log in as that user in your local GUI (or have the user do so, if not yours).

5. Verify that the resource exists, test a connection, and execute a query.

Congratulations! You have connected to a resource using Secret Store integration.