Skip to main content

Users, Groups and Roles

Account Types​

Users​

A user is an individual account in meshStack. Users can be assigned to workspaces and projects with specific roles, determining their level of access and responsibility. Admin users are managed under Admin Access.

API Users​

API Users are accounts that can access meshStack APIs across all workspaces. They are typically used to enable integrations that require access to resources spanning multiple workspaces.

API Keys​

API Keys can be issued either at the workspace or admin level. Workspace-scoped API Keys authorize requests to the meshObject API within the specific workspace, while admin-issued API Keys can also provide access across multiple workspaces. API Keys are now the recommended way to manage resources programmatically.

For more details, refer to the API keys documentation.

Choosing Between API Users and API Keys​

API User Deprecation

API keys are gradually replacing API users. Over time, more actions will be supported via API keys, and API user functionality will be fully deprecated.

API keys have the advantage of being short-lived tokens (the username/password is not sent with every request and therefore cannot be “stolen” as easily), and they allow more fine-grained permission handling.

API keys offer similar capabilities, with the added flexibility of workspace scoping. Application teams can issue and manage API keys to control access to their workspace resources. Historically, API users were used by admins or systems to manage resources across meshStack.

Groups​

A group is a collection of users, used to manage permissions collectively. Assigning a role to a group grants that role to every member at once, so you don't have to assign users individually. There are two ways a group can be made available beyond a single workspace, and it's important to keep them apart:

  • Global groups are available to every workspace, just like an individual user can be added to any workspace. Use these when a group genuinely belongs to all teams.
  • Admin groups are granted Admin Area roles on the organization (Admin Area) level. Use these to give a group central administrative access without exposing it to every workspace.

Global Groups​

A global group is selectable from every workspace and can be assigned to workspace and project roles anywhere through the UI, the same way a normal user can be added to any workspace. A real global group can only be created by syncing it from your identity provider via SCIM — it cannot be created through the meshStack API or the UI.

Use a global group only when the group really should be available everywhere. For a group that should only have central admin access — for example a customer's platform team — use an Admin Group instead, so it is not offered to every workspace.

Admin Groups​

An Admin Group grants a group access to the Admin Area with one of the Admin Area roles (e.g. Organization Admin), so you can control admin access for multiple users through a single group. An Admin Group is a workspace user group that belongs to your admin workspace.

The identifier of this admin workspace depends on your meshStack installation. You can look it up in the Admin Area under Access Control → Admin Access → Admin Groups: the info box there shows the workspace identifier you need for the meshObject API.

You can view Admin Groups within your Administration Area, but creating one is currently only possible via the meshStack API, in two steps:

  1. Create the group by importing a meshWorkspaceUserGroup with metadata.ownedByWorkspace set to your admin workspace identifier (see above for how to find it), using the Import meshObjects with JSON endpoint:

    {
      "apiVersion": "v1",
      "kind": "meshWorkspaceUserGroup",
      "metadata": {
        "name": "my-admin-group",
        "ownedByWorkspace": "your-admin-workspace-identifier"
      },
      "spec": {
        "displayName": "My Admin Group",
        "egid": "your-external-group-id",
        "members": ["existing-username"],
        "tags": {}
      }
    }

  2. Grant the group an Admin Area role by creating a workspace group binding that targets the same admin workspace with roleRef.name set to one of the roles listed below (e.g. Organization Admin).

Requires an API User

Both steps must be performed with an API User because of the permissions involved:

  • Step 1 requires Basic Authentication with an API User that has the "Import any supported meshObject" permission. API Keys cannot create workspace user groups, since there's currently no permission that grants them access to that endpoint.
  • Step 2 works with an API User that has the "Import any supported meshObject" permission (or an API Key with the "Admin: Create and update workspace role bindings in any workspace" permission).

Workspace User Groups​

A workspace user group is a special type of group that exists within a workspace. These groups are used for managing permissions at the workspace level, allowing for easier assignment of roles and access to multiple users at once.

Admin Area Users and Permissions​

Admin area users and groups have access to the meshStack admin area and can perform administrative tasks that affect the entire meshStack. Access to the admin area is typically restricted to the central platform team providing the Internal Developer Platform.

Assigning admin users can only be done by user who have "Organization Admins" rights.

