In partnership with
TechOps Examples
Hey — It's Govardhana MK 👋
Welcome to another technical edition.
Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.
Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.
👋 👋 A big thank you to today's sponsor WISPR FLOW
The best prompt engineers aren't typing. They're talking.
Power users figured this out early: speaking a prompt gives you 10x more context in half the time. You include the edge cases, the examples, the tone you want — because talking is fast enough that you don't skip them.
Wispr Flow captures everything you say and turns it into clean, structured text for any AI tool. Speak messy. Get polished input. Paste into ChatGPT, Claude, Cursor, or wherever you work.
89% of messages sent with zero edits. 4x faster than typing. Works system-wide on Mac, Windows, and iPhone.
👀 Remote Jobs
Growe is hiring a Senior DevSecOps Engineer
Remote Location: Worldwide
GitLab is hiring a Site Reliability Engineer
Remote Location: Worldwide
Powered by: Jobsurface.com
📚 Resources
Looking to promote your company, product, service, or event to 49,000+ Cloud Native Professionals? Let's work together. Advertise With Us
🧠 DEEP DIVE USE CASE
How to Restrict Access to Kubernetes Resources
I still see clusters where every service account has cluster admin because nobody wanted to spend an afternoon working out the correct RBAC rules. Then one compromised pod later, that decision costs a lot more than an afternoon. Kubernetes ships with a full authorization model built for exactly this problem, and most of the damage from over permissioned clusters.
The Three Things Every Access Rule is Built From
Every RBAC rule in Kubernetes answers ‘who can do what to which object’. That breaks down into three pieces.
The subject is the identity making the request, and Kubernetes recognizes three kinds: Users, Groups, and ServiceAccounts.
The API resource is the object being acted on, things like Node, Pod, Deployment, Namespace, ConfigMap, or ReplicaSet.
The operation is the verb applied to that resource, and Kubernetes defines a fixed set: create, get, list, watch, update, delete, and attach, among others.
A rule always names a subject, a resource type, and a set of verbs. Nothing is implied. If a ServiceAccount is not explicitly granted get on pods, it cannot read pod data, regardless of what other permissions it holds elsewhere.
How a Role Actually Reaches a Pod
The subject, resource, and verb pieces above only become an enforceable permission once two more objects connect them: a Role and a RoleBinding.
A Role by itself grants nothing. It is a named list of permitted verbs against specific resources, sitting unused until something binds it to an identity. A RoleBinding is what makes that connection, pointing to one Role and listing one or more subjects, a User, a Group, or a ServiceAccount, that should receive the permissions defined in that Role. Multiple subjects can share a single RoleBinding, but a RoleBinding can only reference one Role.
Writing the Role
The YAML for a Role is short, and every field maps directly to the concepts described above.
apiGroups set to an empty string refers to the core API group, which is where Pods, ConfigMaps, and Services live.
resources names exactly which object type the rule applies to, and verbs lists the exact operations permitted. This Role grants read only access to Pods within whichever namespace it is created in. It says nothing about who can use it, that comes next.
🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)
Upgrade to Paid to read the rest.
Become a paying subscriber to get access to this post and other subscriber-only content.
UpgradePaid subscriptions get you:
- Access to archive of 250+ use cases
- Deep Dive use case editions (Thursdays and Saturdays)
- Access to Private Discord Community
- Invitations to monthly Zoom calls for use case discussions and industry leaders meetups
- Quarterly 1:1 'Ask Me Anything' power session
