Understand roles and permissions

Role Based Access Control (RBAC)

STACKIT uses Role Based Access Control (RBAC) to allow or deny access to different endpoints. In RBAC, a policy assigns a role to a subject for a specific resource.

A subject is a verified identity that can have the following forms:

• User: Identifies a real person whose data is stored in the Identity Provider. They can log in using a username and password or via federated login methods.
• Service account: Identifies a machine, a script, or something that is not a real person. Service accounts are useful to set up automation that requires minimal or no user interaction.
• Client: Clients identify a machine or something that is not a real person and has administrative privileges. Clients cannot be used by end users.

No subject has access to any resource by default. The access is granted via roles.

Permissions

Permissions define the specific actions users can perform in your STACKIT environment. They are the lowest level in the RBAC model used by STACKIT. Every operation in your organization, whether executed through the STACKIT Portal, API, or infrastructure tools, requires a specific permission. There is generally a one-to-one relationship between each permission and an API method.

Each permission has two components:

• Name: A human-readable identifier used for recognition in the STACKIT Portal.
• Description: A human-readable description of the permission’s purpose.

Roles

A role is a collection of permissions. Roles can be broad, like Owner, or specific, like postgres-flex.reader. You can think of roles as logically cohesive sets of permissions. When you grant a user one or more roles, you give them all the permissions those roles contain.

Each role has the following components:

• Name: A human-readable identifier used for recognition in the STACKIT Portal.
• Description: A human-readable description.
• Permissions: A list of permissions included in the role.

General roles

General roles, such as Owner, Editor, and Reader, provide broad access across all STACKIT services and contain extensive permission sets. Use these roles with caution in production environments, and limit their scope to specific folders or projects rather than applying them at the organization level.

• Owner: Grants full access to manage all resources, including the ability to assign roles.

• Editor: Grants full access to create and delete resources for most STACKIT services, but does not allow role assignment.

• Reader: Grants read-only access to all resources. This role does not allow you to modify resources or assign roles.

Product-specific roles

Product-specific roles enable you to grant limited access to specific STACKIT products. You can assign these roles at different scope levels for broad or fine-grained access control. The naming for these roles has a fixed format: product-name.noun, like postgres-flex.admin or postgres-flex.reader.

Product-specific roles are mostly to be used for service accounts. If you assign only these roles to a person, parts of the Portal might become inaccessible for them.

Scope

A scope refers to the range of resources that can be accessed. You can define a scope at different levels: organization, folder, and project. The level you choose determines how far-reaching the role’s permissions are. Scopes follow a hierarchical structure, where each level is a more specific subset of the parent.

Role binding

Role bindings, also referred to as memberships, are the core mechanism for access control. They link a subject (a user, service account, or group) to a specific role within a defined scope. This is the sole method used to manage access across your organization, folders, and projects.

A role binding consists of the following:

• Subject: The identity that gets the access. This can be a user’s email, a service account email, or a group ID.
• Role: A collection of permissions.
• Scope: The resource hierarchy level where the access is granted. Currently, role bindings are only available on Resource Manager entities like your organization, folder, or project. Role bindings on individual cloud resource levels (like a specific bucket or VM) aren’t supported.

The access model for Role bindings is strictly additive. Access is granted only through the creation of a new role binding and cannot be revoked by subsequent bindings. To reduce a subject’s effective permissions, the existing, overly permissive role binding(s) must be explicitly removed.

Inherited role bindings

If the effective permissions are granted through inheritance — that is, via a role binding established on a parent node in the resource hierarchy (organization or folder)—the binding must be removed at the parent level. Access cannot be restricted or denied by adding a binding on a child node (project or folder).

IAM Membership roles and permissions matrix

Lowest Scope	Name	Description	Permissions
Project	IAM Member Admin	This role allows managing access to the specific resource. This includes listing, adding, and removing members and role bindings.	iam.member.add iam.member.get iam.member.remove iam.role.get iam.role.list
Project	IAM Member Reader	This role allows listing the members and role bindings of a resource.	iam.member.get iam.role.get iam.role.list
Project	IAM Role Reader	This role allows listing the roles.	iam.role.get iam.role.list

Deprecated permissions (legacy permissions)

Throughout the evolution of our access management system, we’ve introduced few permission changes. Occasionally, you may still encounter some of these deprecated legacy permissions in the system. They remain for now to ensure a safe transition until we can permanently remove them. The following is a list of these permissions and their descriptions:

Name	Description
organization.memberships.edit folder.memberships.edit project.memberships.edit	These aliases stand for the permissions iam.member.add and iam.member.remove.