> For the complete documentation index, see [llms.txt](https://docs.strongdm.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.strongdm.com/concepts/security/credentials-and-secrets-management.md). # Credentials and Secrets Management ### 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. {% @mermaid/diagram content="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: . #### 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. ### Security Considerations for Privileged Accounts Not even your users with the Administrator permission level can access resource credentials directly. Even if an Administrator account in your organization is compromised, this particular consequence is mitigated. However, it is possible for a malicious Administrator or Database Administrator (DBA) to change the address of a resource to point to a server under their control. Depending on the type of resource and authentication method, the attacker may be able to recover plaintext credentials for the original resource when authentication attempts are made to the new server using the legitimate resource credentials. In addition, a malicious Administrator or DBA can create a resource that points to a sensitive address, such as the [AWS Instance Metadata Service](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), and recover credentials that way. These attack vectors are impossible to block completely, so it's critical to maintain the security of your StrongDM Administrator and DBA accounts. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.strongdm.com/concepts/security/credentials-and-secrets-management.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.