Elevating IaC Workflows with Spacelift Stacks and Dependencies 🛠️

Register for the July 23 demo →


What Makes Spacelift Secure

What Makes Spacelift Secure

Infrastructure as Code(IaC) offers tremendous scalability, efficiency, and reliability benefits, but it’s essential to remember that it is always subject to security-related threats.

infrastructure vulnerabilities

Infrastructure security

Vulnerabilities can be exploited at any point in the application lifecycle. Even though you are doing everything right on the application level to ensure security, if you don’t focus enough attention on the infrastructure, you will likely have breaches.

The main points where you need to secure your infrastructure are:

  • Network
      • Firewalls → Use stateful and stateless firewalls to filter traffic (Network Security Groups, Network Access Control Lists, etc.).
      • Segmentation → Split network resources as much as possible (use multiple VPCs, subnets, etc.). to reduce blast radiusMonitor network traffic 
  • Access Control
      • IAM → Use the least-privileged access control option everywhere. Define multiple roles and policies to ensure different levels of access.
      • MFA → Use multi-factor authentication — it adds another layer of security by always asking users to provide one-time passcodes in order to log in to their accounts.
      • Response Plans → Ensure your company has a plan in place to respond to security breaches.
  • Data
      • Encryption → Data should be encrypted both at rest and in-transit with strong encryption protocols such as AES.
      • Backup → Regular backups ensure functionality in case of disasters.
  • Runtime
      • Instance hardening → Use base configurations and disable unnecessary services to reduce the blast radius.
      • Regular patching → Apply patches, especially security-related ones as soon as possible.

Common security concerns in IaC

Now that we understood the main points of securing infrastructure, we need to discuss the most common security pattern concerns with IaC:

Issue Description
Misconfiguration This is one of the most common issues in the IaC world and can affect all the main points discussed above.
For example, an engineer could potentially leave a port open in Security Group, leaving a critical EC2 instance accessible to the world.
Hard-Coded Secrets Adding secrets in the configuration code, such as passwords, API Keys, Tokens, etc, will lead to unauthorized access to the application, if the code is compromised.
Lack of Security Tests Many tools can assess your IaC configurations’ vulnerabilities. Without using these kinds of tools and blocking deployments in case issues are found, vulnerabilities are added to the infrastructure, facilitating exploitation.
Lack of Encryption Information sent or received will be stored in a readable format, without encryption, making it vulnerable to unauthorized access or breaches.
Audit Trails Logging and auditing are very important to detect malicious activity. Setting them up as early as possible will facilitate threat detection and response.
Outdated Dependencies Similar to application software (try starting a nodejs application developed 5 years ago without any new changes; you will find over 100 vulnerabilities), IaC can also have outdated dependencies. As soon as tools have a new LTS version available, you should try to update in order to avoid vulnerabilities.

Best practices in IaC security

Putting certain best practices in place can facilitate Infrastructure and IaC security. This should be done as soon as you start a project:

  • Use SSO and enable MFA.
  • Use the Least Privileged access model.
  • Encrypt data at rest and in transit.
  • Use a security vulnerability scanning tool to find breaches in your code or images.
  • Perform audits and penetration testing.

Spacelift security architecture

SOC2 Type II Certified

Even though this certification is not mandatory for SaaS products, in today’s world it is one of the most relevant certifications when it comes to security.

Five pillars of trust are assessed:

  • Security
      • Access Control, Web Application Firewall (WAF), MFA, Intrusion Detection
  • Availability
      • Monitoring Network Performance, Availability, Site-failover
  • Integrity
      • Data Integrity and processing
  • Confidentiality
      • Data confidentiality and how it can be achieved
  • Privacy
      • Collection, Use, Disclosure, and Disposal of personal information

Obtaining this certification involves a CPA firm that specializes in SOC assessments. The certification is valid for 12 months.  A renewal audit will be necessary after that. Even though this certification renews annually, you are required to continuously monitor and refine the trust pillars to ensure compliance.

Security audits

Apart from the SOC2 audit, Spacelift engages regularly with external security firms to perform audits and penetration testing. This process happens at least once a year, and in addition to this, Spacelift’s security team conducts internal audits regularly. 

Penetration testing (pen testing) helps to uncover weaknesses from the perspective of an attacker before the actual hackers can exploit them. Multiple types of pen testing are available:

    • White Box Testing → Ethical hackers will have full knowledge of the system including source code and architecture diagrams
    • Black Box Testing → Ethical hackers will have no knowledge of the system
    • Grey Box Testing → This will be a combination of Black and White testing, as ethical hackers will have partial knowledge of the system

By using this combination of audits and pen testing, Spacelift identifies weaknesses faster and can easily test if security defenses work as expected.


