As your infrastructure grows, so does the number of stacks in Spacelift. While policies by themselves can help manage everything for a single team in a single account, you’re eventually going to need to have more fine-grained control. Once you have multiple teams and environments that require different policy scopes, context access, cloud integrations, worker pools, and more, it’s time to create some extra guardrails. Luckily, Spacelift has released Spaces to create those guardrails.
Read about the release: Announcing Spaces by Spacelift
Spaces create logical containers for your stacks and resources. For instance, you may want a set of policies to only apply to a set of development stacks while another set applies to your production stacks. This is achievable by using Spaces.
You may also want to ensure your development team does not have access to production context values. This is also possible. Spaces can be used to set up permissions boundaries for any Spacelift resources and limit access to only the stacks within those Spaces from which you have allowed inheritance.
Let’s take a look.
If you have existing resources, such as modules, worker pools, contexts, and policies, the first thing you’ll want to do is assign all of those resources to the root space. Although this isn’t absolutely required, it will simplify the Space creation process and the process of moving stacks to their respective spaces without encountering dependency errors. Since the legacy space that all stacks are assigned to by default inherits all resources from the root, this will work. If you attempt to assign resources to another space from which the legacy space does not inherit, you will also receive an error.
Once you have done this, you can begin creating spaces. If anything breaks, you’ll know you haven’t set up inheritance properly.
Creating Spaces is a very simple process from within the UI. Although it is obviously recommended to create everything via Terraform, the UI will be a good place to start and get familiar with the workflow and options.
In this example, I’ll create spaces for our Administrative, Production, Development, and Sandbox resources.
| Space | Description | Parent | Inheritance |
| administrative | For Spacelift Management | root | Enabled |
| resources | For Dev/Prod Shared Resources | root | Enabled |
| production | For Production Workloads | resources | Enabled |
| development | For Development Workloads | resources | Enabled |
| sandbox | For Tinkering | development | Disabled |
Once I’ve created the Spaces, I can start moving the stacks.
All of the stacks should have no problem moving to their respective Spaces since inheritance is enabled. The only Space that may become an issue is the sandbox Space since inheritance is disabled. If you have any resources associated with a stack that can’t inherit those resources, it will give you an error.
Note: Any changes to Spaces require other users to log out and log back in before they will become effective.
Now that I have my initial spaces created and populated with the necessary stacks, I can begin restricting visibility to certain stack resources from stacks that do not need them. I have created the “resources” Space for any shared resources between the development and production Spaces. This is useful any time you share resources to keep from having to duplicate them.
An example of the Dev Stack having access to the shared-context stored in the resources Space below:
Finally, we can create the policies that ensure only the right people get access to the right Spaces. This can be accomplished using access policies. You can allow all access to the Space or even limit the stacks within the Space that someone can see.
If you find that you are getting too fine-grained with these policies, you may want to consider organizing your stacks in a different way to better reflect your organizational requirements. Keep in mind that, just like other space resources, these policies can be inherited and applied to all child stacks that inherit their parent stack’s resources.
An example policy is here:
package spacelift
developers := { "1337developer", “developer42” }
login := input.session.login
is_developer { developers[login] }
allow { input.session.member }
# Let's give every developer read access to any space
space_read[space.id] {
space := input.spaces[_]
is_developer
}
# Assign write role to developers for spaces with "developers-are-writers" label
space_write[space.id] {
space := input.spaces[_]
space.labels[_] == "developers-are-writers"
is_developer
}
space_admin[space.id] {
space := input.spaces[_]
space.labels[_] == "developers-are-admins"
is_developer
}
# Assign admin role for the root space for anyone in the admin team
space_admin["root"] {
input.session.teams[_] == "admin"
}
sample { true }In the above login policy, we give developers read access to all Spaces, write access to any Space with the label “developers-are-writers”, and full admin access to any space with the label “devleopers-are-admins”.
Note: just like any login policy, if it is updated, it will kill the sessions of any logged in users other than the one editing the policy.
Developer view of the Spaces screen with policies applied:
That’s a basic walkthrough of the new Spaces feature by Spacelift! There are certainly a lot of nuances in these new features as it completely changes the way policies are handled within Spacelift. Check out the documentation for more information and to help ensure you blast off quickly with your much more organized and secure account! You can also try Spacelift for free by creating a trial account.
Automation and Collaboration Layer for Infrastructure as Code
Spacelift is a flexible orchestration solution for IaC development. It delivers enhanced collaboration, automation and controls to simplify and accelerate the provisioning of cloud based infrastructures.
