Credentials & Secrets Management

Last modified on April 5, 2023

Credential Handling

Because StrongDM is a protocol-aware proxy, we are able to inject credentials during the “last mile” hop between the proxy and the target database or server. As a result, sensitive credentials are always inaccessible to users: they are never transferred to a client in any form.

Credentials are unlocked at runtime using a “dual key” system: only when a cryptographically valid proxy instance requests decryption on behalf of a cryptographically valid user session are they unlocked. Neither the user nor the proxy instance alone are sufficient to decrypt the credential.

We call the system that StrongDM uses to handle this “credential leasing”.

Credential Leasing

Users in the StrongDM system may be granted access to a Datasource or Server via Roles, or via temporary access directly granted to the User.

From the perspective of a Datasource or Server, access is conducted via the Leased Credential.

Example: When Bob connects to a MySQL instance, executing SHOW PROCESSLIST will list the connection within that instance as originating from leased-credential and the IP of the gateway or relay most proximate to that MySQL instance. Within StrongDM, any logged queries will be attributed to Bob.

graph TD; U(User) -->|belongs to| R; R(Role) -->|leases| A; R(Role) -->|leases| B; R(Role) -->|leases| C; A(superuser) --> D[DB]; B(read-only) --> D[DB]; C(restricted) --> D[DB];

StrongDM’s Secret Stores

Internally, the StrongDM Secret Stores are implemented using AWS Key Management Service. The StrongDM implementation fully leverages authenticated encryption with associated data (AEAD) via the KMS Encryption Context. All credential decryption events are written to a tamper-hardened audit log that is owned by a separate AWS account. You can read more about KMS at: https://docs.aws.amazon.com/kms/latest/cryptographic-details/intro.html.

Third-party Secret Stores

Secret store integrations provide the option to store resource credentials in a third-party tool controlled by you rather than saving them with StrongDM. If your organization already manages and rotates credentials with a supported secret store provider, nothing about that workflow will have to change.