Skip to content

Access control»

Spaces provide the organizational structure for Spacelift's role-based access control (RBAC) system. Permission management is handled through login policies or Identity Access Management depending on your authorization strategy. All roles are assigned to specific spaces, providing precise control over who can access what resources.

Roles and RBAC»

System roles»

Spacelift provides several built-in system roles that can be assigned on a space-by-space basis. In short:

  • Space Reader: View-only access to resources within the space, can add comments to runs for collaboration.
  • Space Writer: Space Reader permissions + ability to trigger runs and modify environment variables.
  • Space Admin: Space Writer permissions + ability to create and modify stacks and attachable entities.

The RBAC system reference holds the full definitions of each role and its access level.

Custom roles»

Beyond predefined roles, you can create custom roles with precisely tailored permissions:

  • Granular actions: Compose roles from specific actions like Runs: Trigger run and Stack: Update stack.
  • Business-aligned: Match roles to your organizational structure and job functions.
  • Principle of Least Privilege: Grant exactly the permissions needed, nothing more.

Custom Role Example

Instead of giving someone full Space Admin access, create a custom "Infrastructure Developer" role with just:

  • Space: Read: View space contents
  • Stack: Read: Understand configurations
  • Runs: Trigger run: Deploy changes

A "Root Space Admin" is a user given administrative permissions to the root space, which is the top-level space in Spacelift's hierarchy. This grants special permissions and allows them to manage the entire account, including modifying the space tree and accessing account-wide settings.

Role permissions»

Action / Role Root Space Admin Space Admin Space Writer Space Reader
Set up SSO ✅ ❌ ❌ ❌
Set up VCS ✅ ❌ ❌ ❌
Manage Sessions ✅ ❌ ❌ ❌
Manage Login Policies & Identity Access Management Controls ✅ ❌ ❌ ❌
Manage Audit Trails ✅ ❌ ❌ ❌
Invite/Revoke Users ✅ ❌ ❌ ❌
Create/Modify/Delete Roles ✅ ❌ ❌ ❌
Create/Modify/Delete API Keys, IdP Group Mappings ✅ ❌ ❌ ❌
View Roles, Users, API Keys, IdP Group Mappings ✅ ✅ ❌ ❌
Manage Role Bindings ✅ ✅* ❌ ❌
Manage Spaces ✅ ✅** ❌ ❌
Manage Stack Config Settings ✅ ✅ ❌ ❌
Manage Worker Pools, Contexts ✅ ✅ ❌ ❌
Manage Stack Env Vars ✅ ✅ ✅ ❌
Trigger runs ✅ ✅ ✅ ❌
View Stacks ✅ ✅ ✅ ✅
View Spaces ✅ ✅ ✅ ✅
View Worker Pools, Contexts ✅ ✅ ✅ ✅

*Can only manage role bindings for assigned space(s)

**Can only manage assigned space(s)

Authorization methods»

Identity Access Management»

The Identity Access Management interface provides a way to assign roles to users, groups, and API keys:

  1. Click your name in the bottom-left of the screen, then Organization settings.
  2. In the Identity Management section, select Users, IdP group mapping, or API keys.
  3. Assign predefined or custom roles to specific spaces.

See assigning roles to users for detailed instructions.

Login policies (policy-as-code)»

Login policies can only be created in the root space. Therefore, only root and legacy space admins and stacks with root space admin roles can modify login policies.

Login policies enable programmatic role assignment using OPA/Rego:

Getting role slugs

To use custom roles in login policies, copy the role slug from Organization Settings → Access Control Center → Roles → select role → copy slug.

Use the roles rule to assign RBAC roles in login policies:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
package spacelift

# Basic login permissions
allow if input.session.member

# Assign RBAC roles using role slugs
roles["space-id"] contains "developer-role-slug" if {
    some team in input.session.teams
    team == "Frontend"
}

roles["space-id"] contains "platform-engineer-role-slug" if {
    some team in input.session.teams
    team == "DevOps"
}

# Assign admin role for root space
roles["root"] contains "space-admin-role-slug" if {
    some team in input.session.teams
    team == "Admin"
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
package spacelift

# Basic login permissions
allow { input.session.member }

# Assign RBAC roles using role slugs
roles["space-id"]["developer-role-slug"] {
    input.session.teams[_] == "Frontend"
}

roles["space-id"]["platform-engineer-role-slug"] {
    input.session.teams[_] == "DevOps"
}

# Assign admin role for root space
roles["root"]["space-admin-role-slug"] {
    input.session.teams[_] == "Admin"
}

If a user is logged in, their access levels will not change, so newly added spaces might not be visible. The user must log out and back in to see new spaces they're granted access to.

However, the space's creator immediately has access to it.

How access reaches a space»

The space a role is bound to is rarely the only space that role affects. Access propagation carries a binding down to every descendant space; resource inheritance shares a parent's resources into a child and grants Read back up to the parent; and stacks get implicit read access to their own space and to inheriting parents.

Propagation is always on, while resource inheritance is a per-space toggle. For the full model and how each case shows up in the UI, see How access works.