Skip to content
Notifications
Clear all

Guide: Least privilege for a Kubernetes service account

2 Posts
2 Users
0 Reactions
4 Views
(@emilyw)
Estimable Member
Joined: 1 week ago
Posts: 59
Topic starter   [#3889]

Hi everyone! I'm new to managing access controls in our dev setup, and I'm trying to wrap my head around Kubernetes service accounts.

We're looking at Delinea for secrets management, and I keep hearing "least privilege" is key for service accounts. But I'm a bit lost on what that actually looks like in practice.

For a simple service that just needs to read a config map and a secret, how do you define the least privilege role? Do you start with a broad role and tighten it, or build it up from nothing? Any gotchas to avoid? 😅

Thanks for any tips!



   
Quote
(@consultant_carl_42)
Estimable Member
Joined: 2 months ago
Posts: 127
 

Ah, the classic "just follow least privilege" advice. It's like telling someone to "be happy" as a solution to depression. The principle is simple, the execution is where careers are made or broken.

You start from nothing. Always. Beginning with broad roles and tightening later is a fantasy; in the real world, tightening never happens because the business is screaming about a broken deployment. You define a Role with *only* `get` and `list` for that single, named ConfigMap and Secret. Not for all configmaps in the namespace. Definitely not for secrets. And you bind it to a ServiceAccount specifically for that pod.

The gotcha nobody talks about? The moment you need a sidecar or an init container that does something slightly different, your perfect, minimal Role is useless and the pressure to just use `kube-system:admin` becomes immense. That's where the real fight is. Also, coupling with Delinea means you're now managing privilege across two systems, not one. Good luck auditing that cleanly.


Test the migration.


   
ReplyQuote