Identity and Access Management

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

How STACKIT IAM works 

Permisisons  

Permissions are required to access resources. They control what users can do within your organization. For every API method a STACKIT service exposes, there is typically a corresponding permission. To use a method, you need to have the necessary permission. 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 a role to a user, you grant them all the permissions that the role contains. 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. Permissions are required to access resources. 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 the contains roles with fixed names and permissions that cannot be altered.

• Primitive Roles: Roles historically available in STACKIT. These roles are {organization, project}.{owner, admin, member, auditor} DEPRECATED
• Basic Roles: Owner, Editor, Viewer UPCOMING
• Resource-specific Roles: Roles that grant fine-grained access control. They are more specific than the basic roles UPCOMING

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.
• Viewer: 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 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.

Examples

Role Bindings with basic roles

Basic roles on organization level pass on permissions to sub-entities within the scope.

User Alice has owner access to the organization test. Organization test has three projects. Since Alice is given the owner role at the organization level, she automatically gets owner access to all the subsidiary projects within the organization. This means Alice can fully manage all resources across all projects within the organization.

Role Bindings with primitive roles

Primitive roles only provide access within the scope they are assigned to and don’t pass on permissions to sub-entities within that scope.

User Bob has organization.member access to the organization test and project.member access to project Backend. Organization test has three projects. The role binding on project level grants Bob access to manage resource within the project Backend. Since organization.member is a primitive role no additional permissions are passed down to the other two remaining projects.

Role Migration Guide

We’ve decided to combine the {organization, project}.owner and {organization, project}.admin roles due to their overlapping responsibilities. This unified role will be the first Basic Role that can be assigned at any scope. For now, we won’t make any changes to the organization.member or organization.auditor roles. However, we will rename the project.member and project.auditor roles. This is a necessary step towards making these roles assignable at all levels offered by the resource manager. The new Owner role is the first role in the hierarchy that can pass permissions down to sub-entities within its scope. If you assign the Owner role at the organization level, it will provide owner access to all projects within that organization.