Namespaces and RBAC — Kubernetes Basics | CertQnA

As clusters grow, you need ways to organise resources and control who has access to what. Kubernetes provides Namespaces for logical partitioning and RBAC for access control.

Namespaces

A Namespace provides a mechanism to isolate groups of resources within a single cluster. They are not a security boundary (a compromised Pod in one namespace can try to reach others), but they provide:

Separate resource quotas per team/environment
Scoping of names (a Service named api can exist in multiple namespaces)
Easier access control (grant permissions per namespace)

Built-in Namespaces

Namespace	Purpose
default	Resources with no namespace specified
kube-system	Kubernetes system components
kube-public	Publicly readable resources (cluster info)
kube-node-lease	Node heartbeat leases

kubectl get namespaces
kubectl create namespace staging
kubectl get pods -n staging
kubectl get pods --all-namespaces      # or -A
kubectl config set-context --current --namespace=staging  # set default

ResourceQuotas

A ResourceQuota limits the total resources consumed in a namespace:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: staging
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "20"
    services: "10"

LimitRange

A LimitRange sets default resource requests/limits for Pods that don't specify them:

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: staging
spec:
  limits:
    - type: Container
      default:
        memory: 256Mi
        cpu: 250m
      defaultRequest:
        memory: 128Mi
        cpu: 100m

RBAC — Role-Based Access Control

Kubernetes RBAC uses four objects to control who can do what:

Object	Scope	Purpose
Role	Namespace	Defines permissions within a namespace
ClusterRole	Cluster-wide	Defines permissions across all namespaces
RoleBinding	Namespace	Binds a Role (or ClusterRole) to a subject in a namespace
ClusterRoleBinding	Cluster-wide	Binds a ClusterRole to a subject cluster-wide

Example Role

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

Example RoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: production
subjects:
  - kind: User
    name: alice
    apiGroup: rbac.authorization.k8s.io
  - kind: ServiceAccount
    name: monitoring-sa
    namespace: production
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

ServiceAccounts

A ServiceAccount is an identity for processes running in a Pod (not a human user). By default, each namespace has a default ServiceAccount. Assign a custom ServiceAccount with limited permissions to each application:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: production
---
spec:
  serviceAccountName: my-app-sa   # in the Pod spec

Following the principle of least privilege, each application should have its own ServiceAccount with only the permissions it needs.

Next: Helm — the package manager for Kubernetes that simplifies deployment of complex applications.