Chapter 76: DevOps Projects Part 6: Kubernetes Canary Helm RBAC NetworkPolicy Quotas EKS Microservices Velero Upgrade

76.3 Project 42: RBAC for separate dev and ops teams

By Ravindra Bagale Last updated: 28 October 2026

Friends, RBAC says who can touch which objects. Today we make team-dev and team-ops namespaces, Roles, RoleBindings, a ClusterRole for nodes, and prove rights with kubectl auth can-i.

What you will build in this project

Namespaces and ServiceAccounts.
Role and RoleBinding for each team.
ClusterRole for nodes.
can-i proof commands.

1. Start from a real company story

At Razorpay in Bengaluru, a shared cluster-admin kubeconfig leaked into a contractor laptop.

Ananya rotated credentials and split Roles. Rough past cost of the scare: about ₹1 crore in audit overtime.

Today we build that split.

Picture 1: User/SA → RoleBinding → Role → verbs on resources

Ravindra Bagale's Tip

Students often bind cluster-admin because the first error goes away. That is the worst habit. Start read-only. Keep that habit.

2. Start and prepare

Step 1: Why RBAC

Why: Who can do what. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.

What: echo. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.

Example 1: a1

Type this:

echo 'RBAC decides who can do what on which Kubernetes objects'

You will see:

RBAC decides who can do what on which Kubernetes objects

What it means: What RBAC is.

Example 2: a2

Type this:

echo 'Role and RoleBinding are namespaced; ClusterRole and ClusterRoleBinding are cluster-wide'

You will see:

Role and RoleBinding are namespaced; ClusterRole and ClusterRoleBinding are cluster-wide

What it means: Four kinds.

Example 3: a3

Type this:

echo 'Subjects are Users, Groups, or ServiceAccounts'

You will see:

Subjects are Users, Groups, or ServiceAccounts

What it means: Who gets rights.

Step 2: Namespaces and SAs

Why: Create subjects. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.

What: kubectl create. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.

Example 4: b1

Type this:

echo 'kubectl create namespace team-dev; kubectl create namespace team-ops'

You will see:

kubectl create namespace team-dev; kubectl create namespace team-ops

What it means: Two team namespaces.

Example 5: b2

Type this:

echo 'kubectl create serviceaccount sa-dev -n team-dev'

You will see:

kubectl create serviceaccount sa-dev -n team-dev

What it means: Dev ServiceAccount.

Example 6: b3

Type this:

echo 'kubectl create serviceaccount sa-ops -n team-ops'

You will see:

kubectl create serviceaccount sa-ops -n team-ops

What it means: Ops ServiceAccount.

Step 3: Dev Role Binding

Why: Dev edit rights. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.

What: printf Role. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.

Example 7: c1

Type this:

mkdir -p /tmp/k8s42 && printf '%s\n' 'apiVersion: rbac.authorization.k8s.io/v1' 'kind: Role' 'metadata: {name: dev-edit, namespace: team-dev}' 'rules:' '- apiGroups: ["apps"]' '  resources: ["deployments"]' '  verbs: ["get","list","watch","create","update","patch"]' '- apiGroups: [""]' '  resources: ["pods","services","configmaps"]' '  verbs: ["get","list","watch","create","update","patch","delete"]' > /tmp/k8s42/role-dev.yaml && grep -A2 'kind: Role' /tmp/k8s42/role-dev.yaml

You will see:

kind: Role
metadata: {name: dev-edit, namespace: team-dev}

What it means: Dev Role: edit Deployments Pods Services ConfigMaps.

Example 8: c2

Type this:

printf '%s\n' 'apiVersion: rbac.authorization.k8s.io/v1' 'kind: RoleBinding' 'metadata: {name: bind-dev, namespace: team-dev}' 'subjects:' '- kind: ServiceAccount' '  name: sa-dev' '  namespace: team-dev' 'roleRef:' '  apiGroup: rbac.authorization.k8s.io' '  kind: Role' '  name: dev-edit' > /tmp/k8s42/rb-dev.yaml && cat /tmp/k8s42/rb-dev.yaml

You will see:

kind: RoleBinding

What it means: Bind sa-dev to Role.

Example 9: c3

Type this:

echo 'kubectl apply -f /tmp/k8s42/role-dev.yaml -f /tmp/k8s42/rb-dev.yaml'

You will see:

kubectl apply -f ...

