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

```yaml
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"
```

!!!info 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](./gpu-infrastructure.md).

---

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

```yaml
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.

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

!!!warning 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      │
└─────────────────────────────────────────────────────┘
```

---

## Related Pages

- [OpenShift Architecture Overview](./openshift-architecture-overview.md)
- [IaaS Capacity and Node Provisioning](./iaas-capacity-and-node-provisioning.md)
- [GPU Infrastructure](./gpu-infrastructure.md)
- [Resource Pricing](../resource-pricing.md)