What Makes Spacelift Secure

Vulnerabilities can be exploited at any point in the application lifecycle. Even if you are doing everything to ensure security on the application level, 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.

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

Following certain best practices 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 TypeII-certified

This certification is not mandatory for SaaS products, but it is one of the most relevant security certifications.

The five pillars of trust assessed for certification are:

• Security
  • Access control, web application firewall (WAF), MFA, intrusion detection
• Availability
  • Monitoring network performance, availability, and site-failover
• Integrity
  • Data integrity and processing
• Confidentiality
  • Data confidentiality and the method for achieving it
• Privacy
  • Collection, use, disclosure, and disposal of personal information

Obtaining this certification requires a CPA firm that specializes in SOC assessments. The certification is valid for 12 months, after which a renewal audit is necessary. The certification renews annually, but you must 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 real-life hackers can exploit them. Multiple types of pen testing are available:

• • White-box testing → Ethical hackers have full knowledge of the system, including source code and architecture diagrams
  • Black-box testing → Ethical hackers have no knowledge of the system
  • Grey-box testing → This is a combination of black- and white-box testing, as ethical hackers 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

SaaS Spacelift is hosted on AWS, with all data sources (S3, databases, SNS Topics, SQS Queues) 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

Spacelift regularly launches multiple features. We have the capacity to release even more features, but security concerns rank higher than anything else.

Whenever we release a new feature, we review its security aspects 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 of logging in using single sign-on (SSO), which 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 → It offers better oversight and control of user access. Using 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, 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 are typically fewer reset requests, as users will need to remember one user/password combination.

To enable SSO on your Spacelift account, you first need to create it using one of the supported Identity Providers. The user who 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 SSO configuration process, 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, check out our guides for:

• Gitlab
• Okta
• OneLogin
• Azure AD

Private workers

The default setting is a managed worker pool that Spacelift hosts and operates. You can configure a private worker pool if you have special security or compliance requirements that cannot be met via a public worker.

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. 

Both public and private workers offer a view that shows information about their status and the number of 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 containing a configuration token will be downloaded automatically. This token is used to establish the connection between your Spacelift instance and the private VCS. When the configuration is complete, 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

Spaces are the component that will help you achieve access control. They are logical containers that typically group stacks, policies, modules, worker pools, and cloud integrations. 

Spaces are used to give users limited admin access, so they can create all the resources mentioned above in their own space, without interfering with entities that are defined in other spaces.

By default, creating an account creates two spaces: 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

The table above shows an example separation of privileges between the roles mentioned and also the Root Space Admin, which has access to everything.

User management

Collaboration requires people to work together, so Spacelift makes user management easy. Users can be invited using their email and authenticated using your Account’s IdP. Permissions can be individual or based on membership of a group.

The same roles apply to a space (read/write/admin). Users can have different access rights on different spaces.

You can find more details of what admins can do with user management here, including how to leverage our Slack integration.

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 that increases the chances of breaches. To avoid the “evil” static credentials, we can leverage dynamic credentials through native integrations.

Spacelift integrates natively with AWS, Google Cloud, and Microsoft 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 be as restrictive as you want:

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

Simply 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, navigate to the stack, go to Settings, and then click 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

Policy as code plays a very important role in governing the Spacelift 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 push 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 offers full flexibility for 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. 

Unlike Terraform’s module registry, Spacelift’s module registry lets you leverage some of the features available for creating your module. 

You can access features such as contexts, policies, and worker pools. You can also unlock tests that help to ensure your module is working properly, and you can even check the code for vulnerabilities by leveraging lifecycle hooks.

Check out how easy it is to configure a module here. To leverage Dependabot to automatically update your modules, this configuration will be helpful.

MFA

MFA acts as the last line of defense by adding an additional layer of security that will protect your users against unauthorized access.

With MFA, even if somebody has your password, they won’t be able to log in to the product you are using without the second form of verification.

In addition, implementing MFA is very cost-effective, especially compared with the potential damage of data breaches. Many industries have rules and regulations that require MFA to protect sensitive data, so implementing it will make you compliant.

Spacelift takes MFA to the next level because it is IdP-independent. Many applications offer MFA that relies fully on their IdP. In Spacelift, you can have MFA implemented on the IdP level, and you can easily enable MFA independently too. Only when the two sessions are successfully merged can you log in to your Spacelift account.

To enable MFA, go to Organization Settings by clicking on your profile at the bottom left of the screen and selecting this option. The Multi-Factor Authentication option is available under Authentication.

As an administrator, you can require all the organization’s members to enable two-factor authentication. Because I don’t have a personal security key in my account, I will first have to create one. I can do this in Personal settings.

After you have followed the steps to configure MFA and try to connect to your Spacelift account, you will see something like this:

OIDC-backed API keys

By default, API keys are static and long-lived, meaning that you will need to rotate and revoke them manually. They are simple tokens that you use to authenticate requests to an API, usually by including them inside the request header or as a query parameter.

OIDC-backed API keys are dynamic and short-lived. Based on the identity provider you use, token management (rotation, revocation, expiration) can be handled automatically.

This makes OIDC-backed API keys more secure because even if they are intercepted, they are short-lived, so the overall risk of misuse is reduced.

To create an OIDC-backed key in your Spacelift account, you need to go to Organization Settings → API keys. From here you can select the Create API key option, and choose OIDC as the type.

You need to provide the following details for it to work:

• Issuer – URL that your OIDC identity provider is reporting as the token issuer in the iss claim of the JWT token
• Client ID (audience) – client ID of the OIDC application you’ve created in the identity provider
• Subject Expression – regular expression that needs to match the sub-claim of the JWT token

Audit trail

Spacelift supports the creation of an audit trail to view all the operations that change Spacelift resources. By recording all of the actions, changes, and events that happen inside your Spacelift account, you can ensure data integrity, thus protecting sensitive information and maintaining trust with users.

Configuring an audit trail is easy. You simply need to provide a webhook endpoint and an arbitrary secret, used for verifying the payload. If you’d like to send the audit trail to an S3 bucket, we have a reference implementation available here.

Check out this video to explore our built-in Audit Trail feature, which aims to provide a faster and easier way to identify issues in your Spacelift account without needing to contact support:

State management

Spacelift manages your Terraform state and 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 use S3 buckets to manage the state, but we enhance security by generating one-off credentials for each run or task and injecting them directly into your Terraform project as a .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 access. We are not aware of any other company that does that.

Self-hosted Spacelift

Spacelift SaaS is secure, but if your organization requires everything to be air-gapped, we have you covered with our self-hosted option.

Read more about the benefits of using Spacelift Self-Hosted on AWS. This article shows you how to configure it.

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

Spacelift’s number one priority will always be security. We are also running a bug bounty program, to prove this, and if you find any vulnerabilities, you are encouraged to submit them, as you will be rewarded:

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.