Skip to main content

Overview

In this section, you will find details about access management in the StackSpot Account.

In a StackSpot account, multiple people can work on the platform with different goals. Because of this, you need different types of access and permissions. StackSpot uses a hybrid architecture that combines ABAC (Attribute-Based Access Control) and RBAC (Role-Based Access Control). The structure works as follows:

Role-Based Access Control (RBAC)

In StackSpot, roles categorize users or groups of users and define the permissions these users have in the account. For example, roles determine which data users can read or which account resources they can modify.

See the default StackSpot roles and permissions.

Attribute-Based Access Control (ABAC)

ABAC in StackSpot integrates Role-Based Access Control (RBAC) with resource-related groups. In this system, a resource within a group is considered an attribute. Roles determine the permissions, while resources serve as the attributes. When you add a user to a group, they automatically inherit the associated permissions.

Main Components

1. Permissions

  • Sets of actions defined for one or more resource types.
  • Based on three elements: Resource Type + Resource + Action.
  • Example: studio:create (type=studio, action=create).

2. Resource Types

  • Represent the entities/objects in the platform.
  • Examples: Studio, Workspace, Plugin, Stack, Application, etc.

3. Resources

  • Specific instances of resource types.
  • Examples: a specific Studio called "Novo-Studio", a specific Stack, etc.

4. Actions

  • Operations you can perform on resources.
  • Examples: create, update, delete, view, publish, deploy, etc.

5. Roles

  • Categorize users and define sets of permissions.
  • Default roles: account_holder, sys_admin, account_admin, workspace_admin, studio_admin, content_creator, developer, sre, partner_admin, partner_member, member.

6. Groups

  • Collections of users with the same roles and resources.
  • Make large-scale management easier.
  • Contain: members + roles + specific resources.

7. Resource Type Owners

  • Organize permissions by context/domain.
  • Categories: StackSpot Platform, Account, Studio, Workspace, Insights, Partner Account, Cloud, Cloud Foundation.

How it works

User → Group → Roles → Permissions → Actions on Specific Resources

Practical Example:

  • User: João Silva
  • Group: "Testing Studio Admins"
  • Roles in Group: studio_admin + content_creator
  • Group Resources: Studio "Testing-Studio"
  • Resulting Permissions: João can create, update, and delete content in the "Testing-Studio" Studio.

Key Concepts

ConceptDescriptionExample
Account MemberUsers who are part of your Account.-
GroupsCollections of users with the same roles and resources, meaning the same level of permission.A group with Studio Admin and Content Creator permissions, five members, and a Studio called Novo-Studio as a resource.
Resource TypeRepresents StackSpot entities where resources originate.StackSpot Platform, Account, Studio, Workspace.
ResourceObjects users interact with.Plugins, Links, Stacks, Starters, and others.
PermissionsGroups of actions defined for one or more resource types.Permission to activate an account and create a Stack.
ActionsOperations a user can perform on a resource."Publish a Plugin in a Studio." "Publish" is the action, "Plugin" is the resource, "Studio" is the resource type.
RolesIn StackSpot, roles categorize users or groups of users and define account permissions, such as which data they can read or which resources they can modify. When you assign permissions to a role, all users associated with that role receive those permissions.The main StackSpot roles are: account_holder, sys_admin, account_admin, workspace_admin, studio_admin, content_creator, developer, sre, partner_admin, and partner_member.

Next Steps