What it means: Apply Role and RoleBinding.

3. Build the main pieces

Step 4: Ops Role Binding

Why: Ops read rights. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.

What: printf ops. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.

Example 10: d1

Type this:

printf '%s\n' 'apiVersion: rbac.authorization.k8s.io/v1' 'kind: Role' 'metadata: {name: ops-view-all, namespace: team-ops}' 'rules:' '- apiGroups: ["*"]' '  resources: ["*"]' '  verbs: ["get","list","watch"]' > /tmp/k8s42/role-ops.yaml && cat /tmp/k8s42/role-ops.yaml

You will see:

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

What it means: Ops Role: read-only in team-ops.

Example 11: d2

Type this:

printf '%s\n' 'apiVersion: rbac.authorization.k8s.io/v1' 'kind: RoleBinding' 'metadata: {name: bind-ops, namespace: team-ops}' 'subjects:' '- kind: ServiceAccount' '  name: sa-ops' '  namespace: team-ops' 'roleRef:' '  apiGroup: rbac.authorization.k8s.io' '  kind: Role' '  name: ops-view-all' > /tmp/k8s42/rb-ops.yaml && echo applied-ops-yaml

You will see:

applied-ops-yaml

What it means: Ops RoleBinding YAML.

Example 12: d3

Type this:

echo 'kubectl apply -f /tmp/k8s42/role-ops.yaml -f /tmp/k8s42/rb-ops.yaml'

You will see:

kubectl apply -f ...

What it means: Apply ops Role and binding.

Step 5: can-i proofs

Why: Prove. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.

What: can-i. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.

Example 13: e1

Type this:

echo 'kubectl auth can-i create deployments --as=system:serviceaccount:team-dev:sa-dev -n team-dev'

You will see:

kubectl auth can-i create deployments --as=...sa-dev -n team-dev

What it means: Expect yes for dev.

Example 14: e2

Type this:

echo 'kubectl auth can-i delete namespaces --as=system:serviceaccount:team-dev:sa-dev'

You will see:

kubectl auth can-i delete namespaces --as=...sa-dev

What it means: Expect no.

Example 15: e3

Type this:

echo 'kubectl auth can-i create deployments --as=system:serviceaccount:team-ops:sa-ops -n team-ops'

You will see:

kubectl auth can-i create deployments --as=...sa-ops -n team-ops

What it means: Expect no for read-only ops.

Step 6: ClusterRole

Why: Nodes. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.

What: printf CR. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.

Example 16: f1

Type this:

echo 'ClusterRole for cluster-scoped reads: nodes and namespaces'

You will see:

ClusterRole for cluster-scoped reads: nodes and namespaces

What it means: When ClusterRole is needed.

Example 17: f2

Type this:

printf '%s\n' 'apiVersion: rbac.authorization.k8s.io/v1' 'kind: ClusterRole' 'metadata: {name: node-reader}' 'rules:' '- apiGroups: [""]' '  resources: ["nodes"]' '  verbs: ["get","list"]' > /tmp/k8s42/cr.yaml && cat /tmp/k8s42/cr.yaml

You will see:

kind: ClusterRole

What it means: ClusterRole YAML.

Example 18: f3

Type this:

echo 'kubectl apply -f /tmp/k8s42/cr.yaml'

You will see:

kubectl apply -f /tmp/k8s42/cr.yaml

What it means: Apply ClusterRole.

4. Automate and verify

Step 7: ClusterRoleBinding

Why: Bind nodes. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.

What: printf CRB. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.

Example 19: g1

Type this:

printf '%s\n' 'apiVersion: rbac.authorization.k8s.io/v1' 'kind: ClusterRoleBinding' 'metadata: {name: ops-nodes}' 'subjects:' '- kind: ServiceAccount' '  name: sa-ops' '  namespace: team-ops' 'roleRef:' '  apiGroup: rbac.authorization.k8s.io' '  kind: ClusterRole' '  name: node-reader' > /tmp/k8s42/crb.yaml && cat /tmp/k8s42/crb.yaml

You will see:

kind: ClusterRoleBinding

What it means: Bind sa-ops to node-reader.

Example 20: g2

Type this:

echo 'kubectl apply -f /tmp/k8s42/crb.yaml'

You will see:

kubectl apply -f /tmp/k8s42/crb.yaml

What it means: Apply ClusterRoleBinding.

