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.

The Tech newsletter for Engineers who want to stay ahead

Tech moves fast, but you're still playing catch-up?

Here's what you get:

  • Curated tech news that shapes your career - Filtered from thousands of sources so you know what's coming 6 months early.

  • Practical resources you can use immediately - Real tutorials and tools that solve actual engineering problems.

  • Research papers and insights decoded - We break down complex tech so you understand what matters.

All in just 5 minutes a day.

IN TODAY'S EDITION

🧠 Use Case
  • How Kubernetes RBAC Decision Flow Works

👀 Remote Jobs

Powered by: Jobsurface.com

📚 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

gemini-cli - An open source AI agent that brings the power of Gemini directly into your terminal.

Free tier: 60 requests/min and 1,000 requests/day with personal Google account.

🧠 USE CASE

How Kubernetes RBAC Decision Flow Works

RBAC, or Role Based Access Control, is a critical concept every DevOps and Cloud Engineer must understand. It defines who can perform what actions on which resources. Whether managing Kubernetes, cloud accounts, or CI/CD pipelines, it brings structure to access control, makes permissions predictable, and helps teams manage security at scale.

When a user, service account, or process tries to perform an action (verb) on a resource (like deployments) in a namespace, Kubernetes uses the following flow to determine if the action is allowed:

1. API Server Receives the Request

The request could be: GET /apis/apps/v1/namespaces/dev/deployments/nginx-deploy

It includes:

  • Verb: get

  • Resource: deployments

  • Namespace: dev

  • User identity

2. Authentication

The API server authenticates the request using one of the supported methods:

  • Client certificate authentication from the kube-apiserver configuration

  • Bearer tokens (including service account tokens)

  • OIDC tokens configured with an identity provider

For this example, the identity resolved is:
User = [email protected]

3. Authorization

The RBAC authorizer processes the authenticated identity and evaluates it against:

  • RoleBindings and ClusterRoleBindings present in etcd.

  • Corresponding Roles or ClusterRoles defined in the cluster.

# Role allowing get on deployments in namespace dev
kind: Role
metadata:
  namespace: dev
  name: view-deployments
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list"]
# RoleBinding assigning above role to user from techopsexamples
kind: RoleBinding
metadata:
  name: deployment-reader
  namespace: dev
subjects:
- kind: User
  name: [email protected]
roleRef:
  kind: Role
  name: view-deployments
  apiGroup: rbac.authorization.k8s.io

4. Match Rules

The RBAC authorizer iterates through all applicable rules in the matched Roles or ClusterRoles. Checks whether any rule allows the verb on the resource in the given namespace

Each rule contains:

  • verbs (e.g., get, list)

  • resources (e.g., deployments)

  • apiGroups (e.g., apps)

  • resourceNames (optional, e.g., only certain deployments)

5. Decision

  • If any rule matches, the RBAC authorizer grants access

  • If no rule matches, the API server returns 403 Forbidden

Test the calculation:

kubectl auth can-i get deployments --as [email protected] --namespace dev

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

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

Keep Reading