Vault & Secrets

How StrongDM Handles Credentials

When a user connects to a resource through StrongDM, the credentials that authenticate the connection are never revealed to the user. The node (gateway, relay, or proxy worker) delivering the traffic fetches credentials and injects them into the connection transparently. Where those credentials come from depends on how you've configured the resource.

Three Ways to Store Credentials

Connection Flow with Secret Stores

When using a secret store, StrongDM never has the credentials. They go directly from your vault to the node to the resource. If you rotate credentials in your vault, StrongDM picks up the new ones automatically on next connection.

Supported Secret Stores

StrongDM integrates with these secret store providers. Once a resource is configured with a specific secret store, you can't reassign it to a different one (you'd need to recreate the resource).

Setting Up Secret Stores

The general flow for any third-party secret store is the same: configure the store, set up your relay/gateway to authenticate to it, register it in StrongDM, and then configure resources to reference paths within the store.

VAULT_ROLE_ID=<YOUR_ROLE_ID>
VAULT_SECRET_ID=<YOUR_SECRET_ID>
VAULT_TOKEN_TTL=600

VAULT_TOKEN=<YOUR_VAULT_TOKEN>

AWS_ACCESS_KEY_ID=<YOUR_KEY_ID>
AWS_SECRET_ACCESS_KEY=<YOUR_SECRET_KEY>

Configuring a Resource with a Secret Store

Once a secret store is registered and healthy (green indicator in Admin UI), you can use it when creating resources. Instead of entering a password directly, you select the secret store and provide the path to the credential within it.

CLI: Creating Secret Stores

You can also create secret stores from the CLI:

# List existing secret stores
sdm admin secretstores list

# Create a HashiCorp Vault secret store (AppRole auth)
sdm admin secretstores create vaultAppRole \
  --name "Production Vault" \
  --server-address "https://vault.example.com:8200"

# Create an AWS Secrets Manager store
sdm admin secretstores create aws \
  --name "AWS Prod Secrets" \
  --region "us-east-1"

Certificate Authorities

Certificate authorities let your SSH and RDP resources authenticate with trusted certificates instead of static key pairs or passwords. StrongDM provides a built-in CA (Strong CA) automatically for every organization, and Enterprise customers can integrate third-party CAs.

Strong CA (Built-In)

Every StrongDM organization gets two Strong CAs by default: one for SSH and one for RDP. There's nothing to configure.

How Certificate Auth Works

Setting Up SSH Certificate Auth

1. Get the CA public key
   In the Admin UI, go to Settings > Secrets Management > Certificate Authorities. Select the SSH CA, click the active certificate, and copy the public key.
2. Trust the CA on your hosts
   Save the key as /etc/ssh/sdm_ca.pub on each target host. Add TrustedUserCAKeys /etc/ssh/sdm_ca.pub to /etc/ssh/sshd_config, then restart sshd.
3. Create the resource in StrongDM
   Add an SSH (Certificate Auth) resource. Select your CA and key type. StrongDM issues short-lived certificates for each connection.

# Trust StrongDM CA for user authentication
TrustedUserCAKeys /etc/ssh/sdm_ca.pub

Setting Up RDP Certificate Auth

1. Download the root certificate
   In the Admin UI, go to Settings > Secrets Management > Certificate Authorities. Select the RDP CA and download the rdp.cer file.
2. Trust the CA in Active Directory
   Upload the root certificate to Microsoft Entra ID (Security > Certificate authorities) or distribute it via Group Policy to your on-premises AD.
3. Create the resource in StrongDM
   Add an RDP (Certificate Auth) resource. Select the CA. Connection authentication is handled via short-lived X.509 certificates.

Third-Party CAs (Enterprise)

Enterprise plan customers can integrate external CAs instead of using the Strong CA. Supported third-party CAs:

Certificate Rotation

You can create multiple certificates under a CA but only one is active at a time. To rotate:

1. Create a new certificate in the Admin UI.
2. Deploy the new certificate's public key (SSH) or root cert (RDP) to your hosts.
3. Once deployed, activate the new certificate in StrongDM.
4. The old certificate becomes inactive and can be removed.

Secrets Management (Enterprise)

StrongDM's secrets management goes beyond just storing credentials. Secret engines can actively manage and rotate credentials in both the target resource and a backing secret store simultaneously.

Secret Engine Types

Backing Secret Stores

Every secret engine needs a backing secret store where it keeps synchronized copies of credentials. Supported backing stores for secrets management:

StrongDM Vault as a backing store requires nodes running version 51.51.0 or higher.

How Rotation Works

Key Value Engine Use Cases

The Key Value engine doesn't connect to any target resource. It just manages secrets in a store. This is useful for:

• Resource types that don't have a dedicated engine (e.g., Redis, DynamoDB)
• Non-resource secrets like Windows admin credentials that users need to retrieve manually
• Integration with policy-based secret entitlement for audited credential retrieval

Secret Entitlement with Policies

StrongDM policies can entitle specific users to retrieve secrets manually. This is useful for credentials that aren't for StrongDM-proxied access, like a Windows admin password a user needs to enter themselves. Every retrieval is logged and auditable.

Deployment Patterns

Decision Guide

Which approach should you use?

Terraform Examples

Creating a Secret Store

# HashiCorp Vault (AppRole auth)
resource "sdm_secret_store" "vault" {
  vault_approle {
    name           = "prod-vault"
    server_address = "https://vault.example.com:8200"
  }
}

# AWS Secrets Manager
resource "sdm_secret_store" "aws_sm" {
  aws {
    name   = "aws-prod-secrets"
    region = "us-east-1"
  }
}

Resource Using a Secret Store

resource "sdm_resource" "prod_pg" {
  postgres {
    name           = "prod-postgres"
    hostname       = "pg.internal.example.com"
    port           = 5432
    database       = "production"
    username       = "secret/data/prod/pg?key=username"
    password       = "secret/data/prod/pg?key=password"
    secret_store_id = sdm_secret_store.vault.id
    tags = {
      env  = "production"
      team = "platform"
    }
  }
}

Vault SSH CA in Terraform

resource "sdm_secret_store" "vault_ssh_ca" {
  vault_tls_cert_ssh {
    name              = "vault-ssh-ca"
    server_address    = "https://vault.example.com:8200"
    signing_role      = "sdm-ssh-signer"
    ssh_mount_point   = "ssh-ca/"
    client_certificate_path = "/path/to/client.crt"
    client_key_path         = "/path/to/client.key"
  }
}

Troubleshooting

Quick Reference