Implement proper RBAC for a multi-tenant cluster where teams should not access each other's resources.

Q: Implement proper RBAC for a multi-tenant cluster where teams should not access each other's resources.

Learn the answer to "Implement proper RBAC for a multi-tenant cluster where teams should not access each other's resources." with detailed explanations, code examples, and best practices on DeployU.

The Scenario

You’re the Platform Security Lead at a fast-growing tech company. Your company uses a shared Kubernetes cluster for multiple product teams:

Team Alpha: E-commerce platform (namespace: alpha-prod, alpha-dev)
Team Beta: Analytics dashboard (namespace: beta-prod, beta-dev)
Team Gamma: Internal tools (namespace: gamma-prod, gamma-dev)

Current problem: All developers have cluster-admin access. Last week:

A Team Alpha developer accidentally deleted Team Beta’s production database
A Team Gamma engineer viewed Team Alpha’s secrets containing API keys
Your security audit failed due to insufficient access controls

Your CISO mandates:

Principle of Least Privilege: Teams can only access their own namespaces
Role Separation: Developers can deploy, but cannot view secrets in production
Admin Access: Only platform team has cluster-wide admin rights
Compliance: All access must be auditable (who did what, when)

The Challenge

Design and implement a complete RBAC (Role-Based Access Control) strategy that:

Isolates teams to their own namespaces
Differentiates between dev and prod permissions
Provides read-only access for on-call engineers
Allows platform team to manage everything

How Different Experience Levels Approach This

Junior Engineer

Surface Level

I'll create a single role for all developers and bind it to everyone using ClusterRoleBinding with the built-in 'edit' role. This gives everyone access but violates least privilege.

Technically correct, but lacks depth

Senior Engineer

Production Ready

Enterprise-grade RBAC requires a hierarchy: Cluster Admins → Namespace Admins → Developers → Viewers. Use ClusterRoles for reusability, bind with RoleBindings for namespace-specific access.

RBAC Hierarchy Design:

Cluster Admins (Platform Team)
    ↓
Namespace Admins (Team Leads)
    ↓
Developers (Read/Write in dev, Deploy in prod)
    ↓
Viewers (Read-only for on-call)

Step 1: Create Namespaces with Labels

apiVersion: v1
kind: Namespace
metadata:
  name: alpha-prod
  labels:
    team: alpha
    environment: production
---
apiVersion: v1
kind: Namespace
metadata:
  name: alpha-dev
  labels:
    team: alpha
    environment: development

Step 2: Define ClusterRoles (Reusable Across Namespaces)

# Role for developers in dev environments (full access)
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: developer-dev-role
rules:
- apiGroups: ["", "apps", "batch"]
  resources: [pods, deployments, services, configmaps, jobs]
  verbs: ["*"]
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list"]  # Can view, not edit
- apiGroups: [""]
  resources: ["pods/log", "pods/exec"]
  verbs: ["get", "create"]  # For debugging
---
# Role for developers in production (limited access)
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: developer-prod-role
rules:
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch", "update", "patch"]  # No delete!
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]
# CANNOT view secrets or exec in production

Step 3: Create RoleBindings (Namespace-Specific)

# Team Alpha: Developers in dev environment
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: alpha-developers-dev
  namespace: alpha-dev
subjects:
- kind: Group
  name: alpha-developers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: developer-dev-role
  apiGroup: rbac.authorization.k8s.io
---
# Team Alpha: Developers in production (limited)
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: alpha-developers-prod
  namespace: alpha-prod
subjects:
- kind: Group
  name: alpha-developers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: developer-prod-role
  apiGroup: rbac.authorization.k8s.io

Step 4: Platform Team Cluster-Wide Access

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: platform-team-admin
subjects:
- kind: Group
  name: platform-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

Testing RBAC Permissions

# Test as a developer from Team Alpha
kubectl auth can-i get pods -n alpha-dev --as bob@company.com
# yes

kubectl auth can-i delete deployments -n alpha-prod --as bob@company.com
# no

kubectl auth can-i get pods -n beta-dev --as bob@company.com
# no (Cannot access Team Beta's namespace)

kubectl auth can-i get secrets -n alpha-prod --as bob@company.com
# no (Developers cannot view production secrets)

RBAC Best Practices

Use Groups instead of individual users
Define ClusterRoles (reusable), bind with RoleBindings (namespace-specific)
Principle of Least Privilege (start minimal, add as needed)
Separate dev and prod permissions
Never give direct Secret access in production
Enable audit logging for compliance
Regular access reviews (quarterly)

Shows real-world understanding & trade-offs

What Makes the Difference?

Context over facts: Explains when and why, not just what
Real examples: Provides specific use cases from production experience
Trade-offs: Acknowledges pros, cons, and decision factors

Practice Question

A developer is bound to a Role that allows get, list, watch on pods. Can they run kubectl exec -it my-pod -- /bin/sh?

Questions