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.
By the end, you will understand not just “what is RBAC” but how Kubernetes decides who can do what, how users authenticate, how ServiceAccounts allow automation, and how DevOps/SRE teams manage identity in production clusters.
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
AuthZ verifies permissions
AuthN happens first, AuthZ second
Successful AuthN does not imply AuthZ
1.2 Identity Types in Kubernetes
Kubernetes recognizes three identity types:
Users (humans / external systems)
Groups (collections of users)
ServiceAccounts (workloads running inside pods)
These identities come from different authentication systems.
SECTION 2 — Users, Groups, and ServiceAccounts (Beginner → Intermediate)
2.1 Users (Humans)
Users represent humans operating from outside the cluster using tools like:
kubectl
CI/CD system runners
dashboards
Terraform
SDKs
Important Facts
Kubernetes does not provide “create user”
Users are managed by external systems like:
Certificates (on-prem)
OIDC (Keycloak/Okta/AzureAD)
Cloud IAM (EKS/GKE/AKS)
MFA/SSO portals
2.2 Groups
A Group is a logical collection of users. Groups simplify permission assignments.
Example groups:
dev-team
sre-team
qa-team
security-team
Instead of granting permissions to 50 developers, assign once to dev-team.
2.3 ServiceAccounts
A ServiceAccount (SA) is an identity for workloads inside the cluster.
Pods use ServiceAccounts to authenticate to the Kubernetes API server.
Used by
Operators (cert-manager, prometheus-operator)
Controllers (ingress-nginx)
CI/CD agents (GitLab Runner, ArgoCD, FluxCD)
Monitoring systems (Prometheus)
Logging pipelines (Fluentbit)
Key Principle
Humans ≠ Workloads
Workloads must not use human credentials.
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"
Meaning:
CN=devuser → username
O=dev-team → group
Step 3: Sign certificate
openssl x509 -req -in devuser.csr \
-CA /etc/kubernetes/pki/ca.crt \
-CAkey /etc/kubernetes/pki/ca.key \
-CAcreateserial \
-out devuser.crt -days 365
Output
Signature ok
subject=CN=devuser,O=dev-team
Step 4: Add to kubeconfig
kubectl config set-credentials devuser \
--client-certificate=devuser.crt \
--client-key=devuser.key
Step 5: Create context
kubectl config set-context devctx --cluster=kubernetes --user=devuser
kubectl config use-context devctx
*Test access"
kubectl get pods
Expected Output
Error from server (Forbidden): pods is forbidden
This proves:
Authenticated ✔
Authorized ❌
We move next to authorization.
SECTION 4 — Authorization Using RBAC (Intermediate Level)
RBAC answers the second big question:
What can you do?
RBAC contains four building blocks:
Role
ClusterRole
RoleBinding
ClusterRoleBinding
4.1 RBAC Basics
Resources examples
pods
deployments
secrets
configmaps
nodes
Verbs examples
get
list
watch
create
update
patch
delete
Authorization works only if subject + verb + resource matches.
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
kind: Role
metadata:
name: pod-reader
namespace: dev
rules:
- apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"] Apply:
kubectl apply -f role.yaml
Output:
role.rbac.authorization.k8s.io/pod-reader created
5.2 Bind Role to User
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-dev-pods
namespace: dev
subjects:
- kind: User name: devuser roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io Apply:
kubectl apply -f rb.yaml
Output:
rolebinding.rbac.authorization.k8s.io/read-dev-pods created
5.3 Test Authorization
kubectl get pods -n dev
If pods exist, output:
NAME READY STATUS AGE
nginx 1/1 Running 5m
Cluster scope check:
Copy code
kubectl get nodes
Output:
Copy code
Error: User "devuser" cannot list resource "nodes" at cluster scope
RBAC least privilege achieved.
SECTION 6 — Cluster-Level Access (Advanced)
Some workloads need cluster-level visibility.
Example: Prometheus needs node info.
6.1 Create ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: node-reader
rules:
- 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: ClusterRoleBinding
metadata:
name: node-read-binding
subjects:
- kind: ServiceAccount name: prometheus-sa namespace: monitoring roleRef: kind: ClusterRole name: node-reader apiGroup: rbac.authorization.k8s.io Apply:
kubectl apply -f crb.yaml
Verify using auth can-i
kubectl auth can-i list nodes --as=system:serviceaccount:monitoring:prometheus-sa
Output:
yes
SECTION 7 — ServiceAccount in Deployment
Attach SA to Deployment:
spec:
serviceAccountName: prometheus-sa
Apply and verify SA token inside pod:
kubectl exec -it prometheus-xxxx -n monitoring -- ls /var/run/secrets/kubernetes.io/serviceaccount
Output:
ca.crt
namespace
token
SECTION 8 — Real DevOps/SRE Scenarios (Expert Level)
8.1 Developers
Needs: ✔ create deployments
✔ view logs
✔ exec into pods
❌ cluster-admin
❌ node-level access
❌ secrets in other namespaces
8.2 CI/CD
Example: GitLab Runner
Needs: ✔ create/update deployments
✔ watch pods
❌ delete nodes
❌ list secrets
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
IAM → aws-auth → RBAC
AKS
Azure AD → RBAC
GKE
GCP IAM → RBAC + Workload Identity
SECTION 10 — Anti-Patterns (Real world mistakes)
Common failures:
❌ cluster-admin for CI/CD
❌ default ServiceAccounts
❌ long-lived tokens
❌ uncontrolled secrets
❌ no MFA for human users
❌ no namespace boundaries
SECTION 11 — Best Practices (Enterprise Grade)
✔ use SSO/OIDC for humans
✔ use ServiceAccounts for workloads
✔ use Groups for onboarding
✔ least privilege RBAC
✔ rotate tokens
✔ enable audit logs
✔ never give cluster-admin casually
✔ use namespace isolation
✔ review RBAC regularly
✔ secure cloud IAM integration
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.
Top comments (0)