DevSpace Permissions and Access Management

Devspaces management #

Kosmos UI does not allow you to create or delete Devspaces, but it does provide management capabilities for:

• Members DevSpace members are:
  • Users → Individual Kosmos users that can access the DevSpace.
  • DevSpace Teams → Groups of users that can access the DevSpace. These teams are scoped to the DevSpace. Therefore, a team defined in one DevSpace can never be granted access to any other DevSpaces.
  • Global Kosmos Teams → Kosmos-wide teams. Due to their global nature, you should generally not use these.
• Permissions Two ways to manage DevSpace permissions:
  • Users → Assign DevSpace roles to specific users.
  • DevSpace Teams → Assign DevSpace roles to DevSpace teams.
  • Global Kosmos Teams → Assign DevSpace roles to Kosmos-wide teams.

Devspace members management #

Add members #

1. Login to https://console.kosmos.spcplatform.com/dashboard .
2. Click Devspaces in the left navigation panel.
3. Choose your Devspace, you want to edit by clicking on three dots next to your devspace name.

   

4. Click Edit Devspace.

   

5. In the Edit Devspace module, go to Members → Default Devspace Role.
6. Choose the desired role and click Add Users.

   

7. Select the user from the list, then click Save to update settings.

   

Edit members #

1. Go to Devspaces in left navigation → select your Devspace.

2. Click the three dots (⋮) → Edit.

3. In Members, section you can:

   • Change the Default Devspace Role (dropdown).
   • Add users via Add User.

4. Save changes with Update Devspace.

Delete members #

1. Go to Devspaces in left navigation → select your Devspace.
2. Click the three dots (⋮) → Edit.
3. In Members, find the user to remove.
4. Click the Delete icon .
5. Save with Update Devspace.

Add, edit, or delete members using CLI #

1. Login via the CLI: kosmos login https://console.kosmos.spcplatform.com
2. Download the YAML representation of the DevSpace: kosmos get devspace -o yaml DEVSPACE-NAME > devspace.yaml
3. Open the devspace.yaml file. The spec.permissions section defines the permissions for users and DevSpace teams. In the following example, the users peter.pluck and john.johnson are granted admin permission within the DevSpace, while rob.robson is granted viewer permissions only.

  permissions:
    - fleetRole: devspace-admin
      users:
        - peter.pluck
        - john.johnson
    - fleetRole: devspace-viewer
      users:
        - rob.robson

4. Make any required changes, and update the DevSpace: kosmos update devspace -f devspace.yaml

Devspace dashboard #

Click on a Devspace name to access the Devspaces Info Dashboard, which includes:

• Virtual Clusters → List of all virtual clusters in your Devspaces.
• Teams → Logical groups of users assigned access to multiple virtual clusters.
• Devspace Roles → Role-Based Access Control (RBAC) roles.
  • devspace-admin → Full access (all resources, all verbs).
  • devspace-editor → Create namespaces, deploy workloads, but limited cluster management.
  • devspace-viewer → Read-only access.
  • devspace-secret-sync-admin → Full access to devspacesecrets and vault configurations.
  • devspace-secret-sync-editor → Create, update, list, get, delete of devspacesecrets.
  • devspace-secret-sync-viewer → Read-only access. Supports get, list, watch of devspacesecrets.
  • custom-devspace-role → Define your own permissions.
• Devspace secrets → The place where you maintain your setcrets needed for third party tool integration.
• Config → Packages are the configuation artifacts specified as Helm charts, git repositories, and OCl registries.

Virtual cluster management #

You can manage your virtual clusters through virtual clusters dashboard.

This virtual cluster dashboard provides you options to:

• View list of all the available virtual clusters
• Create virtual clusters
• Install app on your virtual clusters
• Edit virtual clusters
  • Show YAML
  • Show logs
  • Change template
  • Sleet
• Delete Virtual clusters

To learn more in details about creation, refer to Getting started with vClusters .

Team management in devspace using Managment console #