It is no secret that SaaS Spacelift is hosted on AWS. All the data sources we are using (S3, Databases, SNS Topics, SQS Queues) are encrypted at rest using AWS KMS keys with restricted and audited access. The entire data is encrypted at rest and in transit, and all traffic is handled using secure transport protocols, apart from the infra-VPC traffic between the load balancer and the webserver, which is protected by a very restrictive AWS security group.

Customer secrets are extra encrypted at rest, in a way that should withstand even an internal attacker.

Security-first development approach

As you can see, we are launching many features on a monthly basis. We have the capability and the manpower to release even more features than we are currently doing, but for us, security concerns rank higher than anything else.

Whenever we release a new feature, we go through the security aspects of that feature, to ensure compliance and avoid any potential security vulnerabilities.

Spacelift security features

Single Sign-On

Apart from logging in using GitHub, GitLab, and Google, Spacelift offers the possibility to log in using Single Sign-On (SSO). This offers centralized access to resources. To accommodate this use case, you can use either SAML 2.0 or OIDC.

SSO is useful from many points of view:

    • Elevates user experience → Users won’t need to remember multiple usernames and passwords for different applications.
    • Improved security → Offers better oversight and control of user access, and having a single user/password combination, a stronger password policy can be enforced without burdening the users. You can also take advantage of session timeouts to automatically log out users after a period of inactivity, in this way, reducing the risk of unauthorized access.
    • Integrated MFA → Seemless integration with MFA systems will bolster security by requiring an additional verification step.
    • Streamlined onboarding and offboarding → Administrators can manage access from a centralized location. Whenever someone joins or leaves a company, access can be granted or revoked from a single place.
    • Decreases helpdesk costs → With SSO, there will typically be a lower number of reset requests, as users will only need to remember one user/password combination.

To enable SSO on your Spacelift account, you first need to create the account by using one of the supported Identity Providers. The user that creates the account using this option will become the Managed IdP Administrator. 

If you are configuring SSO, this admin user is disabled, and the first user to successfully log in to the Spacelift account will become the SSO Admin. To avoid locking your account, login policies won’t be evaluated for administrator (both Managed IdP and SSO).

Before starting the configuration per-se of SSO, it is important to create backup credentials as shown here, in order to avoid misconfigurations of SSO or to avoid not being able to log in if the SSO provider has an outage.

If you don’t want to use SAML 2.0, you can leverage OIDC. To see how you can configure SSO by leveraging OIDC you check out our guides for:

Private workers

By default, in Spacelift, you will use a managed worker pool hosted and operated by us. If you have special requirements regarding your security or compliance that cannot be obtained via a public worker, you can configure a private worker pool.

To take advantage of the flexibility and security of our private worker pools, temporary run state is encrypted end-to-end by using asymmetric encryption. Only the workers in the configured private worker pool will have access to the temporary run state. 

For both public and private workers, you have a view that shows information about their status and how many queued runs they have.

spacelift private workers

There are three possible statuses for workers:

  • Idle → Available for runs
  • Busy → Is processing or is preparing to process a run
  • Drained → Not accepting new work

When you are selecting a worker pool, you can also see what stacks are using it:

spacelift eks worker pool

You can easily set up private worker pools on both virtual machines or containers by following this guide.

Access private VCS

To access private VCS, you can leverage VCS Agent Pools in Spacelift. They work in conjunction with the private workers, so the workers you are configuring should have access to the private VCS instance.

Creating a VCS Agent Pool can be done by navigating to VCS Agent Pools and clicking on Create VCS Agent Pool.

spacelift private vcs

After you have created the VCS agent pool, a file will be downloaded automatically containing a configuration token. This token will be leveraged to establish the connection between your Spacelift instance and the private VCS. With the configuration done, you will be able to see how many active connections you have.

Whenever you need to specify an endpoint that should leverage your vcs agent pool, you should prepend it with private://my-vcs-agent-pool-name/path.


We talked about access control. Spaces are the component that will help you achieve it. They are logical containers that typically group Stacks, Policies, Modules, Worker Pools, and Cloud Integrations. 

Spaces are used for giving users limited admin access, giving them the ability to create all the resources mentioned above in their own Space, without interfering with entities that are defined in other Spaces.

Two Spaces are created by default when you create the account: the root space which is the father of all Spaces and the legacy space, which is used for backward compatibility to the era of pre-spaces Spacelift.

Three roles can be assigned in a Space:

  • Read → View resources in a Space
  • Write → Read capabilities + trigger runs
  • Admin → Write capabilities + Can create/modify spaced resources
spacelift spaces table

In the above table, you can see an example separation of privileges between the roles mention and also the Root Space Admin, which has access to everything.

Cloud integrations

