Spaces and Members

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 <SPACE>.<USER> (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 <SPACE>.cordium (e.g. payments.cordium).

Creating Spaces

The type of a Space is determined by its full name:

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

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). 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:

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

cordium delete space research

Deleting a Space deletes all of its Workspaces and Templates as well. This cannot be undone.