# Spaces and Members > Cordium documentation. Canonical page: . A *Space* is the top-level organizational unit of Cordium. It groups *Templates*, *Workspaces*, *Secrets*, *GitProviders*, *Volumes* and *Memberships*, and it can define runtime configuration and resource limits that apply to all of its *Workspaces*. There are two types of *Spaces*: - **`USER`** *Spaces* are personal to a single *User*. Their full name is `.` (e.g. `research.alice`). Every *User* automatically gets a `default` *Space* (e.g. `default.alice`) when they create their first *Workspace* without specifying a *Space*. - **`ORGANIZATION`** *Spaces* are shared among several *Members* with different roles. Their full name is `.cordium` (e.g. `payments.cordium`). ## Creating Spaces The type of a *Space* is determined by its full name: ```bash # A USER Space cordium create space research # An ORGANIZATION Space cordium create space payments.cordium ``` Creating *Spaces* (other than the automatically created `default` *Space*) requires the *User* to be allowed to own *Spaces* by the ownership rules of the `ClusterConfig`. By default, no *User* is allowed to own *Spaces* until a *Cluster* administrator defines these rules (read more [here](https://octelium.com/docs/cordium/latest/management/clusterconfig.md#space-ownership)). The creator of a *Space* automatically becomes its `OWNER`, and every *Space* is created with an empty `default` *Template*, which is used by the *Workspaces* that are created in the *Space* without a specific *Template*. You can list your *Spaces* as follows: ```bash cordium get space ``` ## Members and Roles The *Members* of an `ORGANIZATION` *Space* are managed from the web portal or via the `CreateMembership`, `UpdateMembership` and `DeleteMembership` APIs, by inviting existing Octelium *Users* by email or by their *User* name. Every *Membership* has one of the following roles: | Action | `USER` | `ADMIN` | `OWNER` | | ------------------------------------------------------------------------------------- | :----: | :-----: | :-----: | | Create, use and manage their own *Workspaces* and *WorkspaceSnapshots* in the *Space* | ✓ | ✓ | ✓ | | Use the *Space*'s *Templates*, *Volumes* and *GitProviders* in their *Workspaces* | ✓ | ✓ | ✓ | | Create, update and delete *Templates* and trigger pre-builds | | ✓ | ✓ | | Create, update and delete *Secrets*, *GitProviders* and *Volumes* | | ✓ | ✓ | | Add, update and remove `USER` and `ADMIN` *Members* | | ✓ | ✓ | | Grant and revoke the `OWNER` role | | | ✓ | | Update and delete the *Space* | | | ✓ | > **Note:** > > *Workspaces* are always private to their owners, even inside `ORGANIZATION` *Spaces*. Other *Members*, including the *Space* admins, cannot open terminals, SSH into, or access the applications of a *Workspace* that they do not own, unless its owner explicitly shares an application with them (read more [here](https://octelium.com/docs/cordium/latest/workspaces/applications.md#sharing-applications)). Likewise, *Secret* values are never exposed to the *Members* via the API; they can only be used by the *Workspaces* of the *Space*. `USER` *Spaces* cannot have *Members* other than their owner. ## Space Configuration A *Space* can define configuration that cascades down to all of its *Workspaces*, regardless of their *Template*. This is how platform teams enforce organization-wide settings such as proxy settings, compliance tasks or Linux capabilities. Here is an example: ```yaml spec: runtime: envVars: - key: HTTP_PROXY value: http://proxy.internal:3128 - key: SENTRY_DSN fromSecret: sentry-dsn.payments.cordium tasks: - name: install-ca type: ON_CREATE runAsRoot: true run: | curl -fsSL https://pki.example.com/root-ca.crt -o /usr/local/share/ca-certificates/acme.crt update-ca-certificates capabilities: drop: - NET_RAW limit: defaultLimit: cpu: millicores: 2000 memory: megabytes: 4096 maxLimit: cpu: millicores: 8000 memory: megabytes: 32768 storage: megabytes: 100000 authorization: disableSSH: true ``` | Field | Description | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `runtime.envVars` | Environment variables injected into every *Workspace* of the *Space*. *Secret*-sourced variables are only supported in `ORGANIZATION` *Spaces*. They have a lower precedence than the variables of the *Templates* and *Workspaces*. | | `runtime.tasks` | Lifecycle tasks that run in every *Workspace* of the *Space*, after the tasks of the *Template*, the *Workspace* and the *UserConfig*. | | `runtime.capabilities` | Linux capabilities that are merged into every *Workspace* of the *Space*. | | `limit.defaultLimit` | The limits of the *Workspaces* that do not define their own (read more [here](https://octelium.com/docs/cordium/latest/workspaces/resources.md#resolution)). Only for `ORGANIZATION` *Spaces*. | | `limit.maxLimit` | A hard cap that no *Workspace* of the *Space* can exceed. | | `authorization.disableSSH` | Denies SSH access to all the *Workspaces* of the *Space* (see below). | ### Disabling SSH Setting `authorization.disableSSH` to `true` denies all SSH connections to the *Workspaces* of the *Space*, including the connections of their owners. This affects `cordium ssh`, `cordium cp` (which transfers files over SSH) and IDEs connecting via SSH (read more [here](https://octelium.com/docs/cordium/latest/use/ssh.md)). Terminals, `cordium exec` and the other APIs keep working normally. This is useful for *Spaces* dedicated to unattended automation and AI agents, where interactive shell access is unnecessary. ## Deleting Spaces ```bash cordium delete space research ``` Deleting a *Space* deletes all of its *Workspaces* and *Templates* as well. This cannot be undone.