# Namespaces, Quotas and RBAC

Namespaces, referred to as Projects in OpenShift, are the primary mechanism for multi-tenancy, resource isolation, and cost allocation within a shared cluster. Each namespace represents a governed partition of the cluster assigned to a specific team, application, or environment.

# What a Namespace Provides

Capability	Mechanism
Resource isolation	`ResourceQuota` caps total CPU, memory, and storage per namespace
Per-workload limits	`LimitRange` sets defaults and maximums per pod and container
Access control	RBAC policies restrict which users and service accounts can deploy
Cost accountability	Resource usage per namespace maps directly to a monthly CHF cost

# ResourceQuota

A ResourceQuota object is assigned to a namespace by a platform administrator. It defines the maximum resources that all workloads in that namespace can collectively consume.

The two key fields for each resource type are:

requests — the guaranteed minimum allocation, used as the basis for billing
limits — the maximum the namespace is permitted to consume (burst ceiling)

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: my-project
spec:
  hard:
    requests.cpu: "4"
    limits.cpu: "8"
    requests.memory: 16Gi
    limits.memory: 32Gi
    requests.storage: 100Gi

Billing is based on requests, not limits

Chargeback is calculated against requests values, not limits. This ensures predictable costs regardless of actual burst usage.

# LimitRange

A LimitRange operates at the individual pod and container level within a Namespace. It sets sensible defaults so that workloads without explicit resource definitions still consume a bounded amount of cluster capacity.

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

# Role-Based Access Control (RBAC)

RBAC in OpenShift controls which users and service accounts can perform actions within a Namespace. Common roles include:

Role	Permissions
`admin`	Full control over all resources in the namespace
`edit`	Create, update, and delete workloads; no RBAC management
`view`	Read-only access to all resources

Roles are bound to users or groups via RoleBinding objects scoped to the namespace, ensuring that access is strictly contained within tenant boundaries.

# Namespace Isolation Example

The diagram below illustrates three namespaces sharing a common cluster node pool while maintaining independent resource and access boundaries.

Kubernetes Cluster
┌─────────────────────────────────────────────────────┐
│                                                     │
│  Namespace A          Namespace B    Namespace C    │
│  CPU: 4 cores         CPU: 8 cores  CPU: 2 cores   │
│  RAM: 16 GiB          RAM: 32 GiB   RAM: 8 GiB     │
│  Storage: 100 GiB     Storage: 500 GiB  Storage: 200 GiB │
│                                                     │
│  Worker Node 1   Worker Node 2   Worker Node 3      │
└─────────────────────────────────────────────────────┘