Devspace team organize users, groups, and resources for easier access management across Devspaces. Instead of assigning users directly to vClusters, assign them to a Devspace Team, and the team inherits the permissions.

Create a Team #

1. Go to Devspace dashboard → click on a Devspace.

   

2. Open the Teams tab.

   

3. Click Add Team.

   

4. Enter Team Name and Description.

   

5. Add members in the Team Members section.

   

6. Click Save.

   

Edit a Team #

1. Go to Devspaces in left navigation panel → select your Devspace.
2. Open the Teams tab in your Devspace dashboard.
3. Update details and click Save.

Delete a Team #

1. Go to Devspaces in left navigation panel → select your Devspace.
2. Open the Teams tab.
3. Select a Devspace Team (checkbox).
4. Click Delete → Confirm by entering Devspace name.

Note: If the deleted team still appears, refresh the page.

Team management in DevSpaces using CLI #

Adding a DevSpace team #

The kosmos create devspaceteam -f team.yaml command can be used to create a DevSpace team. An example team.yaml file is shown below.

apiVersion: storage.kosmos.spcplatform.com/v2alpha1
kind: DevSpaceTeam
metadata:
  name: sample-team
  namespace: loft-p-devspace-name
spec:
  description: This is a sample team for a DevSpace
  displayName: sample-team
  users:
    - peter.pluck
    - john.johnson
    - stanley.yelnats

Editing a DevSpace team #

The kosmos update devspaceteam -f team.yaml command works like the previous example to update an existing DevSpace team.

Deleting a DevSpace team #

A DevSpace team can be deleted using the following command: kosmos delete devspaceteam --devspace DEVSPACE-NAME --name TEAM-NAME

Role management in devspace using Management console #

A Devspace roles defines what actions users or teams can perform across clusters.

They work with:

• Devspace team: who can act.
• Devspace permissions: where they can act.
• Devspace roles: what they can do.

Predefined devspace roles #

• devspace-admin: Full access (all resources, all verbs).
• devspace-editor: Create namespaces, deploy workloads, but limited cluster management.
• devspace-viewer: Read-only access.
• devspace-secret-sync-admin: Full access to devspacesecrets and vault configurations.
• devspace-secret-sync-editor: Create, update, list, get, delete of devspacesecrets.
• devspace-secret-sync-viewer: Read-only access. Supports get, list, watch of devspacesecrets.
• Define your own permissions. You can also create your own custom role by selecting the specifics

Create a devspace roles #

1. Open Devspace and select your devspace.

2. Click the Devspace roles tab.

3. Click Add Devspace Role.

   

4. Enter Name and Description.

   

5. Add rules (resources + permissions).

6. Click Save.

Delete a Devspace role #

1. Open Devspace roles tab.
2. Select the Role you wish to delete. Click Delete.
3. Confirm by typing the Role name, then Click Delete.

Role management in DevSpaces using CLI #

DevSpace roles are similar to native Kubernetes roles , but are scoped to individual DevSpaces. These roles define access:

• The resources that can be accessed within the DevSpace.
• The actions that can be taken on those resources within the DevSpace. The spec.permissions section of the DevSpace YAML grant roles to users and teams.

Predefined DevSpace roles #

All DevSpaces are created with the following predefined DevSpace roles:

• devspace-admin: Full access (all resources, all verbs).
• devspace-editor: Create namespaces, deploy workloads, but limited cluster management.
• devspace-viewer: Read-only access.
• devspace-secret-sync-admin: Full access to DevSpace secrets and Vault configurations.
• devspace-secret-sync-editor: Create, update, list, get, delete of DevSpace secrets.
• devspace-secret-sync-viewer: Read-only access. Supports get, list, watch of DevSpace secrets. It is also possible to create custom DevSpace roles, as described in the following sections.

Create a DevSpace role #

The kosmos create devspacerole -f role.yaml command can be used to create a DevSpace role. An example role.yaml file is shown below.

apiVersion: storage.kosmos.spcplatform.com/v2alpha1
kind: DevSpaceRole
metadata:
  name: devspace-admin
  namespace: loft-p-devspace-name
