API Reference
Last modified on October 25, 2024
The StrongDM API allows users of StrongDM to programmatically interact with their organization in StrongDM in order to create, remove, or manage users, roles, permissions, gateways, relays, resources, and more. The amount of API access afforded to an API key depends entirely on what was granted to the key by the organization’s administrators when the key was created.
The StrongDM API is constructed with gRPC and a request signature model that requires the use of one of the StrongDM SDKs to interface with the API. The SDKs were designed with REST principles in mind. They are built around a set of domain objects, as well as the basic set of Create, Read, Update, and Delete (CRUD) operations.
Moreover, the StrongDM API provides advanced auditing and logging capabilities that simplify how data is extracted from StrongDM for programmatic integration into other parts of your organization, such as SIEM, log aggregators, compliance and/or security reports, or end-to-end IAM workflows. You can additionally use the StrongDM API to do the following:
- Get the history of what happened in your organization.
- View full snapshots.
- Look at shells for all replays.
- View SSH session data as it comes in, and watch sessions play live.
- Actively look at queries as they come in.
- Suspend users by ID.
The destination for requests directly to the StrongDM API is api.strongdm.com
.
You can interact with the API via any of StrongDM’s SDKs or Terraform.
StrongDM SDKs
The StrongDM API allows for the programmatic management of StrongDM features as well as the resources attached to the organization. StrongDM supports the following SDK options: Go, Java, Python, and Ruby.
Language | Reference | GitHub | Examples |
---|---|---|---|
Go | pkg.go.dev | strongdm-sdk-go | Go SDK Examples |
Java | javadoc | strongdm-sdk-java | Java SDK Examples |
Python | pdocs | strongdm-sdk-python | Python SDK Examples |
Ruby | RubyDoc | strongdm-sdk-ruby | Ruby SDK Examples |
Feel free to use the SDKs to interact with StrongDM from your own software.
StrongDM Terraform Provider
StrongDM’s Terraform provider makes use of the StrongDM API and has a set of Terraform provider examples.
How It Works
The StrongDM API does not rely on bearer tokens alone to protect your requests (and thus your infrastructure). Instead, the StrongDM API requires the use of request signatures modeled on the AWS V4 signing process. This methodology never sends a secret key over the network. If the key isn’t sent, the key cannot be intercepted. Furthermore, this methodology allows StrongDM to validate the time and payload of each API call, protecting against replay attacks or Manipulator in the Middle (MitM) message tampering. The StrongDM SDKs handle the gRPC calls and signing process to ensure a consistent and convenient experience.
Authentication
Each SDK provides a client that must be constructed with an API ID
and Secret
(also referred to as your API key). This key also sets the client’s permission to manage objects within StrongDM. For instructions on creating your API key, see the API Keys page.
For example, in Python:
def main():
client = strongdm.Client(<YOUR-ID>,<YOUR-SECRET>)
Domain objects
Domain objects are present in all of the StrongDM SDKs. These domain objects are, in a way, the glossary of the API. Once you’re familiar with them, you’ll better understand what you can do with the API.
Modifiable domain objects
The domain objects in the following table may be modified.
Domain object | Description |
---|---|
AccountAttachments | Assigns an account to a role |
AccountGrants | Assigns a resource directly to an account, giving the account the permission to connect to that resource |
AccountPermissions | Records the granular permissions accounts have, allowing them to execute relevant commands via StrongDM’s APIs |
Accounts | User accounts or service accounts that have access to StrongDM; a user account is for humans who are authenticated through username and password or SSO; a service account is for machines that are authenticated using a service token |
Nodes | The gateway(s) and relay(s) that make up your StrongDM network and allow your users to connect securely to your resources. Gateways, the entry points into the network, listen for connections from the StrongDM client and provide access to databases and servers. Relays are used to extend the StrongDM network into segmented subnets. They provide access to databases and servers but do not listen for incoming connections. |
PeeringGroupNodes | Provides the building blocks necessary to attach a node to a peering group |
PeeringGroupPeers | Provides the building blocks necessary to link two peering groups |
PeeringGroupResources | Provides the building blocks necessary to attach a resource to a peering group |
PeeringGroups | Provides the building blocks necessary to obtain explicit network topology and routing |
Policies | Policies are a collection of zero or more policy statements written in the Cedar policy language that enforce fine-grained action control for the users of an organization. |
IdentityAliases | Assigns an Identity Alias-enabled resource directly to an account, giving the account the permission to connect to that resource using an Identity Alias instead of a leased credential |
IdentitySets | A named grouping of Identity Aliases for accounts; an account’s relationship to a IdentitySet is defined via IdentityAlias objects |
Resources | Databases, servers, clusters, websites, or clouds to which StrongDM delegates access |
Roles | A collection of of access rules that determine which Resources the members of the role can access; an account can be a member of multiple roles via AccountAttachments |
SecretStores | Servers where resource secrets (for example, passwords and keys) are stored |
WorkflowApprovers | A listing of users assigned to the workflow as approvers |
WorkflowRoles | A listing of the roles assigned to a workflow, which indicate which users may make requests via that workflow |
Workflows | A collection of rules that define the resources to which access can be requested, the roles that allow their members to request access to those resources, and the mechanism for approving those requests |
Read-only domain objects
The domain objects in the following table are read-only. They primarily allow you to view logs, administrative activities, and historical changes.
Domain object | Description |
---|---|
AccessRequestEventsHistory | A record of all changes to the state of an AccessRequestEvent |
AccessRequests | Requests for access to a resource via a workflow |
AccessRequestsHistory | A record of all changes to the state of an AccessRequest |
AccountAttachmentsHistory | A record of all changes to the state of an AccountAttachment |
AccountGrantsHistory | A record of all changes to the state of an AccountGrant |
AccountResources | Enumerates the resources to which accounts have access |
AccountResourcesHistory | A record of all changes to the state of an AccountResource |
AccountsHistory | A record of all changes to the state of an account |
Activities | A record of an action taken against a StrongDM deployment, such as user creation, resource deletion, or SSO configuration change |
ControlPanel | A record of all administrative controls |
NodesHistory | A record of all changes to the state of a node |
OrganizationHistory | A record of all changes to the state of an organization |
PoliciesHistory | A record all changes to the state of a Policy |
Queries | A record of single client request to a resource (for example, a SQL query); SSH, RDP, or Kubernetes interactive sessions also count as queries |
IdentityAliasesHistory | A record of all changes to the state of an IdentityAlias |
IdentitySetsHistory | A record of all changes to the state of an IdentitySet |
Replays | Captures the data transferred over a long-running SSH, RDP, or Kubernetes interactive session/query |
ResourcesHistory | A record of all changes to the state of a resource |
RoleResources | Enumerates the resources to which roles have access |
RoleResourcesHistory | A record of all changes to the state of a RoleResource |
RolesHistory | A record of all changes to the state of a role |
SecretStoresHistory | A record of all changes to the state of a SecretStore |
WorkflowApproversHistory | A record of all changes to the state of a WorkflowApprover |
WorkflowAssignments | A listing of the resources assigned to a workflow |
WorkflowAssignmentsHistory | A record of all changes to the state of a WorkflowAssignment |
WorkflowRolesHistory | A record of all changes to the state of a WorkflowRole |
WorkflowsHistory | A record of all changes to the state of a workflow |
Requests
Each domain object is accessible via functions or methods provided by the client.
For example, in Ruby:
users = client.accounts.list("")
Filters
Many domain objects provide a common filtering language. You can use filters to narrow results from most Read operations when making requests.
For example, in Go:
users, err := client.Accounts().List(ctx, "firstName:Alice")
if err != nil {
log.Fatal("failed to query accounts:", err)
}
In the Go example shown, only users matching the first name “Alice” are returned.
Paginate results
When making a request with a Read operation that returns many results, the SDK automatically paginates the results. Depending on the language, pagination may be modeled as a transparent iterator, as in Ruby:
users.each do |user|
p user
end
Alternatively, pagination may be modeled as an explicit call to receive the next result, as in Go:
for users.Next() {
user := users.Value()
fmt.Println(user)
}
Audit API
History
History domain objects (such as AccountsHistory
) offer a time range to show the history of what was changed over time. For example, Accounts
provides information about users and service accounts, whereas AccountsHistory
provides a historical record of all the changes that have been made to the state of those accounts.
If the Enterprise plan is enabled for your organization, you can query the domain objects and get history for the last 13 months. If the Enterprise plan is not enabled, you can query back 30 days by default and results may be truncated to 20 rows returned.
Snapshots
Typical calls to the API return the state of a domain object at the time of the request. Snapshots, however, allow you to view the state of one or more domain objects at a specified time in the past. Snapshots let you programmatically extract the history of what happened in your organization at a certain time regarding access grants, gateways and relays, roles, resources, and so forth.
Let’s say, for example, that within the last hour there was a security incident related to a role granting access to all Redis resources. You can use a snapshot to see the state of the role an hour ago. In the following example, the desired time is specified in client.SnapshotAt(<TIME>)
.
For example, in Go:
client.SnapshotAt(time.Now().Add(-1*time.Hour)).Roles().Get(ctx, "r-123456")
Snapshots are supported for the following domain objects:
AccessRequests
AccountAttachments
AccountGrants
AccountPermissions
AccountResources
Accounts
Nodes
IdentityAliases
IdentitySets
Policies
Resources
RoleResources
Roles
SecretStores
WorkflowApprovers
WorkflowAssignments
WorkflowRoles
Workflows
If the Enterprise plan is enabled for your organization, you can use snapshots for any time in the last 13 months. If the Enterprise plan is not enabled, you can use snapshots for the last 30 days by default and results may be truncated to 20 rows returned.
Rate Limits
Requests are subject to rate limits. Default rate limits are generous, and you’re unlikely to reach rate limits during normal operations. For more information, see the Rate Limits section.
Additional Information
You can find resources and information about the following StrongDM topics in this section: