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.

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:

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.

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.

Encryption

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.

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:

• Gitlab
• Okta
• OneLogin
• Azure AD

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.

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:

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.

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.

Spaces

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

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:

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:

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

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.

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

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.

Policies

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

• Define access control at the Space level with login policies
• Restrict runs based on resource parameters with plan policies
• Require multiple approvals for a run by leveraging the approval policies
• Use trigger policies to control what happens when a PR or a merge occurs
• Define notifications for runs with the notification policies

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:

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:

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.

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.