spec:
  description: Admin role for DevSpace
  rules:
    - resources:
        - '*'
      verbs:
        - '*'

Delete a DevSpace role #

A DevSpace role can be deleted using the following command: kosmos delete devspacerole --devspace DEVSPACE-NAME --name ROLE-NAME

DevSpace secrets management #

DevSpaceSecret overview #

The DevSpaceSecret resource type is used to create a secret that is shared across all virtual clusters within a DevSpace. This resource type is built on Loft’s Project Secrets concept.

Using DevSpaceSecrets #

To use DevSpaceSecrets, follow the workflow below.

Step 1: Create a DevSpaceSecret #

Create a DevSpaceSecret resource in the DevSpace. The following example creates a DevSpaceSecret named devspacesecret-sample in the sample-devspace DevSpace.

apiVersion: storage.kosmos.spcplatform.com/v2alpha1
kind: DevSpaceSecret
metadata:
  name: devspacesecret-sample
  namespace: loft-p-sample-devspace
spec:
  displayName: Sample DevSpaceSecret
  description: Sample DevSpaceSecret Description
  data:
    key: dmFsdWU=

Step 2: Reference the DevSpaceSecret in a virtual cluster #

To propagate the contents of a DevSpaceSecret to a virtual cluster, create a standard Kubernetes Secret and add the loft.sh/project-secret-name label referencing the DevSpaceSecret name.

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  namespace: my-space
  labels:
    loft.sh/project-secret-name: devspacesecret-sample
type: Opaque

Synchronization behavior #

The contents of the DevSpaceSecret are periodically synchronized to all Kubernetes Secrets that reference it using the loft.sh/project-secret-name label.

Here is your content converted to Markdown (MD) with clean structure, consistent headings, and preserved YAML examples.

Syncing secrets from Vault to a DevSpace or Fleet #

Kosmos supports syncing secret data from a user-managed HashiCorp Vault instance into a DevSpace or Fleet.

Note: Kosmos does not provide a managed Vault solution. A user-managed Vault instance is required.

Prerequisites #

To configure Vault secret syncing, the following components are required:

• A user-managed Vault instance

• A VaultConfiguration resource created in the DevSpace or Fleet namespace

  • Defines how Kosmos connects to Vault
  • Controls the synchronization interval
  • Includes a flag to enable or disable syncing

• A DevSpaceSecret or FleetSecret resource

  • Reads secret data from Vault using the VaultConfiguration
  • Stores the retrieved data in Kosmos
  • Syncs the data to virtual clusters (DevSpace) or member clusters (Fleet)

Step 1: Create a VaultConfiguration #

Create a VaultConfiguration resource that points to your Vault instance. Replace the sample values with those appropriate for your environment.

apiVersion: storage.kosmos.spcplatform.com/v2alpha1
kind: VaultConfiguration
metadata:
  name: vaultconfiguration-sample
  namespace: devspace-or-fleet-namespace
spec:
  address: http://vault.vault.svc.cluster.local:8200
  auth:
    token: xxxxxxxxxxxx
  enabled: true
  syncInterval: 10s

Using with DevSpaces #

If you are targeting a DevSpace, create a DevSpaceSecret resource.

The vaultRef field must be configured correctly with the Vault mount path and secret path. If vaultRef is misconfigured, synchronization from Vault will not occur.

apiVersion: storage.kosmos.spcplatform.com/v2alpha1
kind: DevSpaceSecret
metadata:
  name: devspacesecret-sample
  namespace: loft-p-sample-devspace
spec:
  displayName: Sample DevSpaceSecret
  description: Sample DevSpaceSecret Description
  vaultRef:
    mountPath: "secret"
    secretPath: "webapp/config"

Once synchronization from Vault is working correctly, refer to the DevSpaceSecrets documentation for details on propagating secrets to virtual clusters.

Using with Fleets #

If you are targeting a Fleet, create a FleetSecret resource.

