Permissions

StackState Self-hosted v4.5.x

This page describes StackState v4.5.x. The StackState 4.5 version range is End of Life (EOL) and no longer supported. We encourage customers still running the 4.5 version range to upgrade to a more recent release.

Go to the documentation for the latest StackState release.

Overview

Permissions in StackState allow Administrators to manage the actions that each user or user group can perform inside StackState and the information that will be shown in their StackState UI. Only the feature set relevant to each user's active role will be presented. The actions, information and pages that a user does not have access to are simply not displayed in their StackState UI.

Permissions are stored in StackGraph. This means that:

  • If you perform an upgrade with "clear all data", permission setup will also be removed.

  • To completely remove a user, they must also be manually removed from StackGraph.

There are two types of permission in StackState:

Predefined roles

StackState comes with four predefined roles:

  • Administrators (stackstate-admin): Have access to all views and have all permissions, except for the platform management permission access-admin-api.

  • Platform Administrators (stackstate-platform-admin): Have platform management permissions and have access to all views.

  • Power Users (stackstate-power-user): This role is typically granted to users that need to configure StackState for their team(s), but will not manage the entire StackState installation. Power users have all Administrator permissions except for:

    • execute-restricted-scripts

    • update-permissions

    • upload-stackpacks

    • Guests (stackstate-guest): Have read access, as you can see below when we use the StackState CLI to show granted permissions for the role:

        $ sts permission show stackstate-guest
        subject           permission                 resource
        ----------------  -------------------------  ----------
        stackstate-guest  access-cli                 system
        stackstate-guest  access-explore             system
        stackstate-guest  perform-custom-query       system
        stackstate-guest  read-permissions           system
        stackstate-guest  update-visualization       system
        stackstate-guest  manage-star-view           system
        stackstate-guest  execute-component-actions  system
        stackstate-guest  access-view                everything

Default and custom role names

The default pre-defined role names (stackstate-admin, stackstate-platform-admin, stackstate-power-user, stackstate-guest) are always available. Additional custom role names can be added that have the same permissions. Below is an example of how to do this for both Kubernetes and Linux installations.

Include this YAML snippet in an authentication.yaml when customizing the authentication configuration to extend the default role names with these custom role names.

stackstate:
  authentication:
    roles:
      guest: ["custom-guest-role"]
      powerUser: ["custom-power-user-role"]
      admin: ["custom-admin-role"]
      platformAdmin: ["custom-platform-admin-role"]

To use it in for your StackState installation (or already running instance, note that it will restart the API):

helm upgrade \
  --install \
  --namespace stackstate \
  --values values.yaml \
  --values authentication.yaml \
stackstate \
stackstate/stackstate

All permissions in StackState

There are two types of permission in StackState:

System permissions

System permissions scope user capabilities, such as access to settings, query execution and scripting. They are set system wide.

See also the full list of view permissions.

View permissions

View permissions allow for CRUD operations on StackState Views. They can be set for a specific view or all views (everything).

See also the full list of system permissions.

Permissions by action

Page access

The permissions in the table below are required to access specific pages in the StackState UI. Without these permissions, the associated page will be hidden in the StackState UI and will not be accessible via its URL.

See the full list of permissions for pre-defined roles (above).

Topology

The permissions listed below are required to work with topology in StackState:

See the full list of permissions for pre-defined roles (above).

Component/relation details

The permissions listed below are required to carry out specific actions in the component or relation details pane.

See the full list of permissions for pre-defined roles (above).

View management

The permissions listed below can be set to access and work with views:

See the full list of permissions for pre-defined roles (above).

Analytics environment

The permissions listed below are required to access and execute scripts in the StackState UI analytics environment:

See the full list of permissions for pre-defined roles (above).

Settings page

The permissions listed below are required to access and manage settings in the StackState UI:

See the full list of permissions for pre-defined roles (above).

Platform Management

The permissions listed below are required to access and manage StackState platform:

See the full list of permissions for pre-defined roles (above).

Example CLI commands

Important note: All permissions in StackState are case sensitive.

List all permissions

List all permissions:

sts permission list

Show granted permissions

Show the permissions granted to a specific role.

sts permission show [role-name]

Grant permissions

Allow a user to open a view

Provide a subject with permission to open a view:

sts permission grant [subject-handle] access-view [view-name]

Allow a user to create (save) views

Provide a subject with the system permission to create (save) views:

sts permission grant [subject-handle] create-views system

Allow a user to check StackState settings

Provide a subject with the system permission to check StackState settings:

sts permission grant [subject-handle] read-settings system

Allow a user to add or edit event handlers

Provide a subject with the system permission to add new event handlers and edit existing event handlers:

sts permission grant [subject-handle] manage-event-handlers system

Revoke permissions

Revoke permissions for a subject to open a view:

sts permission revoke [subject-handle] access-view [view-name]

StackState UI with no permissions

Below is an example of how the StackState UI would look for a user without any permissions:

Last updated