Understanding Kubernetes RBAC

Author

Govardhana M K
November 11, 2025

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.

TOGETHER WITH MINDSTREAM

Master ChatGPT for Work Success

ChatGPT is revolutionizing how we work, but most people barely scratch the surface. Subscribe to Mindstream for free and unlock 5 essential resources including templates, workflows, and expert strategies for 2025. Whether you're writing emails, analyzing data, or streamlining tasks, this bundle shows you exactly how to save hours every week.

IN TODAY'S EDITION

🧠 Use Case

  • Understanding Kubernetes RBAC

👀 Remote Jobs

📚️ Resources

If you’re not a subscriber, here’s what you missed last week.

To receive all the full articles and support TechOps Examples, consider subscribing:

🛠️ TOOL OF THE DAY

gitops-bridge - Community project that aims to showcase best practices and patterns for bridging the process of creating a Kubernetes cluster to subsequently managing everything through GitOps.

🧠 USE CASE

Understanding Kubernetes RBAC

Some of you may already know this. Let's quickly revise how RBAC works.

Step 1: Define Roles (Role or ClusterRole): What actions are allowed within a namespace (Role) or across the entire cluster (ClusterRole).

Step 2: Creating Service Accounts or Users/Groups: Set up service accounts within Kubernetes or manage external users/groups to take on these roles.

Step 3: Bind Roles to Accounts, Users, or Groups: Use RoleBindings to connect roles to service accounts or users within a namespace, or ClusterRoleBindings for cluster-wide permissions.

Here is the simplified visualization of Kubernetes RBAC:

To further understand how RBAC operates, let’s break down the key roles in Kubernetes:

  • Cluster-admin: Acts as a superuser with full control over all resources across the cluster and namespaces.

  • Admin: Grants complete read and write access within a specific namespace, including creating roles and bindings but not modifying the namespace itself.

  • Edit: Allows read and write permissions within a namespace, excluding the ability to view or modify roles or bindings.

  • View: Provides read-only access within a namespace, without permission to view or change roles or bindings.

Creating an RBAC role is straightforward, so let’s not go there. Instead, let’s talk about more crucial elements:

How to Check Defined Permissions:

Always verify what your service accounts can do, blind spots lead to security breaches.

Use kubectl auth can-i 

These commands check if the app-sa service account in the prod-app namespace can get secrets, list pods, and create deployments.

kubectl auth can-i get secrets --namespace=prod-app --as=system:serviceaccount:prod-app:app-sa

kubectl auth can-i list pods --namespace=prod-app --as=system:serviceaccount:prod-app:app-sa

kubectl auth can-i create deployments --all-namespaces --as=system:serviceaccount:prod-app:app-sa

Why Default service account shouldn’t be used ?

Default service accounts often have broad permissions that can be a security risk. Create and use custom service accounts to better control and limit access.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: frontend-sa
  namespace: prod-app

Assign this service account to your frontend application pod:

apiVersion: v1
kind: Pod
metadata:
  name: frontend-pod
  namespace: prod-app
spec:
  serviceAccountName: frontend-sa

Disabling auto mounting of service account token

Only mount tokens when absolutely necessary for the pod's operation. This way you reduce the significant risk of token exposures.

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod
  namespace: prod-app
spec:
  serviceAccountName: backend-sa
  automountServiceAccountToken: false

Implementing Least Privilege access

Assign only the permissions that are absolutely necessary for a role to perform its tasks. This minimizes potential damage if a service account is compromised.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: prod-app
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list"]

Define roles for different permissions, not for different service accounts

This way, you avoid role duplication and can easily update permissions in one place without worrying about multiple service accounts having differing access levels.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: prod-app
  name: deployment-manager
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["create", "update", "delete"]

Security is everyone’s responsibility. RBAC just sets the boundaries.

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)

Looking to promote your company, product, service, or event to 57,000+ DevOps and Cloud Professionals? Let's work together.