Discover how StrongDM's Zero Trust PAM and fine-grained authorization secure cloud data plane access and mitigate shadow access risks without hindering productivity.
StrongDM manages and audits access to infrastructure.
- Role-based, attribute-based, & just-in-time access to infrastructure
- Connect any person or service to any infrastructure, anywhere
- Logging like you've never seen
StrongDM, the Zero Trust PAM platform that gives technical staff direct access to the critical infrastructure they need to be their most productive, now gives you more authentication flexibility with Remote Identities. This new feature enables you to connect to StrongDM resources using the identities of individual users instead of a leased credential.
Remote Identities helps you leverage the native capabilities of your SSH and Kubernetes resources and capitalize on infrastructure workflow investments you’ve already made.
Here’s how.
What Is the Remote Identities Feature All About?
With Remote Identities, you authenticate to an SSH or Kubernetes resource using the identity of the StrongDM user connecting to it instead of StrongDM’s standard leased credential method.
In the StrongDM leased credential model, users access SSH and Kubernetes resources through a centralized set of credentials. This simplifies credential management and helps prevent credential sprawl while preserving all identity information about the StrongDM user accessing your infrastructure in our comprehensive logs.
But, what if you want to take advantage of user profiles and home directories on your servers, or have StrongDM users without auditing privileges relying on native Kubernetes logging and RBAC? Remote Identities allows you to leverage these resource-specific features and more.
Ultimately, though, we leave it up to you to choose if you want to use leased credentials or Remote Identities. Understanding the benefits of using Remote Identities can help you decide.
What Are the Benefits of Using Remote Identities?
The Remote Identities feature allows you to extract more value from your SSH and Kubernetes resources by leveraging their native capabilities.
For instance, it’s now easier to do these tasks:
- Assign Kubernetes permissions at the group level with native Kubernetes RBAC
- Include user-specific profiles on your servers
- Identify specific users associated with processes being executed on multi-tenant systems
Additionally, you can leverage pre-existing investments in infrastructure processes or workflows (such as native alerting, log aggregation, and SIEM integrations).
Have you already done any of the following?
- Set up a SIEM aggregation that consumes native logs directly from your resources
- Establish a local threat identification system that relies on user identities
- Employ disk and compute quotas on a per-user basis
Remote Identities enables you to keep operating all of these processes within StrongDM.
When Does Using Remote Identities Make Sense?
We’ve already highlighted some of the most prominent use cases where authenticating using a remote identity, rather than a leased credential, makes sense. However, let’s recap them here along with a few others:
- Leveraging user-specific profiles and home directories on servers
- Enabling targeted identification and cancellation of server processes based on the user
- Enforcing per-user, per-server quotas on resource usage in multi-tenant systems
- Leveraging native Kubernetes RBAC
- Being able to identify specific StrongDM users in a resource’s native logs
- Using local threat identification systems on resources
- Supporting custom notification, approval, and escalation workflows running on your resources that need to be aware of a user’s identity
New to StrongDM? Sign up for our free no-BS demo and discover how our Zero Trust PAM platform can work for you.
About the Author
💙 this post?
Then get all that StrongDM goodness, right in your inbox.
You May Also Like
Learn why Just-in-Time (JIT) access is essential for Zero Trust security in AWS environments. Discover how StrongDM's JIT access enhances security, optimizes workflows, and ensures compliance with Zero Trust principles.
Let’s talk about the unsung heroes of your on-premises infrastructure: network devices. These are the routers, switches, and firewalls that everyone forgets about…and takes for granted—until something breaks. And when one of those somethings breaks, it leads to some pretty bad stuff. If your network goes down, that’s bad, bad, bad for business. But if those devices lack the necessary security, well, that can leave you exposed in an incredibly dangerous way.
Zero Trust cloud security is a cybersecurity model that operates on the principle that no user, device, system, or action should be trusted by default — even if it's inside your organization’s own network. This approach minimizes the risk of breaches and other cyber threats by limiting access to sensitive information and resources based on user roles, device security posture, and contextual factors.
Protecting sensitive patient data in healthcare isn't just a priority—it's a legal and ethical obligation. However, one of the most overlooked security gaps that healthcare organizations face is the practice of password sharing among employees. This seemingly harmless habit can quickly lead to unauthorized access and serious data breaches, putting both the organization and patients at risk. While often seen as a convenient shortcut, password sharing undermines the security of protected health information (PHI), potentially leading to HIPAA violations and data breaches. In this post, we'll explore eight effective ways to prevent password sharing in healthcare.