Kubernetes IAM & RBAC for DevOps & SRE

Kubernetes security often confuses even experienced engineers because it mixes human identity, machine identity, permissions, tokens, API access, namespaces, cloud IAM, and workload automation. This guide explains all of it in a single walkthrough — from absolute basics to real-world cluster administration. SECTION 1 — Understanding Identity in Kubernetes (Beginner Level) 1.1 Concept: Authentication vs Authorization To reason about Kubernetes access, you must separate two ideas: Authentication = Who are you? Authorization = What can you do? Kubernetes strictly separates these duties. Bullet Memory AuthN verifies identity 1.2 Identity Types in Kubernetes Kubernetes recognizes three identity types: Users (humans / external systems) Groups (collections of users) ServiceAccounts (workloads running inside pods) SECTION 2 — Users, Groups, and ServiceAccounts (Beginner → Intermediate) 2.1 Users (Humans) Users represent humans operating from outside the cluster using tools like: Important Facts Kubernetes does not provide “create user” 2.2 Groups A Group is a logical collection of users. Groups simplify permission assignments. 2.3 ServiceAccounts A ServiceAccount (SA) is an identity for workloads inside the cluster. Used by Operators (cert-manager, prometheus-operator) Key Principle Humans ≠ Workloads SECTION 3 — Authentication in Practice (Intermediate Level) We'll now create an actual Kubernetes user using certificate authentication (common in kubeadm clusters). 3.1 Practical: Create User Step 1: Generate private key openssl genrsa -out devuser.key 2048 Output Generating RSA private key, 2048 bit long modulus Step 2: Generate CSR openssl req -new -key devuser.key -out devuser.csr -subj "/CN=devuser/O=dev-team" Step 3: Sign certificate openssl x509 -req -in devuser.csr \ Output Signature ok Step 4: Add to kubeconfig kubectl config set-credentials devuser \ Step 5: Create context kubectl config set-context devctx --cluster=kubernetes --user=devuser *Test access" kubectl get pods Expected Output Error from server (Forbidden): pods is forbidden SECTION 4 — Authorization Using RBAC (Intermediate Level) RBAC answers the second big question: 4.1 RBAC Basics Resources examples pods Verbs examples SECTION 5 — Practical RBAC Configuration 5.1 Create Role (namespace scope) Create a role that allows read-only access to pods in dev namespace: apiVersion: rbac.authorization.k8s.io/v1 apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"] Apply: kubectl apply -f role.yaml role.rbac.authorization.k8s.io/pod-reader created 5.2 Bind Role to User apiVersion: rbac.authorization.k8s.io/v1 kind: User name: devuser roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io Apply: kubectl apply -f rb.yaml rolebinding.rbac.authorization.k8s.io/read-dev-pods created 5.3 Test Authorization kubectl get pods -n dev NAME READY STATUS AGE kubectl get nodes Error: User "devuser" cannot list resource "nodes" at cluster scope SECTION 6 — Cluster-Level Access (Advanced) Some workloads need cluster-level visibility. 6.1 Create ClusterRole apiVersion: rbac.authorization.k8s.io/v1 apiGroups: [""] resources: ["nodes"] verbs: ["get", "list", "watch"] Apply: kubectl apply -f cr.yaml 6.2 Bind to ServiceAccount apiVersion: rbac.authorization.k8s.io/v1 kind: ServiceAccount name: prometheus-sa namespace: monitoring roleRef: kind: ClusterRole name: node-reader apiGroup: rbac.authorization.k8s.io Apply: kubectl apply -f crb.yaml kubectl auth can-i list nodes --as=system:serviceaccount:monitoring:prometheus-sa yes SECTION 7 — ServiceAccount in Deployment Attach SA to Deployment: spec: kubectl exec -it prometheus-xxxx -n monitoring -- ls /var/run/secrets/kubernetes.io/serviceaccount ca.crt SECTION 8 — Real DevOps/SRE Scenarios (Expert Level) 8.1 Developers Needs: ✔ create deployments 8.2 CI/CD Example: GitLab Runner 8.3 Operators cert-manager and ArgoCD require API write access. SECTION 9 — Cloud IAM Integration (Expert Level) Kubernetes does not handle enterprise IAM by itself. Cloud provides bridge: EKS AKS GKE SECTION 10 — Anti-Patterns (Real world mistakes) Common failures: SECTION 11 — Best Practices (Enterprise Grade) ✔ use SSO/OIDC for humans SECTION 12 — Conclusion If you followed along, you learned: how kube authentication works users vs groups vs serviceaccounts RBAC theory and binding namespace vs cluster scope real YAML + commands + outputs DevOps/SRE identity scenarios cloud IAM fusion anti-patterns & best practices This is the complete mental model used by real SRE and Platform Engineers running production clusters.