Example 21: g3

Type this:

echo 'kubectl auth can-i get nodes --as=system:serviceaccount:team-ops:sa-ops'

You will see:

kubectl auth can-i get nodes --as=...sa-ops

What it means: Expect yes.

Step 8: Least privilege audit

Why: Habits. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.

What: echo habits. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.

Example 22: h1

Type this:

echo 'Least privilege: start with get list watch then add verbs you prove you need'

You will see:

Least privilege: start with get list watch then add verbs you prove you need

What it means: Least privilege.

Example 23: h2

Type this:

echo 'Never bind cluster-admin to a team ServiceAccount for convenience'

You will see:

Never bind cluster-admin to a team ServiceAccount for convenience

What it means: Danger habit.

Example 24: h3

Type this:

echo 'Audit tip: kubectl get rolebindings,clusterrolebindings -A'

You will see:

Audit tip: kubectl get rolebindings,clusterrolebindings -A

What it means: List bindings.

Step 9: OIDC and describe

Why: Identity. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.

What: describe. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.

Example 25: i1

Type this:

echo 'Impersonation with --as is for tests; real users come from your identity provider'

You will see:

Impersonation with --as is for tests; real users come from your identity provider

What it means: OIDC tip.

Example 26: i2

Type this:

echo 'kubectl describe rolebinding bind-dev -n team-dev'

You will see:

kubectl describe rolebinding bind-dev -n team-dev

What it means: Inspect binding.

Example 27: i3

Type this:

echo 'Document who owns each Role in your notebook'

You will see:

Document who owns each Role in your notebook

What it means: Ownership habit.

5. Harden and accept

Step 10: Default deny tips

Why: Deny default. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.

What: deny tips. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.

Example 28: j1

Type this:

echo 'Deny by default: if no Role allows a verb, Kubernetes denies'

You will see:

Deny by default: if no Role allows a verb, Kubernetes denies

What it means: Default deny.

Example 29: j2

Type this:

echo 'ResourceNames can lock a Role to one named Secret'

You will see:

ResourceNames can lock a Role to one named Secret

What it means: Fine-grained tip.

Example 30: j3

Type this:

echo 'AggregationRule can build ClusterRoles from labels'

You will see:

AggregationRule can build ClusterRoles from labels

What it means: Advanced tip.

Step 11: Cleanup

Why: Cleanup. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.

What: cleanup. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.

Example 31: k1

Type this:

echo 'Optional cleanup: kubectl delete ns team-dev team-ops; kubectl delete clusterrole node-reader; kubectl delete clusterrolebinding ops-nodes'

You will see:

Optional cleanup: kubectl delete ns ...

What it means: Cleanup.

Example 32: k2

Type this:

echo 'Save Role and RoleBinding YAML for both teams'

You will see:

Save Role and RoleBinding YAML for both teams

What it means: Artifact.

Example 33: k3

Type this:

echo 'Next project adds NetworkPolicies between namespaces'

You will see:

Next project adds NetworkPolicies between namespaces

What it means: Bridge.

Step 12: Acceptance

Why: Ananya signs off. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.

What: All green. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.

Example 34: z1

Type this:

echo 'can-i checks prove dev can edit and ops is read-only'

You will see:

can-i checks prove dev can edit and ops is read-only

What it means: Checklist can-i.

Example 35: z2

Type this:

echo 'No cluster-admin for team SAs'

You will see:

No cluster-admin for team SAs

What it means: Checklist admin.

Example 36: z3

Type this:

echo 'Ananya: PASS'

You will see:

Ananya: PASS

What it means: Project 42 accepted.

Check yourself

Q1. Who fixed Razorpay?

Ananya

Q2. Dev namespace?

team-dev

Q3. Prove rights command?

kubectl auth can-i

Q4. Cluster-scoped Role kind?

ClusterRole

Q5. Bind SA to Role kind?

RoleBinding

Q6. Default if no rule?

deny

Friends, you separated team rights and proved them with can-i. Did you understand? Let us try it once more. Add a Group subject from your identity provider next.

Lab: try at home

Create namespaces and SAs.
Write Role and RoleBinding for dev.
Write read-only Role for ops.
Add ClusterRole for nodes.
Prove with can-i.

Recap

Least privilege.
Namespaced vs cluster-scoped.
Never team cluster-admin.
can-i before go-live.
Document Role owners.