Different groups of people may need access to the different administration area functionality. Therefore, the following administrative roles are currently available to users of the administration area:

  • Organization Admin: It's basically the account with administration rights. Has full access to all functionality and can manage users of the organization account.
  • Organization User: Has full access to all administration functionality, but cannot manage policies, tag definitions or users of the organization account.
  • Platform Engineer: An operator of a cloud platform, that is managed by the meshcloud platform. This role can perform tasks related to platform operations in the administration area.
  • Ops Support: Not all Ops operations must be executed by platform engineers. E.g. setting quotas is a task that can also be done by a separate Ops Support team.
  • FinOps Manager: A finOps manager has access to billing and usage information of workspace projects.
  • Onboarding Support: A support team in place to help users who want to sign up may also need access to some administration functionality which is granted by this role.
  • Compliance Manager: Has the rights to manage policies and tag definitions.
  • Replication Operator: A supportive role that can assist by viewing tenants' replication status. This role is helpful for meshcloud employees to debug any potential issues with tenant replication.
Organization AdminOrganization UserPlatform EngineerOps SupportFinOps ManagerOnboarding SupportCompliance ManagerReplication Operator
Workspace List✓✓✓✓✓✓✓✓
  Payment Methods List✓✓✓
  Manage Payment Methods✓✓✓
  Project List✓✓✓✓✓✓✓✓
    Manage Quota✓✓✓✓
    Edit project tags✓✓✓✓✓
  List Workspace Users✓✓
    Add yourself✓✓
    Pending role requests✓✓✓✓
Compliance✓✓✓
   List policies✓✓✓
   Manage policies✓✓
   List Tags✓✓✓
   Manage Tags✓✓
Project Management✓✓✓✓✓
  Delete Tenants✓✓✓✓✓
  Chargeback Statements✓✓✓
Platforms✓✓
  Platform Restrictions✓✓✓✓
  Landing Zones✓✓✓
  Usage Reports✓✓✓
  Tenants✓✓✓✓✓
  View Unmanaged Tenants✓✓✓✓
  Assign Unmanaged Tenants✓
User List✓✓
  Create User✓✓
  Delete User✓✓
  Download User Info✓✓
API Users✓
Service Broker✓✓
  Approve Service Broker✓✓
List Building Blocks & Definitions✓✓✓✓✓
   Manage Building Blocks & Definitions✓✓✓✓✓
   Delete Building Blocks & Definitions✓✓✓

User and Role Bindings​

User and role bindings define how users and groups are assigned specific roles within workspaces and projects. These bindings control access and permissions, ensuring that users have the appropriate level of responsibility for their tasks.

Bindings can be managed via the meshStack UI or API. When a user or group is bound to a role, they inherit the permissions associated with that role for the relevant workspace or project.

4 Eye Principle​

You can configure meshStack to require 4 eye principle for workspace and project permissions. This configuration enforces that at least two workspace owners or managers have to approve access before a user binding is created or modified.

Role Approvals (4 Eye Principle)​

You can configure meshStack to require approvals for workspace and project permissions. This configuration enforces that at least two workspace owners or managers have to approve access before a user binding is created or modified.

Workspace Users and Permissions​

Workspace users are assigned roles within a workspace, such as Workspace Owner, Workspace Manager, or Workspace User. These roles determine what actions a user can perform within the workspace.

Workspace Owner: Often the team lead or product owner and central point of contact for the team

Workspace Manager: Often the application architects or solution architects and back office personnel

Workspace Member: Often the developers and individual systems engineers

PermissionWorkspace OwnerWorkspace ManagerWorkspace Member
Manage all resources✔️✔️❌
Manage users✔️✔️❌
Assign/change roles✔️✔️ (limited)*❌
Assign/remove Owner role✔️❌❌
Invite new users✔️✔️❌
Delete workspace✔️❌❌
Use resources✔️✔️✔️
Change workspace settings✔️✔️❌

*Managers cannot assign or remove the Owner role.

Project Users and Roles​

Project users are assigned to specific projects within a workspace. If you are part of the project you can access the project in meshStack and add services from the marketplace. Project permissions also manage access to platform resources, as defined by their project role (e.g., Project Member, Project Admin). The project roles dont have any effect on permissions in meshStack.

Project roles can be customized in the global settings in the admin area.

Add platform and landing zone to configuration in the Platform Builder to enable role mappings.

Concepts​

Guides​