Kubernetes Namespaces and RBAC — Multi-Tenant Clusters

DodaTech 3 min read

In this tutorial, you'll learn about Kubernetes Namespaces and RBAC. We cover key concepts, practical examples, and best practices to help you understand and apply this topic effectively.

What You'll Learn

Organize Kubernetes clusters with namespaces and control access with RBAC — isolate environments, set resource quotas, and manage multi-team clusters.

Why It Matters

A flat Kubernetes cluster is chaos. Namespaces provide isolation boundaries, and RBAC ensures only authorized users can access resources.

Real-World Use

Dev, staging, and prod in one cluster with resource guarantees, giving each team their own namespace, or restricting developers from production.

What is a Namespace?

A namespace is a virtual cluster within a physical cluster — a scope for names and resources.

Cluster
├── Namespace: production
│   ├── Pod: web-app (name unique within production)
│   └── Service: web-app
├── Namespace: staging
│   ├── Pod: web-app (same name, different namespace)
│   └── Service: web-app
└── Namespace: development
    ├── Pod: web-app
    └── Service: web-app

Working with Namespaces

# List namespaces
kubectl get namespaces

# Get resources in a namespace
kubectl get pods -n production
kubectl get all -n staging

# Create a namespace
kubectl create namespace team-alpha

# Set context to always use a namespace
kubectl config set-context --current --namespace=team-alpha

Resource Quotas

Reserve and limit resources per namespace:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    persistentvolumeclaims: "5"
    pods: "20"
    services: "10"
---
apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: team-alpha
spec:
  limits:
    - default:
        cpu: 500m
        memory: 256Mi
      defaultRequest:
        cpu: 100m
        memory: 64Mi
      type: Container

RBAC Deep Dive

RBAC controls who can do what in which namespace.

Roles and ClusterRoles

# Role (namespace-scoped)
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: team-alpha
  name: pod-manager
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch", "create", "update", "delete"]
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get", "list"]
---
# ClusterRole (cluster-wide)
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-viewer
rules:
  - apiGroups: [""]
    resources: ["nodes", "namespaces", "persistentvolumes"]
    verbs: ["get", "list", "watch"]

RoleBindings and ClusterRoleBindings

# Bind a user to a Role in a namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: team-alpha
  name: alice-pod-manager
subjects:
  - kind: User
    name: alice@company.com
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-manager
  apiGroup: rbac.authorization.k8s.io
---
# Bind all authenticated users to a ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: all-users-view
subjects:
  - kind: Group
    name: system:authenticated
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-viewer
  apiGroup: rbac.authorization.k8s.io

ServiceAccounts

Pods use ServiceAccounts to authenticate to the API:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: team-alpha
---
# Assign to a pod
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  serviceAccountName: my-app-sa
  containers:
    - name: app
      image: my-app

Multi-Tenant Pattern

# One namespace per team or application
Namespaces:
├── team-alpha: Development team
│   ├── ResourceQuota: 4 CPU, 8GB memory
│   ├── Role: developer (full access to pods, services)
│   └── ServiceAccounts: team-alpha-sa
├── team-beta: Data team
│   ├── ResourceQuota: 8 CPU, 32GB memory
│   ├── Role: data-scientist (access to jobs, pods)
│   └── ServiceAccounts: team-beta-sa
└── production: Production workloads
    ├── ResourceQuota: 32 CPU, 128GB memory
    ├── Role: sre (admin, but no delete)
    └── ServiceAccount: production-sa

Useful Commands

# Check who you are
kubectl auth whoami

# Check if you can do something
kubectl auth can-i create pods
kubectl auth can-i delete pods --namespace production

# Check what a user can do
kubectl auth can-i --list --as alice@company.com

# View RBAC bindings
kubectl get rolebindings --all-namespaces
kubectl get clusterrolebindings

# Debug permissions
kubectl describe rolebinding alice-pod-manager -n team-alpha

← Previous Docker and Kubernetes Security Best Practices Next → CI/CD with Docker and Kubernetes — Complete Pipeline

Built by the developers of DodaTech

Doda Browser, DodaZIP & Durga Antivirus Pro

Home Browse Docker Kubernetes