The vaultRef field must be configured correctly with the Vault mount path and secret path. If vaultRef is misconfigured, synchronization from Vault will not occur.

The FleetSecret spec includes additional fields that define where the secret will be written in the Fleet’s member clusters.

apiVersion: storage.kosmos.spcplatform.com/v2alpha1
kind: FleetSecret
metadata:
  name: fleetsecret-sample
  namespace: fleet-sample
spec:
  displayName: Sample FleetSecret
  description: Sample FleetSecret Description
  name: target-secret-name
  namespace: target-secret-namespace
  vaultRef:
    mountPath: "secret"
    secretPath: "webapp/config"

DevSpace secrets management using Management console #

Adding a secret #

1. In the dashboard, click on the DevSpace Secrets tab.
2. Click the Add DevSpace Secret button in the top-right corner.
3. Enter a name and description for your secret.
4. Add your secret as a key-value pair by clicking Add a secret.

Editing a secret #

1. Click the three dots next to the secret you want to edit.
2. Select Edit from the menu.
3. Update your secret values in the Edit Secret window.
4. Click Save to apply your changes.

Deleting a secret #

1. Click the three dots next to the secret you want to delete.
2. Select Delete from the menu.
3. Enter the secret’s name to confirm the deletion.
4. Click Delete to remove the secret.

DevSpace secrets management using CLI #

Adding a secret #

The kosmos create devspacesecret -f secret.yaml command can be used to create a DevSpace secret. An example secret.yaml file is shown below.

apiVersion: storage.kosmos.spcplatform.com/v2alpha1
kind: DevSpaceSecret
metadata:
  name: wallarm-token
  namespace: loft-p-devspace-name
spec:
  data:
    token: >-
      YUV1KytHQ0RSM0syNFN3clJOK0xWTC9jQUNDUDJZcHl4UFNhSVVsK0pDRnBNclJwSVhSSFFJVDVyOFI5eWpQSB==
  description: Secret containing a Wallarm token
  displayName: Wallarm Token

Editing a secret #

The kosmos update devspacesecret -f secret.yaml command works like the previous example to update an existing DevSpace secret.

Deleting a secret #

A DevSpace secret can be deleted using the following command: kosmos delete devspacesecret --devspace DEVSPACE-NAME --name SECRET-NAME

DevSpace config management #

Adding a package #

1. In the dashboard, click on the Config tab.
2. Click the Deploy Package button in the top-right corner.
3. Select the clusters where the package should be installed, then click Next.
4. Provide the following details:
   • Package name
   • Source and path
   • In Advanced settings, choose your authentication type
5. (Optional) Provide a destination, then click Next.
6. Review the details and click Save.

   

7. After successful installation, the package will appear in the Overview section of Config.

   

Editing a package #

1. In the dashboard, click on the Config tab.

2. Select the Packages option.

3. Click the three dots next to the package you want to edit and choose Edit.

4. The Edit Package window will appear on the right.

5. Make the required changes by following the three-step process.

6. Click Save to apply your changes.

   Note: You cannot change the name of an existing package.

Deleting a package #

1. In the dashboard, click on the Config tab.
2. Select the Packages option.
3. Click the three dots next to the package you want to delete and choose Delete.
4. Enter the package name to confirm deletion.
5. Click Delete to remove the package.

Editing DevSpaces permissions using YAML editor #

You can manage DevSpaces permissions directly through the YAML editor.

1. In the DevSpaces list, click the three dots menu on the right side of your desired DevSpace.
2. Select Show YAML.

   

3. The YAML editor window will open.
4. Make the necessary changes to update memberships or permissions.
5. Click the Update button to save your changes.

   

Supported DevSpace quotas #

DevSpaces support a defined set of resource quota limits that control resource usage within the DevSpace.

Currently supported quotas #

The following quota keys are currently supported:

• limits.cpu: 16
• limits.memory: 64Gi
• limits.ephemeral-storage: 200Gi
• requests.ephemeral-storage: 10Gi
• services.loadbalancers: 0
• services.nodeports: 0

Edit this page on GitHub