Kubernetes Namespaces & RBAC Explained

📖 Introduction

So far, we’ve been deploying everything into the default namespace. But in real-world clusters, especially in production, you’ll have multiple teams, environments, and applications sharing the same cluster.

👉 This is where Namespaces come in. They allow you to logically isolate and organize resources inside a Kubernetes cluster.

Think of Namespaces as folders in an operating system — they help keep things organized and prevent conflicts.

🌍 What is a Namespace?

A Namespace is a virtual cluster inside Kubernetes.
It lets you group resources (Pods, Services, Deployments, ConfigMaps, Secrets, etc.) together.
Each Namespace provides isolation of names → two Services with the same name can exist in different Namespaces without conflict.

📌 By default, Kubernetes comes with these namespaces:

default → where resources go if no namespace is specified.
kube-system → for system components (e.g., CoreDNS, kube-proxy).
kube-public → public, read-only resources (rarely used).
kube-node-lease → manages node heartbeats.

🔑 Why Use Namespaces?

Namespaces help in:

✅ Multi-tenancy → Different teams can share the same cluster without interfering.
✅ Environment separation → Example: dev, staging, prod.
✅ Resource isolation → Apply ResourceQuotas and LimitRanges per namespace.
✅ RBAC (Role-Based Access Control) → Assign permissions per namespace.
✅ Organization → Keep microservices grouped by project.

🛠 Creating a Namespace

1. Command Line

kubectl create namespace dev
kubectl get namespaces

2. YAML Manifest

apiVersion: v1
kind: Namespace
metadata:
  name: dev

Apply it:

kubectl apply -f namespace-dev.yaml

🚀 Deploying into a Namespace

Example: Deploying NGINX into the dev namespace.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: dev
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80

🔄 Switching Between Namespaces

List all namespaces:
```
  kubectl get namespaces
```
Check resources in a specific namespace:
```
  kubectl get pods -n dev
```

Switch default namespace using context:

  kubectl config set-context --current --namespace=dev

Now, every command will default to dev.

⚡ Cross-Namespace Communication

Services in different namespaces need fully qualified domain names (FQDNs).

Format:

  <service-name>.<namespace>.svc.cluster.local

Example:
```
  backend.dev.svc.cluster.local
```

So a frontend pod in frontend namespace can talk to backend service in dev namespace using this DNS.

🔐 What is RBAC?

RBAC in Kubernetes is a way to control access to resources:

Who → The subject (User, Group, or ServiceAccount).
Can do What → The action (verbs: get, list, create, delete, update).
On Which Resources → Pods, Services, Deployments, etc.
In Which Namespace → Example: dev, staging, prod.

👉 RBAC uses four main objects:

Role → Defines permissions within a namespace.
ClusterRole → Defines permissions cluster-wide.
RoleBinding → Assigns a Role to a user in a namespace.
ClusterRoleBinding → Assigns a ClusterRole to a user across all namespaces.

🛠 Example: Role & RoleBinding

1. Create a Namespace

kubectl create namespace dev

2. Define a Role

dev-role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: dev-role
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list", "create", "delete"]

👉 This allows the user to manage only pods & services in the dev namespace.

3. Bind the Role to a User

dev-rolebinding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-rolebinding
  namespace: dev
subjects:
- kind: User
  name: developer1          # Replace with your actual user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dev-role
  apiGroup: rbac.authorization.k8s.io

👉 Now, developer1 can only create/manage pods & services in dev namespace, but not in prod.

🛡 ClusterRole Example (Admin)

Sometimes, you want cluster-wide permissions.

cluster-admin-role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-admin-role
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

Bind it with ClusterRoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-binding
subjects:
- kind: User
  name: admin1
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin-role
  apiGroup: rbac.authorization.k8s.io

👉 admin1 will have full access across all namespaces.

🔑 Service Accounts + RBAC

Pods can use ServiceAccounts to access Kubernetes API securely.
Example: give a pod access to list secrets in dev.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: dev-sa
  namespace: dev
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: sa-role
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: sa-rolebinding
  namespace: dev
subjects:
- kind: ServiceAccount
  name: dev-sa
  namespace: dev
roleRef:
  kind: Role
  name: sa-role
  apiGroup: rbac.authorization.k8s.io

👉 Now, any pod using dev-sa can only list secrets in dev namespace, not modify or delete.

🔐 RBAC & Namespace Security

Namespaces integrate tightly with RBAC (Role-Based Access Control).

Example: Restrict a developer to only manage resources in the dev namespace.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: dev-role
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list", "create", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-rolebinding
  namespace: dev
subjects:
- kind: User
  name: developer1
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dev-role
  apiGroup: rbac.authorization.k8s.io

👉 Now developer1 can only work in dev namespace, not prod.

📊 Resource Quotas per Namespace

You can limit how much CPU/Memory a team uses:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-quota
  namespace: dev
spec:
  hard:
    requests.cpu: "2"
    requests.memory: 2Gi
    limits.cpu: "4"
    limits.memory: 4Gi
    pods: "10"

This ensures no single namespace can hog cluster resources.

📊 Best Practices

✅ Always use namespaces for isolation (dev, staging, prod).
✅ Assign RBAC per namespace to avoid privilege leaks.
✅ Use least privilege principle → give only what is needed.
✅ Use ServiceAccounts for apps, not root credentials.
✅ Combine with ResourceQuota to prevent resource hogging.

-🎯 Conclusion

Namespaces are essential for scaling Kubernetes in production. They provide isolation, organization, security, and resource control for multi-tenant clusters.

By using Namespaces correctly, you can:

Separate environments (dev, staging, prod).
Allocate resources fairly among teams.
Implement RBAC policies for security.

RBAC (Role-Based Access Control) → Control who can do what within a namespace.

Module 9: Kubernetes Namespaces, Multi-Tenancy & RBAC