RBAC and Authentication

🔐 Kubernetes Security: RBAC and Authentication

The Story of the Castle Kingdom

Imagine a magical castle called Kubernetes Kingdom. Inside this castle, there are many precious rooms filled with treasures (your applications and data). But you can’t let just anyone walk in and touch everything!

So the wise king created a special system called RBAC — Role-Based Access Control. It’s like giving different magic keys to different people based on their job.

🏰 What is RBAC?

RBAC stands for Role-Based Access Control.

Think of it like a school:

• The principal can do everything
• Teachers can enter classrooms and give grades
• Students can only see their own grades
• The janitor can open cleaning closets but not the principal’s office

In Kubernetes, RBAC decides WHO can do WHAT to WHICH resources.

graph TD
    A["User/Service"] --> B{RBAC Check}
    B -->|Allowed| C["✅ Access Granted"]
    B -->|Denied| D["❌ Access Denied"]

Real-Life Example

• Developer Alice → Can read pods in dev namespace
• Admin Bob → Can do everything in all namespaces
• CI/CD Pipeline → Can only deploy to staging namespace

👑 Roles and ClusterRoles

These are like job descriptions that list what powers you get.

Role (Namespace-Specific)

A Role is like a key that only works in ONE room (namespace).

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

What this means:

• 📦 Only works in the dev namespace
• 👀 Can look at pods (get, list, watch)
• ❌ Cannot create or delete pods

ClusterRole (Entire Kingdom)

A ClusterRole is like a master key that works everywhere in the castle.

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

What this means:

• 🌍 Works in ALL namespaces
• 🔒 Can read secrets everywhere

graph TD
    A["Role"] -->|Works in| B["One Namespace"]
    C["ClusterRole"] -->|Works in| D["All Namespaces"]
    C -->|Can also access| E["Cluster Resources"]

🎀 RoleBindings Overview

Roles are job descriptions. RoleBindings are like hiring someone for that job.

Think of it this way:

• Role = “Pizza Delivery Driver” (the job description)
• RoleBinding = “Tom is hired as Pizza Delivery Driver”

RoleBinding (For One Namespace)

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: dev
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Translation: “Alice can use the pod-reader powers in dev namespace”

ClusterRoleBinding (For Entire Cluster)

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-binding
subjects:
- kind: User
  name: bob
roleRef:
  kind: ClusterRole
  name: cluster-admin

Translation: “Bob has admin powers everywhere!”

graph LR
    A["User"] -->|RoleBinding| B["Role"]
    A -->|ClusterRoleBinding| C["ClusterRole"]
    B --> D["Namespace Access"]
    C --> E["Cluster-wide Access"]

⚡ RBAC Verbs and Permissions

Verbs are the actions you can perform. Think of them like instructions:

Example: Read-Only Access

verbs: ["get", "list", "watch"]

Like a museum visitor — look but don’t touch!

Example: Full Control

verbs: ["*"]

The asterisk means “everything” — full power!

Special Verbs for Subresources

rules:
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get"]
- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["create"]

This lets someone:

• 📜 Read pod logs (pods/log)
• 💻 Execute commands in pods (pods/exec)

🤖 Service Accounts

Service Accounts are like robot workers in your castle. They’re not humans — they’re programs that need permissions too!

Why Do We Need Them?

Your applications (pods) need to talk to Kubernetes. But they need permission first!

Default Behavior

Every namespace has a default service account. But it has almost no powers (for safety).

Creating a Custom Service Account

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: production

Giving It Powers

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: my-app-binding
  namespace: production
subjects:
- kind: ServiceAccount
  name: my-app-sa
  namespace: production
roleRef:
  kind: Role
  name: pod-reader

Using It in a Pod

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  serviceAccountName: my-app-sa
  containers:
  - name: app
    image: my-app:v1

graph TD
    A["Pod"] -->|Uses| B["Service Account"]
    B -->|Gets Token| C["Kubernetes API"]
    C -->|Checks| D["RBAC Rules"]
    D -->|Allowed?| E["Access Resource"]

