Skip to main content

Granular Access Controls: Stack-Level Permissions, Scoped Roles, and IdP Delegation

Feature Requests


What would be helpful is to have: Stack-level permissions (e.g. grant preview/apply without needing space admin), Custom roles like: Context editor Policy-only maintainer Read-only + preview, Delegation via IdP-managed groups, Decoupling access from Spaces (Currently forced to move stacks or grant admin to transfer ownership) Avoiding PIM escalations just to test policies or edit contextWe're running into limitations with Spacelift’s current permission model, especially the lack of granularity beyond space-level admin.
Right now it’s either full admin or very limited user, nothing in between. We want to avoid moving stacks just to change ownership.Changing ownership of a stack often requires migrating state or temporary admin elevation, which introduces risk and friction.
Customers with compliance requirements (e.g. HIPAA, SOC 2) need least-privilege enforcement and auditability.

Status: 🔭 Discovery8 comments

Log in to comment and vote

Comments8

  • Ovidiu Moise

    Team•

    Jul 8

    Dear Upvoters, we are actively researching this topic of “granular permissions”. Please share any more use cases that you feel are important to know of.

    • Lime Manatee

      •

      Jul 8

      Hey Ovidiu, one of the use cases for us is while using Templates. E.g., one user is using a template to deploy one or more stacks. Another user is doing the same (same template). There are scenarios where it would be very helpful if the first user could only see the stacks deployed by himself and not the stacks from the second user, and vice versa. And I don’t want to create a Space for every user, as we might end up with hundreds of them.

    • Beige Rain

      •

      Jul 30

      Apologies if some of these are already configurable (I haven’t taken a look at this in a while so they may well be):

      1. Ability to restrict user role’s abilities to configure certain stack settings e.g. the following settings under the Behaviour tab:

      1. ♻️ for ability to prevent changing the source branch for a stack, specifically if it has a label or set of labels. For instance, prohibit changing the source branch for stacks containing a prod label but allow for stacks with test label

      2. Configurable permissions to allow/restrict use of commands executed in Tasks tab and the types of tasks that are permitted for user roles e.g. allow/deny lists for commands that can be run

      3. Allow creation of Shared Views scoped to specific roles and/or views shared only in specific spaces (my understanding is only admins can create these, and not all views are relevant to all teams within an org for instance)

      4. ♻️ from several of the above but configurable permissions based on user role + stack labels and folder labels

  • Azure Chipmunk

    •

    Oct 6, 2025

    I’d like to throw an additional ACL into the ring: managing stack dependencies.

    Right now, it’s only granted via the space-admin permission. I have a very solid use case for granting that separate from admin permissions. Could that be added as a separate permission?

    Thanks!

  • Weronika Siejkowska

    Team•

    Aug 18, 2025

    Hi! Just a quick update — Advanced Access Control (AAC) is now live. It includes:

    • Custom roles with fine-grained action-based permissions (e.g. context editing, run actions)

    • Role assignment to users, API keys, or IdP groups

    • Integration with Login Policies for dynamic role assignment

    • Full support via the Spacelift Terraform provider

    You can manage everything under Organization Settings → Roles.
    More details in our documentation.

    Note: As previously mentioned, roles are still scoped at the Space level — stack-level ACLs aren’t planned at this time.

  • Natalia Gazda

    Team•

    Jun 25, 2025

    Thanks for the detailed request. Most of what you're asking for is already in progress with Advanced Access Control (AAC) V2, which addresses the core limitations you've identified.

    What AAC V2 will deliver:

    • Custom roles with specific action permissions (context editing, policy management, etc.)
    • Role bindings for users, API keys, and SSO groups
    • IdP delegation through group-based role assignments
    • Fine-grained permissions that eliminate the current binary admin/user model

    What we're clarifying in the next 1-2 weeks:
    Whether to include policy-specific roles (policy development/testing without broader admin access).

    What we'd like to understand better:
    You mentioned needing stack-level permissions specifically. Can you help us understand what workflow would require access to individual stacks rather than spaces? Most use cases we see involve teams needing access to related stacks within the same domain/environment.

    Our hypothesis is that AAC V2's role-based approach will solve your core workflow problems without the complexity of individual stack permissions. But we'd love to hear about specific scenarios where space-level roles wouldn't work.

    Would you be open to a brief call to walk through your specific use cases once AAC V2 details are finalized?

    • Gold Pear

      •

      Jun 26, 2025

      Is there any plan allowing ACLs on the stack as well? We sometimes have 3 stacks in a space and would like to have a group that has Read on 1 our of 3 . Right now this is not possible without setting up some complicated rego policy

      • Natalia Gazda

        Team•

        Jul 24, 2025

        I’m afraid that won’t be possible. “Lowest” we’ll provide is space.