# 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
    requests.nvidia.com/gpu: "2"

Billing is based on requests, not limits

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

GPUs are also governed by quota. The requests.nvidia.com/gpu field caps the number of NVIDIA H100 GPUs that workloads in the namespace can request. For how to schedule GPU workloads and the available deployment models, see GPU Infrastructure.

# 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.

# Network Policy Defaults

OpenShift ships without a cluster-level default-deny NetworkPolicy. This means east-west traffic between pods and VMs — across namespaces — is allowed by default, including service ports such as databases (e.g. MariaDB on TCP 3306) and DNS.

Because there is no default deny, you are responsible for restricting access to any service that should not be reachable from outside your namespace by defining your own NetworkPolicy objects.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: my-project
spec:
  podSelector: {}
  policyTypes:
    - Ingress

Protect exposed services yourself

With no platform default-deny in place, unprotected services are reachable across namespaces. A platform-wide default-deny is planned, but because of the potential impact on existing tenants it will be rolled out gradually — do not rely on it today.

# 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 GB          RAM: 32 GB   RAM: 8 GB     │
│  Storage: 100 GB     Storage: 500 GB  Storage: 200 GB │
│                                                     │
│  Worker Node 1   Worker Node 2   Worker Node 3      │
└─────────────────────────────────────────────────────┘