🔑 Authentication Methods

Authentication = Proving WHO you are (like showing your ID card)

Kubernetes supports many ways to prove your identity:

1. X.509 Client Certificates 📜

Like a fancy ID card signed by a trusted authority.

# In your kubeconfig
users:
- name: alice
  user:
    client-certificate: /path/to/alice.crt
    client-key: /path/to/alice.key

2. Bearer Tokens 🎫

Like a ticket you show to get in.

# Service accounts use this
curl -H "Authorization: Bearer $TOKEN" \
  https://kubernetes/api/v1/pods

3. OpenID Connect (OIDC) 🌐

Like using “Login with Google” for your castle!

Great for:

• Large organizations
• Single sign-on (SSO)
• Integration with identity providers

4. Webhook Token Authentication 🪝

Kubernetes asks an external service to verify tokens.

5. Static Token File (Not Recommended) ⚠️

A simple file with usernames and tokens. Only for testing!

graph TD
    A["User Request"] --> B{Authentication}
    B -->|Certificate| C["X.509 Check"]
    B -->|Token| D["Token Validation"]
    B -->|OIDC| E["Identity Provider"]
    C --> F["Identity Confirmed"]
    D --> F
    E --> F

🚦 Authorization Modes

After proving WHO you are (authentication), Kubernetes decides WHAT you can do (authorization).

Available Modes

How They Work Together

The API server can use multiple modes. It tries each one in order:

# Typical configuration
--authorization-mode=Node,RBAC

graph LR
    A["Request"] --> B["Node Mode"]
    B -->|Not Handled| C["RBAC Mode"]
    B -->|Allowed| D["✅ Success"]
    C -->|Allowed| D
    C -->|Denied| E["❌ Forbidden"]

RBAC is King 👑

RBAC is the recommended mode because:

• ✅ Fine-grained control
• ✅ Easy to understand
• ✅ Namespace isolation
• ✅ Auditable

⚔️ Role vs ClusterRole: The Final Showdown

Let’s settle this once and for all!

When to Use Role

# Perfect for: "Alice can only work in dev namespace"
kind: Role
metadata:
  namespace: dev

When to Use ClusterRole

# Perfect for: "Bob needs to see all namespaces"
kind: ClusterRole
# No namespace field - it's cluster-wide!

Pro Tip: Reuse ClusterRoles with RoleBinding! 🧙‍♂️

You can use a ClusterRole with a RoleBinding to limit it to one namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-pod-reader
  namespace: dev
subjects:
- kind: User
  name: charlie
roleRef:
  kind: ClusterRole  # Using ClusterRole!
  name: pod-reader

Magic Result: Charlie gets pod-reader powers, but ONLY in dev namespace!

graph TD
    A["ClusterRole: pod-reader"] --> B["RoleBinding in dev"]
    A --> C["RoleBinding in staging"]
    A --> D["ClusterRoleBinding"]
    B --> E["Access in dev only"]
    C --> F["Access in staging only"]
    D --> G["Access everywhere"]

🎯 Summary: Your RBAC Cheat Code

1. RBAC = Who can do what to which resources
2. Role = Powers for ONE namespace
3. ClusterRole = Powers for ENTIRE cluster
4. RoleBinding = Give Role to a user/group/service account
5. Verbs = Actions (get, list, create, delete, etc.)
6. Service Accounts = Robot identities for your apps
7. Authentication = Proving WHO you are
8. Authorization = Deciding WHAT you can do

The Golden Rule 🌟

Principle of Least Privilege: Give only the permissions needed, nothing more!

Like giving the pizza delivery person a key to only the lobby — not your bedroom!

🚀 You’ve Got This!

RBAC might seem scary at first, but remember:

• It’s just about matching people to permissions
• Start simple, add complexity only when needed
• Always test with kubectl auth can-i

# Check if you can do something
kubectl auth can-i create pods
kubectl auth can-i delete secrets --namespace dev

Now go forth and secure your Kubernetes kingdom! 🏰✨