> 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 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` 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 what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.