STACKIT IAM is a central authorization system built ontop of the resource manager to provide fine-grained access management to your STACKIT resources. 

How STACKIT IAM works 

Permissions  

Permissions are required to access resources. They control what users can do within your organization. Whenever you interact with the STACKIT Portal, the API, or infrastructure tools, there is a specific permission associated with it. You need this permission to carry out an action.

These permissions aren’t directly assigned to the end users. Instead, roles are used as a medium to provide users with the necessary permissions. In other words, to grant users access to certain resources, you need to assign them specific roles that carry the required permissions.

Each permission has the following components:

  • Name: The permission name, a human-readable identifier, is used for permission recognition in the STACKIT Portal.
  • Description: a human-readable description. Describing the permissions purpose.

Roles

A role is a collection of permissions. Roles can be high level like Owner or specific like object-storage-reader. When you grant one role or multiple roles to a user, you grant them all the permissions that the roles contain.

Each role has the following components:

  • Name: The role name, a human-readable identifier, is used for role recognition in the STACKIT Portal.
  • Description: A human-readable description.
  • Permissions: A list of permission included in the role. Generally, there’s a one-to-one relationship between each permission and an API method.

Role types

STACKIT provides three predefined role types. Each of them contains roles with fixed names and permissions that cannot be altered.

  • Primitive Roles: Roles historically available in STACKIT. These roles are organization.member and organization.auditor DEPRECATED
  • Basic Roles: Owner, Editor, Reader
  • Resource-specific Roles: Roles that grant fine-grained access control. They are more specific than the basic roles

Basic Roles

Basic roles in STACKIT provide users with extensive access to resources, containing thousands of permissions across all services. However, in production environments, these roles should only be granted when there are no other options.

  • Owner: Grants full access to manage all resources, including the ability to assign roles in STACKIT.
  • Editor: Grants full access to create and delete resources for most STACKIT services. Does not allow you to assign roles in STACKIT IAM.
  • Reader: Grants you read-only access to all resources.  Does not allow you to modify the state or existing resources or to assign roles in STACKIT IAM.

Resource-specific Roles

Starting with a few pilot products, resource-specific roles will be applicable to specific types of resources within a given scope. For example, you can create a role binding on project level that grants specific permissions on object storage buckets within a particular project. Resource specific roles are primarily intended to be used for Service Accounts as they will make large parts of the Portal unusable if a human user is only assigned to resource specific roles.    

Scope 

A scope refers to the range of resources that can be accessed. You can define a scope at different levels, currently available are the organization, folder and project levels. Think of scopes as a family tree, where each level down is a more specific subset of the parent. You have the flexibility to assign roles at any level in this hierarchy. The level you choose will determine how broad or narrow the role’s reach is.

Role binding

In STACKIT IAM, access is granted through the creation of role bindings, following an additive model. This means that to provide access, you create role bindings, and to limit access, you remove them. It’s important to note that you can’t limit access by adding new role bindings.

A role binding consists of:

  • The user / service account. Who is assigned to a role.
  • The role which is assigned.
  • The scope at which level the role is assigned.



Inherited Role Bindings

Inherited role bindings are a mechanism for automatically granting permissions to sub-entities within a defined scope. This means that roles and their associated permissions, defined at a higher level (e.g., a folder), are automatically applied to entities within that scope (e.g., projects within the folder).

Visibility and Identification:

  • Inherited role bindings are visible in the Access Section of the Portal and are clearly marked as "inherited."
  • This distinction helps users understand the origin and scope of the role binding.

Modification and Removal:

  • Inherited role bindings can only be removed at the scope level where they are applied. This means that if a project inherits an Owner role binding from its parent folder, the role binding must be removed at the folder level.
  • Direct modification of inherited role bindings at the sub-entity level is not possible. This ensures consistency and prevents unintended changes to the inherited permissions.


Primitive roles like "organization.member" and "organization.auditor" are organization-level only. They grant access at the organization level but do not inherit to child resources (folders or projects). These roles are required for granting access to the organization, which is a prerequisite for creating role bindings at lower levels (i.e folders / projects).

Example

Alice has been granted the Owner role for the Test organization. This organization contains three projects. Due to the hierarchical nature of role inheritance, Alice's Owner role at the organizational level automatically grants her the Owner role on all three projects within Test. Consequently, Alice possesses full administrative privileges over all resources within all projects belonging to the Test organization.