Sticky

Monthly Buzz - June - Privileged Remote Access

Forum|Forum|14 hours ago
June 30, 2026
0 replies
0 views

B

BeyondTrust Communications
Community Manager

How to Secure Cloud-Native Infrastructure at Scale and Speed: A Conversation with Madhu Adireddi

May 21, 2026

Author: Gayatri Karthy Product Marketing Manager

In this Q&A, Director of Product Management for Privileged Remote Access, Madhu Adireddi, shares strategies for aligning security with DevOps velocity. She explains why databases and Kubernetes have become critical friction points for DevOps teams, the danger of relying on static credentials in dynamic environments, and how transitioning to just-in-time access helps organizations maintain speed without sacrificing control

DevOps Moves Fast—Access Shouldn’t Be the Thing That Slows It Down

White chain icon to symbolize the ability to copy a link

Where do DevOps teams feel the most friction with access today?

Madhu: It shows up in the systems they rely on most: databases and Kubernetes.

Teams invest heavily in modernizing their infrastructure. They move to cloud-native platforms, adopt Kubernetes, and automate deployments. However, the access methods for these systems rarely evolve at the same pace. This forces engineers into a frustrating loop where they are:

Waiting on manual approvals that stall deployment momentum

Reusing existing credentials to avoid administrative delays

Working around controls just to get things done

Over time, access becomes a hurdle—something teams tolerate, rather than an enabler of secure, efficient work.

Why are databases such a consistent challenge in this environment?

Madhu: Because while the databases have migrated to the cloud, the methods used to access them are still stuck in the past.

In many environments, access still relies on shared credentials or long-lived standing permissions. This isn’t because teams prefer it; it’s because these legacy methods are faster and more predictable than going through a slower and lengthier request process. But this creates a dangerous trade-off: engineers gain short-term speed, but security teams lose critical visibility. And over time, access expands in ways that are difficult to track or control.

Does Kubernetes introduce even more complexity?

Madhu: Yes—mainly because of how quickly it scales.

As environments grow, access becomes harder to standardize. Permissions are tied to specific roles and configurations that vary across clusters, and temporary access often lingers longer than intended.

Eventually, even simple questions become difficult to answer:

Who has access to which cluster right now?

What specific actions are they performing inside the cluster?

That lack of clarity introduces both operational friction and massive security risk.

Why hasn’t this problem been solved yet?

Madhu: Because traditional access models weren’t built for how cloud-native environments operate.

Infrastructure today is dynamic and short-lived, yet access controls remain static and persistent. To avoid slowing teams down, organizations default to granting broader access than necessary—and they rarely revisit these permissions. Over time, this leads to accumulated permissions, limited visibility, and a rapidly expanding attack surface.

Continue Reading HERE

Customer Case Study
ivision: How ivision Simplifies and Scales Identity Security with BeyondTrust

Latest Available Version
Privileged Remote Access 26.1.1 - April 2026

Beekeepers Hot Topics
Mapping privileged accounts to regular accounts based on different attributes

From what I can tell, dedicated account mapping (e.g. KB0017035) the only option available is to map the exact same attribute in both domains. For example,

employeedomain\user1 has attribute1 set to “user1” privilegeddomain\admin1 has attribute1 set to “user1” to drive the mapping via smart rules.

However, that implies that modifying attribute1 in employeedomain to a different value, say, “user2” would grant user1 access to user2’s privileged resources, giving domain1 authority over a privileged domain’s access.

What I want to be able to do is have privilegeddomain\admin1 attribute1 set to “user1”, and map that to employeedomain\user1’s name field (or samaccountname, or SID - something not modifiable without breaking the employeedomain\user1 account).

Is that possible?

Click here for the most popular articles In our Beekeepers Community