# Namespaces

> Source: https://parallelworks.com/docs/kubernetes/namespaces

# Namespaces

The Namespaces view lets organization admins create Kubernetes namespaces on connected clusters, associate them with budget allocations, and control which groups can access each namespace and at what permission level.

:::info Admin Only
The Namespaces view is available to organization admins and platform admins only.
:::

## Viewing Namespaces

Navigate to **Kubernetes > Namespaces** in the sidebar to see the namespaces across your connected clusters.

| Column | Description |
|--------|-------------|
| **Name** | The namespace name. |
| **Cluster** | The cluster the namespace belongs to. |
| **Shared With** | The groups that have been granted access, along with their assigned role. |
| **Allocation** | The budget allocation associated with the namespace, if any. |
| **Status** | The namespace phase: `Active` or `Terminating`. |

Use the cluster filter and name search at the top of the page to narrow the view.

## Creating a Namespace

1. Navigate to **Kubernetes > Namespaces** and click the add action.
2. Fill in the form:
   - **Cluster** — The cluster to create the namespace on.
   - **Name** — The namespace name (lowercase letters, numbers, and hyphens).
   - **Allocation** (optional) — Associate the namespace with a budget allocation so that usage within the namespace is attributed to it.
3. Save to create the namespace on the cluster.

## Granting Groups Access

Each namespace can be shared with one or more groups by creating **role bindings**. A role binding grants every member of a group a Kubernetes role within the namespace:

| Role | Permissions |
|------|-------------|
| **admin** | Full control over most resources in the namespace, including the ability to manage roles and role bindings within it |
| **edit** | Read and write access to most resources in the namespace, but no ability to manage access |
| **view** | Read-only access to most resources in the namespace |

These map to the corresponding [Kubernetes built-in ClusterRoles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles). The platform creates and manages the RoleBinding objects on the cluster for you.

Role bindings can be edited (to change a group's role) or deleted (to revoke a group's access) at any time. Because [OIDC tokens](/docs/kubernetes/connecting-clusters#security-model) are short-lived, access changes take effect within minutes.

:::info Cluster Sharing
For group members to see the cluster in the first place, the cluster itself must also be shared with their group. See [Granting Users Access](/docs/kubernetes/connecting-clusters#granting-users-access).
:::

## Deleting a Namespace

Select the delete action on a namespace and confirm. The namespace and **everything in it** — workloads, services, persistent volume claims, ConfigMaps, and Secrets — is removed from the cluster. The namespace shows a `Terminating` status while Kubernetes finishes cleaning up its resources.

:::warning Irreversible Action
Deleting a namespace permanently deletes all resources it contains. This action cannot be undone.
:::

## See Also

- [Connecting Clusters](/docs/kubernetes/connecting-clusters) — Register clusters and understand the access model
- [Resource Quotas](/docs/kubernetes/resource-quotas) — Set CPU, memory, and GPU limits per namespace
- [kubectl Access](/docs/kubernetes/kubectl-access) — How group memberships map to namespace access from the CLI