How StrongDM Works

Your StrongDM network is made up of several components: the client, node(s), and resource(s). You can grant standing resource access to users by adding Roles, or use access workflows to provide Just-in-Time (JIT) access. Additionally, you can use Policies to provide even further fine-grained access controls.

Client

The client is the StrongDM Desktop application and/or CLI that is installed locally on a machine by a user, who is typically a member of your organization. Users use the client to authenticate to StrongDM, use StrongDM, manage their organization, and/or interact with resources.

Nodes

StrongDM nodes are proxy clusters, gateways, or relays. You are able to choose whether to use proxy clusters or whether to use gateways and relays separately. You can read more about this decision on the Networking page.

Your StrongDM nodes sit on servers within your infrastructure, and proxy traffic from clients in your organization to resources, working with StrongDM to ensure that the user attempting access should be authorized to do so, and then authenticating them to the resource without exposing resource credentials to the user at any point.

Resources

Resources are the final part of your network. Whether you have only one gateway or a complicated network that requires many nodes, the same thing happens as your traffic arrives at the last node before reaching the target resource: the node acquires credentials from StrongDM or from your Secret Stores, and authenticates with the target resource.

Roles

Roles can be used to provide standing access to resources. Roles contain access rules that can provide static access to particular resources, or dynamic access to resources that meet particular criteria, such as tags or types or resources.

Access Workflows

You can provide JIT access to users by employing access workflows. Users can be given a catalog of resources to select access to, via roles that you attach to the users. The users can then request access via methods including the Admin UI, the CLI, or integrations such as Slack or Teams. The approval workflows on the other end of the process can be set up to automatically approve access (creating no access friction, but enabling an audit trail for the JIT access) or can be manually approved by one or more approvers. These approval workflows can also be used to approve requests that take place in external systems such as Jira or ServiceNow, and can even be used to provide extra approval steps for policy evaluations.

Policies

Extra access control steps are enforceable through policies. Policies are written in the Cedar language, and are context-aware. Users with access provided via roles or JIT who connect to resources can trigger policy evaluation, analyzing their specific context for triggers that might forbid (or allow) access, such as their location or their device trust status. For some resource types, this action control goes even deeper, allowing you to block particular commands, or require MFA challenges or approval steps to continue.