Just Enough Kubernetes Access with Delinea

A developer needs to work in a production Kubernetes cluster.

The question is how much access they get.

Delinea discovers the RBAC groups the cluster already defines and grants them just in time.

Watch this developer escalate twice inside one session and get stopped twice on the way.

It starts in Slack, where the developer already works.

Request access to production cluster.

The privileges box stays empty.

No elevated group, just baseline access to the cluster.

One hour, which is the default duration.

An administrator approves and the cluster appears in the desktop app.

Note what just happened.

Access was granted, but almost no permissions came with it.

Now, from the command line, inspect what the session actually carries.

One group, system:authenticated, which carries almost no permissions.

So listing pods fails, not because Delinea blocked it, but because the cluster’s own RBAC has nothing to allow.

Now the developer needs more.

Same workflow, same channel.

Escalation is not a separate process or a different tool.

It’s the same request with a privilege level attached.

That matters operationally, because a path people already know is a path they will actually use.

This time, choose a group from the privileges list.

These are the cluster’s own RBAC groups, discovered by Delinea rather than invented alongside it.

So what the developer asks for is exactly what Kubernetes will honor.

Approval is required again.

Escalating is a new decision, not an extension of an old one.

Now rerun both commands.

The new group is there and listing pods works.

Now, a root shell into a running pod.

This is the moment that makes security teams uncomfortable, and reasonably so.

A root shell inside a production pod is the highest-leverage thing on this screen.

What makes it defensible is not that it was requested, but what happens next.

The developer tries the destructive command: denied.

The group they hold does not reach that far.

Deleting the pod needs more, and it runs through Kubernetes impersonation.

Here’s a second stop: policy requires a second factor before the command runs.

The prompt hits the MFA client. Approve, and the session carries on.

Rerun the check, and the expanded group is there.

Same session, same developer, more authority, and a record of when it was granted and why.

Now the destructive command runs.

Two escalations, two approvals, one step-up challenge, and at no point did anyone hold standing permission on this cluster.

That’s just enough access for just long enough.

See it at delinea.com.