Skip to content
Portal

Service Accounts

Service accounts let the platform perform actions on behalf of a user in an automated, auditable way. Internally, a service account is represented as a pair of IAM organizations (technical and user) that are added as members to one or more role organizations. The platform then obtains a JWT (refreshable/revocable by default) for the service account to call APIs with the exact permissions granted by the attached roles.

How it works

  • A service account is an organization, member of the role organizations you select.
  • When you request a JWT for a service account, the system:
  • Generates a per‑use API key for the service account technical organization.
  • Requests a JWT with scopes derived from the attached roles.
  • Returns a JWT (refreshable/revocable by default) you can use in automations and integrations.
  • No interactive login is needed and the permissions are fully controlled by roles.

Prerequisites

  1. Create one or more roles with the permissions you want the service account to have.
  2. Make sure the roles have access to the right resources (cloudspaces, vms, etc.).

Create a Service Account

  1. Go to Admin > Service Accounts.
  2. Click Add Service Account.
  3. Enter a name.
  4. Select one or more roles. The service account organizations will be added as members of these role organizations.
  5. Click Add Service Account.

Authorization Required

If your account does not yet have the IAM owner scope, the portal first shows an Authorization Required dialog ("The user:ownerof:organization scope for organization ... is needed to continue the operation!") with AUTHORIZE and CLOSE buttons. Click AUTHORIZE to continue. The creation then runs as a task, shown in the footer task list as "Create Service Account (name)".

The service account will appear in the list, which shows its name, roles and creation date.

Note: the superadmin_1 role is not available for selection when assigning roles to a service account.

Obtain a JWT

  1. In Service Accounts, click the copy icon in the Actions column.
  2. The platform will generate and copy a JWT (refreshable/revocable by default) to your clipboard.
  3. Use this JWT in API calls that require the service account’s permissions.

When creating VDI profiles, use two roles per customer for clarity and security:

  • Read‑only role (for end users)

  • Permissions: read‑only only; no access beyond viewing the VDI landing page and their own sessions.

  • Purpose: regular users use this role to access the VDI landing page.

  • Service account role (for automation)

  • Permissions: full permissions and access within the target cloudspace where VDI will be created.
  • Purpose: used by the service account that provisions and manages the VDI profile and sessions.

Steps:

  1. Create the two roles above with proper permissions and organizational access.
  2. Create a service account and attach the “service account role”.
  3. In the VDI creation screen, select that service account when prompted.

Security Notes

  • Treat service accounts like regular privileged identities.
  • Limit attached roles to the principle of least privilege.
  • Remove a service account’s roles or delete the service account when it is no longer needed.
  • A service account that is still attached to a resource (for example a VDI profile) cannot be deleted until it is detached from all resources.

Containerspaces

Containerspaces run their components under a service account. When you create a management cluster you select the service account in the creation wizard, and you can change it later on the cluster's details page — the platform then automatically rotates the new credential to all cluster VMs, Kubernetes clusters, and Rancher agents. The service account needs full access on the location of the cluster's cloudspace.