Kubernetes Access and Mid-Session Policy with Delinea

Kubernetes access is the easy part, requested just in time.

This is a production EKS cluster in AWS using IAM authentication.

Think about what the alternative usually looks like.

A kubeconfig file sitting on a laptop with a token that does not expire, copied from a colleague a year ago, pointing at production.

Nobody revokes it because nobody knows it’s there.

That file is one of the most common ways an attacker reaches a cluster.

Here, there’s no file to copy. The access does not exist until it’s requested, and the request carries a reason and a time limit.

An administrator approves.

One person asked, one person agreed, both are on the record, and the clock starts.

Now the cluster appears in the desktop app.

Open a shell and update the kubectl config.

The developer keeps their own tooling. Nothing here asks them to learn a new client or change how they work.

Now kubectl works normally: list resources and exec into a pod.

Everything in the terminal is running through Delinea.

The connection is brokered, the identity behind it is named rather than shared, and the session is recorded.

The developer does not experience any of that, which is the point.

A control people route around is not a control.

And notice what has not happened.

Nobody handed this developer a long-lived credential.

Authentication to AWS IAM happens on their behalf at connection time, for the duration they were granted.

When the duration ends, this terminal stops working and there’s nothing to clean up.

So far, this is access.

Now watch what happens when access alone is not enough.

Now add a control to this cluster: access policies.

In the admin console, add a policy.

This one will require a second factor before certain commands run.

Now open it to edit the rule.

Policies are code and can also be applied through Terraform.

Create it and save.

The policy is live immediately.

No restarts, no reconnect, no change window.

The developer in that terminal does nothing and will not know the rule changed until it stops them.

That gap is worth sitting with, because it’s the difference between a control you configure and a control that takes effect.

Most access tooling can tell you what someone is entitled to. Much less of it can change what they’re allowed to do while they’re already connected.

Rerun the command. The policy stops it and asks for a second factor.

Approve, and it runs.

Just-in-time access to the cluster, and policy that keeps working after you’re in. See it at delinea.com.