Kubernetes IAM & RBAC for DevOps & SRE

Source: Dev.to

Understanding Identity in Kubernetes (Beginner Level)

Authentication vs Authorization

• Authentication – Who are you?
• Authorization – What can you do?

Kubernetes separates these duties: authentication verifies identity, while authorization determines permissions.

Identity Types in Kubernetes

Kubernetes recognizes three identity types:

1. Users – human operators or external systems.
2. Groups – logical collections of users.
3. ServiceAccounts – identities for workloads running inside pods.

Users, Groups, and ServiceAccounts (Beginner → Intermediate)

Users (Humans)

Users represent people operating from outside the cluster (e.g., via kubectl).

Note: Kubernetes does not provide a built‑in create user command; users are typically managed outside the cluster (e.g., via certificates or external identity providers).

Groups

A group is a logical collection of users, simplifying permission assignments.

ServiceAccounts

A ServiceAccount (SA) is an identity for workloads inside the cluster.
Typical consumers include operators such as cert‑manager and prometheus‑operator.

Key principle: Humans ≠ Workloads.

Authentication in Practice (Intermediate Level)

Practical: Create a User (certificate authentication)

# Step 1: Generate a private key
openssl genrsa -out devuser.key 2048

# Step 2: Generate a CSR
openssl req -new -key devuser.key -out devuser.csr \
  -subj "/CN=devuser/O=dev-team"

# Step 3: Sign the certificate (using the cluster’s CA)
openssl x509 -req -in devuser.csr \
  -CA /etc/kubernetes/pki/ca.crt \
  -CAkey /etc/kubernetes/pki/ca.key \
  -CAcreateserial -out devuser.crt -days 365

# Step 4: Add the user to your kubeconfig
kubectl config set-credentials devuser \
  --client-certificate=devuser.crt \
  --client-key=devuser.key

# Step 5: Create a context for the new user
kubectl config set-context devctx \
  --cluster=kubernetes \
  --user=devuser

Test access

kubectl --context=devctx get pods
# Expected output:
# Error from server (Forbidden): pods is forbidden

Authorization Using RBAC (Intermediate Level)

RBAC Basics

RBAC (Role‑Based Access Control) answers “what can you do?” by binding subjects (users, groups, service accounts) to roles that define allowed resources and verbs.

• Resources examples: pods, deployments, nodes
• Verbs examples: get, list, watch, create, delete

Practical RBAC Configuration

Create a Role (namespace‑scoped)

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

kubectl apply -f role.yaml
# role.rbac.authorization.k8s.io/pod-reader created

Bind the Role to a User

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

kubectl apply -f rolebinding.yaml
# rolebinding.rbac.authorization.k8s.io/read-dev-pods created

Test Authorization

# Should succeed (read‑only access to pods in dev)
kubectl --context=devctx get pods -n dev

# Should fail (no cluster‑scope permission)
kubectl --context=devctx get nodes
# Output:
# Error: User "devuser" cannot list resource "nodes" at cluster scope

Cluster‑Level Access (Advanced)

Create a ClusterRole

# clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-reader
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

kubectl apply -f clusterrole.yaml
# clusterrole.rbac.authorization.k8s.io/node-reader created

Bind the ClusterRole to a ServiceAccount

# clusterrolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: node-reader-binding
subjects:
- kind: ServiceAccount
  name: prometheus-sa
  namespace: monitoring
roleRef:
  kind: ClusterRole
  name: node-reader
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f clusterrolebinding.yaml
# clusterrolebinding.rbac.authorization.k8s.io/node-reader-binding created

Verify access

kubectl auth can-i list nodes --as=system:serviceaccount:monitoring:prometheus-sa
# Output: yes

ServiceAccount in a Deployment

Attach the ServiceAccount to a Deployment (excerpt):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus
  namespace: monitoring
spec:
  template:
    spec:
      serviceAccountName: prometheus-sa
      containers:
      - name: prometheus
        image: prom/prometheus:latest

You can verify the mounted credentials inside a pod:

kubectl exec -it prometheus-xxxx -n monitoring -- ls /var/run/secrets/kubernetes.io/serviceaccount
# Output:
# ca.crt  token  namespace

Real DevOps/SRE Scenarios (Expert Level)

Cloud IAM Integration (Expert Level)

Kubernetes itself does not provide enterprise‑grade IAM. Cloud providers offer integrations that map external identities to Kubernetes RBAC:

• Amazon EKS – IAM roles for service accounts (IRSA)
• Azure AKS – Azure AD integration
• Google GKE – GCP IAM bindings

These bridges let you leverage existing cloud IAM policies for cluster access.

Anti‑Patterns (Real‑World Mistakes)

• Granting cluster‑admin to service accounts used by applications.
• Using static certificates for human users without rotation.
• Over‑privileged RoleBindings (e.g., * verbs on * resources).
• Mixing human and workload identities in the same group.

Best Practices (Enterprise Grade)

• Use SSO/OIDC for human authentication.
• Prefer short‑lived tokens and certificate rotation.
• Apply the principle of least privilege in Role/ClusterRole definitions.
• Separate namespace‑scoped and cluster‑scoped permissions.
• Regularly audit RBAC bindings (kubectl get rolebindings,clusterrolebindings).
• Leverage Pod Security Standards and NetworkPolicies alongside RBAC.

Conclusion

By following this guide you should now understand:

• How Kubernetes authentication works (certificates, OIDC, etc.)
• The distinction between users, groups, and service accounts
• RBAC theory, role creation, and binding mechanisms
• Namespace‑scoped vs. cluster‑scoped permissions
• Practical YAML manifests and command‑line workflows
• Real‑world DevOps/SRE identity scenarios and cloud IAM integrations
• Common anti‑patterns and enterprise‑grade best practices

This mental model is what production‑grade SRE and Platform Engineers rely on to run secure, maintainable Kubernetes clusters.