Whenever you are deploying resources to a cloud provider, you need a mechanism to authenticate to that provider. Sure, you can use static credentials, but by doing that, you will increase the chances of breaches. To avoid the “evil” static credentials, we can leverage dynamic credentials through native integrations in Spacelift.

At Spacelift, you can integrate natively with AWS, GCP, and Azure, and you can also create integrations via OIDC.

Let’s see how easy it is to set up a native integration in AWS.

Before creating the integration, you will need to create a role in your AWS account with a custom trust policy:

spacelift cloud integration custom trust policy

Replace yourSpaceliftAccountName with the name of your Spacelift account.

After that, add permissions to the role. For simplicity, I’ve given administrative access, but you can get as restrictive as you want:

permissions policies spacelift

Add a name to your role, create it, and go to your Spacelift account.

cloud integrations spacelift security

You will only need to add a name to the integration, copy/paste the Role ARN, and click on Create Integration.

To attach the role to any of your stacks, you will need to navigate to the Stack, go to Settings, and then go to Integrations.

attach aws integration

Environment variables and contexts

You can define environment variables in Spacelift with two options:

  • Plain Text variables which have read/write capabilities
  • Sensitive variables which have write-only capabilities
Environment variables and contexts

These variables can be attached directly to a stack, but you can also add them to a Context. With Contexts, you can group multiple environment variables and mounted files and share them between multiple stacks. This is really useful, as it will save considerable time and reduce the overhead of creating the same variables over and over again.


At Spacelift, Policy as Code plays a very important role when it comes to governing the platform. With Policies, you can: 

We understand that OPA can be hard if you don’t have any experience with it, so that’s why we offer:

  • Policy Workbench → Sampling mechanism for policies that makes testing policies easier. This can be used when you are developing the policies per se by providing an input, or you can leverage this mechanism on a run, to use the input you get from your terraform plan 
  • Policy Library → Collection of over 50 reusable policies that can be leveraged in your automation

Let’s walk through the process of creating a simple approval policy that will require your run to have at least two approvals and no rejections:

Go to Policies, select Create Policy, and specify the type as approval. Paste in the following code.

In the end, it should look like this:

creating a new policy

Now, this policy can be attached to any Stack by navigating to the Stack’s settings and selecting policies. 

On a run, this will look like:

policy on run

Custom inputs

Spacelift gives you full flexibility in integrating tools inside your workflow. With our custom inputs feature, if you are integrating a third-party tool, we offer you the ability to define custom policies for it. 

See an example of how you can integrate security tools such as checkov, tfsec, terrascan, and kics.

Module registry

Terraform modules are essential for reusability, and hosting them in a registry and leveraging versioning can help address issues from the start. 

Spacelift’s module registry is a little bit different from Terraform’s module registry, in the sense that, with us, you can leverage some of the other features that we have when you are creating your module. 

Apart from being able to leverage features such as Contexts, Policies, and Worker Pools, with Spacelift’s registry, you are also unlocking tests that help to ensure your module is working properly, and you can even check the code for vulnerabilities by leveraging lifecycle hooks.

You can check out how easy it is to configure a module here, and if you want to leverage Dependabot to automatically update your modules, this configuration will be helpful.

State management

Spacelift manages your Terraform state but also gives you the possibility to manage your own. If you let us manage your state, it is also important to understand how it works

Behind the scenes, we are using S3 buckets to manage the state, but what we are also doing to make things more secure is generating one-off credentials for each run or task and injecting them directly into your terraform project as .tf file.

By using these one-off credentials and our state server, we can easily map state access and state changes to legitimate Spacelift runs, thus protecting against malicious or unauthorized accesses. As far as we know, we are the only ones that do this — more proof that we are a security-first company.

Self-hosted Spacelift

As you have seen, Spacelift SaaS is secure, but if your organization has a requirement to keep everything air-gapped, we got you covered with our self-hosted option.

Read more about the benefits of using Spacelift Self-Hosted on AWS, and if you are interested to see how you can configure it, this article is for you.

Key points

Security is everyone’s responsibility, and with the continuous modernization of infrastructure, the importance of it cannot be overstated. 

Spacelift’s number one priority is and always will be security. With our product, you not only minimize the chances of unauthorized access, but you also get improved resilience and reliability.

If you want to see how flexible our product is in action, you are welcome to create a free account or book a demo with one of our engineers.

The Most Flexible CI/CD Automation Tool

Spacelift is an alternative to using homegrown solutions on top of a generic CI. It helps overcome common state management issues and adds several must-have capabilities for infrastructure management.

Start free trial

How can Spacelift stacks & dependencies elevate your IaC workflows?

Don’t miss our July 23 webinar.

Register for the webinar