Managing Terraform at scale | Spacelift Blog

In this article, I want to give an overview of Open Policy Agent, why you would want to use it, as well as showcasing how you can use OPA with your Spacelift account. Although OPA can be used for many purposes, I&#8217;m going to focus on how it can be used alongside Infrastructure as Code.

Open Policy Agent provides a way of declaratively writing policies as code and then using those policies as part of a decision-making process. It uses a policy language called Rego, allowing you to write policies for various different services using the same language.
OPA can be used for a number of purposes, including:
<ul>
<li style="font-weight: 400;" aria-level="1">Authorization of REST API endpoints.</li>
<li style="font-weight: 400;" aria-level="1">Allowing or denying Terraform changes based on compliance or safety rules.</li>
<li style="font-weight: 400;" aria-level="1">Integrating custom authorization logic into applications.</li>
<li style="font-weight: 400;" aria-level="1">Implementing Kubernetes Admission Controllers to validate API requests.</li>
</ul>
OPA was originally created by<a href="https://www.styra.com/" target="_blank" rel="noopener"> Styra</a>, and is now a part of the Cloud Native Computing Foundation (CNCF), alongside other CNCF technologies like Kubernetes and Prometheus.

We can visualise how OPA works using the following diagram:

how-does-opa-work

how does opa work

As you can see, OPA accepts a policy, input and query, and generates a response based on that. The input can be any valid JSON document, allowing OPA to integrate with any tool that produces JSON output.

In the following sections, I&#8217;ll go into more specific examples of using OPA that should help make things clearer, but before I do here&#8217;s a quick list of reasons that I&#8217;m interested in using OPA:
<ul>
<li>Policies as code allow you to follow your standard development lifecycle with PRs, CI, etc, and provide you with a history of changes to your policies.</li>
<li>OPA is designed to work with any kind of JSON input, meaning it can easily integrate with any tool that produces JSON output.</li>
<li>Because OPA integrates with a number of different tools, it allows you to use a standard policy language across many parts of your system, rather than relying on multiple vendor-specific technologies.</li>
<li>OPA supports unit-testing, making it easier and faster to iterate your policies with confidence that they won&#8217;t break.</li>
</ul>

Let&#8217;s try to make that a bit less theoretical by using a specific example: Terraform. Terraform can produce a plan in JSON format via the terraform show command. This means that we can  define policies for our infrastructure, and use OPA to make a decision about whether a plan is safe to apply or not:

using-opa-with-terraform

using opa with terraform

For example, say we have the following terraform definition to create an EC2 instance:

Now say we want to ensure that every Terraform resource has a Name tag, we could enforce that by creating a file called plan.rego with the following content:

In order to use OPA to evaluate our policy, we need to take the following steps:
<ol>
<li>Generate a Terraform plan as JSON.</li>
<li>Run opa eval to verify whether that plan passes our policy or not.</li>
</ol>

<h3>Step 1 &#8211; Generate our Terraform plan as JSON</h3>
To get a JSON representation of our plan, we need to output our plan to a file, and then use the terraform show command to output that plan as JSON:

<h3>Step 2 &#8211; Run opa eval</h3>
We can then use opa eval to evaluate our plan against our policy:

As you can see, we&#8217;re using the query data.spacelift.allow because our policy is loaded as a data file, and we defined our allow rule in the spacelift namespace. You can also see that opa eval produced empty output ({}). This means that our allow rule didn&#8217;t evaluate to true, and so produced no output.
Let&#8217;s adjust our terraform definition to include a Name tag:

Now if we generate our plan and evaluate the policy again, we should get a slightly different output:

This tells us that the allow rule has evaluated true. We can get that in a slightly more concise way using the pretty format option:

At this stage, you can probably imagine how you could integrate this into your CI/CD pipeline to enforce naming schemes, security rules, and various other organizational policies.

The following examples illustrate some possible use-cases for OPA with Terraform. All of the examples have been taken from the Spacelift <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy#cookbook" target="_blank" rel="noopener">plan policy documentation</a>, but have been altered to work with plain vanilla Terraform.
<h3>Example 1. Require human review when resources are deleted or updated</h3>
Adding new resources is usually a fairly safe operation, but updating or deleting existing resources can carry more risk. You could flag these for human review using the following policy:

<h3>Example 2. Require commits to be reasonably sized</h3>
Once a PR goes over a certain size it becomes difficult to review without missing things. The same is true for Terraform plans. The following policy can be used to warn when the number of changes goes over a certain threshold:

<h3>Example 3. Blast radius</h3>
The following policy attempts to determine the risk of a particular plan by assigning different weightings to the change type (create, update, delete), along with the affected resource type (ECS cluster, EC2 instance, etc). It takes the approach that an update or delete is more risky than a create because it affects an existing resource:

How can we make sure that our policies work as we expect and that they don&#8217;t break over time as we make changes to them? You guessed it: unit testing! Luckily for us, OPA has first-class support for testing via the opa <code>test</code> command.
To create tests for our policy, all we need to do is create another Rego file with a series of rules prefixed with <code>test_</code>. Each rule starting with that prefix defines a separate test. 
Let&#8217;s go ahead and create a file called plan_test.rego, with the following contents:

As you can see, OPA makes it really easy to specify the policy input using the <code>&lt;variable&gt;</code> as <code>&lt;value&gt;</code> syntax. This allows us to create very concise tests by only including values we care about in the policy input, rather than having to use the entire plan output.
Let&#8217;s go ahead and run <code>opa test</code>:

Unsurprisingly our test passes. That&#8217;s not very exciting, so let&#8217;s add a new test to ensure our resources include an <code>Environment</code> tag:

Running opa test again shows us a failure:

Which we can fix by updating our policy:

At this stage if you run the test command again it should show 2 passes:

If you want to know more about OPA testing, the <a href="https://www.openpolicyagent.org/docs/latest/policy-testing/" target="_blank" rel="nofollow noopener">official docs</a> are full of great examples and information about what you can do.

At this stage, hopefully, you&#8217;ve got a pretty good idea of what OPA is as well as how it can be useful to you. It&#8217;s not too difficult to see how you could start integrating OPA into your development process or even use it as part of production systems.
Luckily for you, at Spacelift we&#8217;ve done all the heavy lifting for you, allowing you to get the benefits of using OPA for Policy-as-Code without having to implement everything from scratch for yourself. In this section, I want to showcase some of the functionality that Spacelift provides that relates to OPA.
<h3>1) Policy Types</h3>
Spacelift allows you to use OPA policies to manage various aspects of your Spacelift account,
not just during planning. For example, you can use policies to control who can login to your account, along with what they have access to. For more information see <a href="https://docs.spacelift.io/concepts/policy" target="_blank" rel="noopener">https://docs.spacelift.io/concepts/policy</a>.
<h3>2) PR Checks</h3>
Spacelift can automatically trigger planning runs whenever you push changes to your VCS provider. For example, here&#8217;s what you might see in GitHub after creating a PR:

pr-checks-1

Opa pr checks

If all goes well your check will succeed, but if a policy is violated, a failed check will be reported:

pr-checks-2

opa pr checks

You can then view the details of the failure in Spacelift:

pr-checks-3

<h3>3) Manual Approvals</h3>
Spacelift <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy" target="_blank" rel="noopener">plan policies</a> use a slightly different format than we used in our example policies earlier in this post. Not only do they allow you to specify a message to be displayed, but they also have the concept of <code>deny</code> and <code>warn</code>:

The <code>deny</code> rule fails the run completely, while the <code>warn</code> rule just displays a warning in the logs.
warn rules take on another role when a run is going to deploy changes (vs just showing the planned changes against a PR). If any warnings are reported during a deployment, the run will wait for manual approval before applying any changes.
Let&#8217;s use the following example policy, designed to warn if a certain set of suggested tags aren&#8217;t found on our resources:

If we then attempt to add resources that don&#8217;t contain all of those tags, Spacelift will block before applying the changes, and give us the chance to manually approve or deny the run:
&nbsp;

manual-approvals

manual approvals

This allows you to build complex workflows where certain changes are completely blocked, but others are allowed as long as the changes are reviewed first.
Check out our <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy#cookbook" target="_blank" rel="noopener">plan policy cookbook</a> for more ideas about what you can do.

Spacelift provides a <a href="https://registry.terraform.io/providers/spacelift-io/spacelift/latest/docs" target="_blank" rel="nofollow noopener">Terraform provider</a> for managing your Spacelift account. This means that you can manage the policies available within your account, along with the Stacks they apply to in code.
For example, to add the policy we defined earlier to Spacelift we can use the <code>spacelift_policy</code> resource like this:

We can then attach this policy to a Spacelift Stack using the <code>spacelift_policy_attachment</code> resource:

Taking this a step further, we could create a custom module for defining Spacelift Stacks that ensured that all Stacks had a certain set of policies attached by default.

I hope you&#8217;ve enjoyed this post, and can see the value that OPA brings to the table. If you&#8217;re interested in trying out Spacelift to see what we have to offer, why not sign up for a <a href="https://spacelift.io/free-trial" target="_blank" rel="noopener">free trial</a>? You can setup a Spacelift account in minutes, and get started on your Open Policy Agent journey!

Importing Existing Infrastructure into Terraform - step by step

5 Ways to Manage Terraform at Scale

How a Specialized Management Platform Can Improve Your IaC

Open Policy Agent provides a way of declaratively writing policies as code, and then using those policies as part of a decision making process. It uses a policy language called Rego, allowing you to write policies for various different services using the same language.

What is Open Policy Agent (OPA) and how it works

In this post I want to show how easy it is to create a <a class="dt id" href="https://spacelift.io/" target="_blank" rel="noopener">Spacelift</a> Stack that manages Azure resources. To keep things simple, I’m going to assume that you already know what Spacelift can do, and the basics of creating and running Stacks, but if not check out our <a class="dt id" href="https://github.com/spacelift-io/terraform-starter" target="_blank" rel="nofollow noopener">terraform-starter</a> repo that walks you through the process of setting up an account, and getting started.

In order to allow Spacelift to manage Azure resources, we need to do the following:
<ul class="">
<li id="f0f8" class="hj hk fo hl b hm jf hn ho hp jg hq hr hs jh ht hu hv ji hw hx hy jj hz ia ic jk jl jm gk" data-selectable-paragraph="">Create a Service Principal in Azure with the correct ARM permissions to manage our resources.</li>
<li id="8f2c" class="hj hk fo hl b hm jn hn ho hp jo hq hr hs jp ht hu hv jq hw hx hy jr hz ia ic jk jl jm gk" data-selectable-paragraph="">Create a Stack in Spacelift that uses the <a class="dt id" href="https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs" target="_blank" rel="nofollow noopener">Azure</a> provider.</li>
<li id="ba4d" class="hj hk fo hl b hm jn hn ho hp jo hq hr hs jp ht hu hv jq hw hx hy jr hz ia ic jk jl jm gk" data-selectable-paragraph="">Give our Stack the credentials for our Service Principal.</li>
</ul>
All of the information you need to configure the Azure provider can be found <a class="dt id" href="https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs#authenticating-to-azure" target="_blank" rel="nofollow noopener">here</a>. This post just explains how to combine that information with Spacelift.

To create our Service Principal, we need to use the <code class="js jt ju jv jw b">az ad sp create-for-rbac</code> command (replacing<code class="js jt ju jv jw b">&lt;subscription-id&gt;</code> with your actual subscription ID):

This will output something like the following:

The command creates a new Service Principal called <code class="js jt ju jv jw b">spacelift-sp</code>, and grants it the Contributor role on your subscription. It also outputs the <code class="js jt ju jv jw b">appId</code>, <code class="js jt ju jv jw b">password</code> and <code class="js jt ju jv jw b">tenant</code> for the Service Principal. Make a note of these because you&#8217;ll need them later.
If you would rather assign permissions yourself later, you can run the following command to just create a Service Principal with no permissions:

You should now be able to view your Service Principal in the Azure Active Directory -&gt; App registrations section of the Azure Portal:

Manage Azure Resources

Now that we’ve got a service principal, we need to create a Stack to actually create some Azure resources. To keep things simple all we’re going to do is add some terraform definitions that specify the version of the Azure Provider we want to use, and create an Azure Resource Group:

If you commit that change and try to run your Stack just now, you should see something similar to the following failure:

Here’s the full error message:
Error building AzureRM Client: obtain subscription() from Azure CLI: Error parsing json result from the Azure CLI: Error launching Azure CLI: exec: “az”: executable file not found in $PATH
At first glance this error is slightly confusing, but what it means is that because we didn’t provide any credentials to the Azure provider it attempted to fallback to using the <code class="js jt ju jv jw b">az</code> CLI for authentication. This works fine locally, but won&#8217;t work on Spacelift.
To solve this, we need to provide our stack with our credentials, which is explained in the next section.

If you take a look at the <a class="dt id" href="https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs#authenticating-to-azure" target="_blank" rel="nofollow noopener">Terraform documentation</a>, you’ll find that there are a number of different ways that you can authenticate Terraform with Azure. What we’re going to do here is authenticate using a Service Principal with a Client Secret, and provide that configuration via environment variables.
To do this we need to set the following environment variables, using the information returned by the Azure CLI when we created our Service Principal:
<ul class="">
<li id="1508" class="hj hk fo hl b hm jf hn ho hp jg hq hr hs jh ht hu hv ji hw hx hy jj hz ia ic jk jl jm gk" data-selectable-paragraph="">ARM_CLIENT_ID — the <code class="js jt ju jv jw b">appId</code> from the response.</li>
<li id="4e7d" class="hj hk fo hl b hm jn hn ho hp jo hq hr hs jp ht hu hv jq hw hx hy jr hz ia ic jk jl jm gk" data-selectable-paragraph="">ARM_CLIENT_SECRET — the <code class="js jt ju jv jw b">password</code> from the response.</li>
<li id="8a57" class="hj hk fo hl b hm jn hn ho hp jo hq hr hs jp ht hu hv jq hw hx hy jr hz ia ic jk jl jm gk" data-selectable-paragraph="">ARM_SUBSCRIPTION_ID — your subscription ID.</li>
<li id="7340" class="hj hk fo hl b hm jn hn ho hp jo hq hr hs jp ht hu hv jq hw hx hy jr hz ia ic jk jl jm gk" data-selectable-paragraph="">ARM_TENANT_ID — the <code class="js jt ju jv jw b">tenant</code> from the response.</li>
</ul>
You can set these environment variables directly on your Stack, but what we’re going to do here is create a <a class="dt id" href="https://docs.spacelift.io/concepts/configuration/context" target="_blank" rel="noopener">Spacelift Context</a> and attach it to our Stack. This allows us to share the same credentials with multiple Stacks if we want.
Add a new Context via the Contexts screen in Spacelift:

Once your context has been created, edit it and enter your environment variables, making sure to mark the <code class="js jt ju jv jw b">ARM_CLIENT_SECRET</code> as a secret rather than plaintext:

Now that we’ve got a Context containing our credentials, you can attach it to your Stack. To do this, click on the Manage link next to your Stack, go to Contexts, choose your Context, and click Attach:

Now that your Context is attached, you should be able to see the it in the Environment section of your Stack:

If you try to run your Azure Stack again you should get a successful plan:

If you take a look in the Azure Portal, you should now be able to see the Resource Group that was created:

Before finishing up, I wanted to just point out a few things about the Service Principal credential expiry. Although this isn’t really related to Spacelift, it’s something that you need to be aware of.
When you create your Service Principal via the Azure CLI, it automatically creates a Client Secret for you with an expiry of 1 year:

What this means is that if you do absolutely nothing, your Spacelift Stacks will stop working after the credentials expire a year later. To solve this, all you need to do is generate a new Client Secret, and update the <code class="js jt ju jv jw b">ARM_CLIENT_SECRET</code> environment variable in your Context.

Hopefully in this post I’ve shown that although Spacelift doesn’t have an official Azure integration (yet!), it’s simple to manage Azure resources using Spacelift. Once you’ve performed a little bit of initial setup, you should be able to rapidly get new Stacks up and running creating Azure resources.

In order to allow Spacelift to manage Azure resources, we need to create a Service Principal in Azure with the correct ARM permissions to manage our resources., create a Stack in Spacelift that uses the Azure provider and give our Stack the credentials for our Service Principal.

Managing Azure Resources using Spacelift

In this guide, you will learn how to provision an AWS EKS Kubernetes cluster with Terraform. Let&#8217;s start with the basics.

AWS EKS provides managed Kubernetes clusters as a service. You’re on AWS and want to avoid getting into the details of setting up a Kubernetes cluster from scratch? EKS is the way to go!

You’ll need to have Terraform installed locally:

as well as the AWS CLI:

as well as kubectl:

If you’re on a different operating system, please find the respective installation instructions here:
<ul>
<li style="font-weight: 400;" aria-level="1">Terraform: <a href="https://learn.hashicorp.com/tutorials/terraform/install-cli" target="_blank" rel="nofollow noopener">https://learn.hashicorp.com/tutorials/terraform/install-cli</a></li>
<li style="font-weight: 400;" aria-level="1">awscli: <a href="https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html" target="_blank" rel="nofollow noopener">https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html</a></li>
<li style="font-weight: 400;" aria-level="1">kubectl: <a href="https://kubernetes.io/docs/tasks/tools/" target="_blank" rel="nofollow noopener">https://kubernetes.io/docs/tasks/tools/</a></li>
</ul>

You’ll need to configure your AWS CLI with access credentials to your AWS account. You can do this by running:

and providing your Access Key ID and Secret Access Key. You will also need to provide the region. For the purposes of this guide we will use us-east-2. Terraform will later use these credentials to provision your AWS resources.

You can now clone a repository which contains everything you need to set up EKS:

Inside you’ll see a few files, the main one being eks-cluster.tf:

It uses the EKS Terraform module to set up an EKS cluster with 2 worker groups (the actual nodes running your workloads): one with a single medium machine, and one with two small machines.

You can now create all of those resources using Terraform. First, run:

to initialize the Terraform workspace and download any modules and providers which are used.
In order to do a dry run of the changes to be made, run:

This will show you that 51 resources will be added, as well as the relevant details of them. You can then run terraform apply with the resulting plan, in order to actually provision the resources:

This might take a few minutes to finish. You might get a “timed out” error. In that case, just repeat both the terraform plan and terraform apply steps.
In the end you will get a list of outputs with their respective values printed out. Make note of your cluster_name.

In order to use kubectl, which is the main tool to interact with a Kubernetes cluster, you have to give it credentials to your EKS Kubernetes cluster. You can do that by running:

Just make sure to replace &lt;output.cluster_name&gt; with the relevant value from your Terraform apply outputs.

You can now see the nodes of your cluster by running:

This command is so long because it displays custom columns, and thanks to those we can indeed see that there are 2 smaller nodes, and 1 bigger node.
Let’s deploy an Nginx instance to see if the cluster is working correctly by running:

You can see the status of it by running:

And finally set up a tunnel from your computer to this pod by running:

If you open <a href="http://localhost:3000" target="_blank" rel="nofollow noopener">http://localhost:3000</a> in your browser, you should see the web server greet you:

welcome to ngix

In order to destroy the resources we’ve created in this session, you can run:

This may again take up to a few minutes.

I hope this guide helped you on your Kubernetes journey on AWS! If you want more help managing your Terraform state file, building more complex workflows based on Terraform, and managing AWS credentials per run, instead of using a static pair on your local machine, check out <a href="https://spacelift.io/" target="_blank" rel="noopener">Spacelift</a>. We’d love to have you!

To provision an AWS EKS Kubernetes cluster with Terraform, you first need to have Terraform installed locally and configure your AWS CLI. Secondly, you need to clone a repository that contains everything you need to set up EKS.

How to provision an AWS EKS Kubernetes module with Terraform - step by step

Atlantis is an old and battle-tested self-hosted tool that provides a layer of automation and collaboration for Terraform. Lacking a user interface other than server <a href="https://www.runatlantis.io/docs/server-configuration.html#flags" target="_blank" rel="nofollow noopener">flags</a> and <a href="https://www.runatlantis.io/docs/server-side-repo-config.html#do-i-need-a-server-side-repo-config-file" target="_blank" rel="nofollow noopener">YAML configuration files</a>, Atlantis uses your VCS as one, listening for pull request notifications and posting feedback as comments.
Using Atlantis has two major benefits over running Terraform in a “generic” CI system. First, it strikes the right balance between specialized and flexible: <a href="https://www.runatlantis.io/docs/custom-workflows.html" target="_blank" rel="nofollow noopener">custom workflows</a> give you a level of control that’s not possible within a tool like <a href="https://www.terraform.io/docs/cloud/index.html" target="_blank" rel="nofollow noopener">Terraform Cloud</a>. Second, it runs on your infrastructure, which allows it to access resources inside a VPC or use cloud-specific dynamic credentials.
Spacelift embraces all those characteristics of Atlantis but offers them in as a modern and sophisticated SaaS product that provides:
<ul>
<li style="font-weight: 400;" aria-level="1">a more intuitive, <a href="https://docs.spacelift.io/concepts/policy/git-push-policy" target="_blank" rel="noopener">versatile</a> and <a href="https://docs.spacelift.io/concepts/run#run-state-machine" target="_blank" rel="noopener">robust</a> workflow;</li>
<li style="font-weight: 400;" aria-level="1">extremely granular access controls on <a href="https://docs.spacelift.io/concepts/policy/login-policy" target="_blank" rel="noopener">account</a> and <a href="https://docs.spacelift.io/concepts/policy/stack-access-policy" target="_blank" rel="noopener">project</a> level that work well with an <a href="https://docs.spacelift.io/integrations/single-sign-on" target="_blank" rel="noopener">identity provider of your choice</a> (SSO);</li>
<li style="font-weight: 400;" aria-level="1">an <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy" target="_blank" rel="noopener">automated code review</a> and <a href="https://docs.spacelift.io/concepts/policy/task-run-policy" target="_blank" rel="noopener">threat detection</a> using a consistent open-source <a href="https://www.openpolicyagent.org/" target="_blank" rel="nofollow noopener">policy-as-code framework</a>;</li>
<li style="font-weight: 400;" aria-level="1">the ability to <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">declare complex workflows</a> between projects across multiple repositories;</li>
<li style="font-weight: 400;" aria-level="1">a <a href="https://docs.spacelift.io/concepts/modules" target="_blank" rel="noopener">built-in private module registry</a> with a full CI system for modules;</li>
<li style="font-weight: 400;" aria-level="1">effortless setup and customization with <a href="https://docs.spacelift.io/concepts/environment" target="_blank" rel="noopener">per-project environment management</a> and <a href="https://docs.spacelift.io/integrations/docker" target="_blank" rel="noopener">Docker integration</a>;</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://docs.spacelift.io/integrations/terraform-provider" target="_blank" rel="noopener">programmatic configuration</a> using Terraform;</li>
<li style="font-weight: 400;" aria-level="1">… and a myriad of creature comforts like <a href="https://docs.spacelift.io/concepts/context" target="_blank" rel="noopener">contexts</a>, <a href="https://docs.spacelift.io/concepts/task" target="_blank" rel="noopener">tasks</a> or <a href="https://docs.spacelift.io/concepts/stack#stack-locking" target="_blank" rel="noopener">stack locking</a>;</li>
</ul>
Let’s talk through each of these features one by one.

One of most frequent challenges while using Atlantis in practice is a non-intuitive workflow driven by its reliance on pull requests. Not only is it a lot of work to set up multiple <a href="https://www.runatlantis.io/docs/repo-level-atlantis-yaml.html#supporting-terraform-workspaces" target="_blank" rel="nofollow noopener">workspaces</a> pointing to the same Git repository but the result is fragile and nondeterministic. Since there’s no concept of mapping projects to branches or tags, anyone that can comment on an approved pull request can deploy arbitrary code to production, even if the approval was meant for a short-lived experimental environment.
Spacelift does not depend on pull requests. Sure, it will post beautiful comments there for your convenience, but it’s mostly driven by push and tag events, so it’s easy to build a sophisticated Git flow. Spacelift will report the outcome of its jobs as commit status checks, which then allows you to block merging the code on a failing Spacelift check. There are <a href="https://docs.spacelift.io/concepts/run#where-do-runs-come-from" target="_blank" rel="noopener">two main types of runs</a> &#8211; proposed and tracked. By default, each project points at a particular branch (and optionally also a path) &#8211; pushing to that branch will trigger a tracked run &#8211; one that can be applied. This behavior can be customized using <a href="https://docs.spacelift.io/concepts/policy/git-push-policy" target="_blank" rel="noopener">Git push policies</a>. Thanks to that, Spacelift can provide the same level of comfort and security to teams using one project per repository and those using monorepos with hundreds of interdependent projects. You can read more about our approach to VCS integration <a href="https://docs.spacelift.io/integrations/github#tracked-branches" target="_blank" rel="noopener">here</a>.

Another pain point when using Atlantis at scale is its access control model. By relying on comments on pull requests to drive infrastructure deployments, Atlantis effectively yields control over your infrastructure to the VCS provider. While this is usually fine when a single repository drives a single Terraform project, this becomes a huge liability for more complex scenarios.
Spacelift ships with a sophisticated mechanism allowing administrators to declare <a href="https://docs.spacelift.io/concepts/policy/login-policy" target="_blank" rel="noopener">who can log in</a> (and under what circumstances) and <a href="https://docs.spacelift.io/concepts/policy/stack-access-policy" target="_blank" rel="noopener">what should be their level of access</a> to each of the managed projects. Since it’s 2020, Spacelift ships with SSO out of the box, supporting every identity provider that speaks SAML 2.0 protocol. Even our <a href="https://docs.spacelift.io/integrations/slack" target="_blank" rel="noopener">Slack integration</a> can be subject to policy controls, allowing an admin to grant access to a project <a href="https://docs.spacelift.io/integrations/slack#managing-access-to-stacks-with-policies" target="_blank" rel="noopener">based on Slack-specific data</a> (think team, channel, user etc.). For extra protection, powerful features like Tasks have their own independent policy controls.

Both Spacelift and Atlantis let you use <a href="https://www.openpolicyagent.org/" target="_blank" rel="nofollow noopener">Open Policy Agent</a> &#8211; an open-source solution endorsed by <a href="https://www.cncf.io/" target="_blank" rel="nofollow noopener">Cloud Native Computing Foundation</a> &#8211; to ensure that your infrastructure is compliant with industry best practices and your company policies. Atlantis integrates with <a href="https://www.runatlantis.io/docs/policy-checking.html#how-it-works" target="_blank" rel="nofollow noopener">conftest</a> to achieve that and lets you verify each Terraform plan using OPA policies.
Spacelift goes a few steps further though and puts policy-as-code in the center of its value proposition and builds a consistent, <a href="https://docs.spacelift.io/concepts/policy" target="_blank" rel="noopener">robust policy framework</a>. Apart from providing a comprehensive automated change review and ensuring compliance of your <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy" target="_blank" rel="noopener">Terraform changes</a>, Spacelift uses the same approach to allow you to declare rules around <a href="https://docs.spacelift.io/concepts/policy/login-policy" target="_blank" rel="noopener">account</a> and <a href="https://docs.spacelift.io/concepts/policy/stack-access-policy" target="_blank" rel="noopener">project access</a>, <a href="https://docs.spacelift.io/concepts/policy/git-push-policy" target="_blank" rel="noopener">handling push notifications</a>, <a href="https://docs.spacelift.io/concepts/policy/run-initialization-policy" target="_blank" rel="noopener">starting runs</a> and <a href="https://docs.spacelift.io/concepts/policy/task-run-policy" target="_blank" rel="noopener">triggering tasks</a>, and creating <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">relationships between projects</a>. It also provides the Policy Workbench, which lets you view past executions of your policy &#8211; including the inputs and decisions that have been made &#8211; and lets you interactively edit your policy, while simulating its execution on these previous inputs. You can use our <a href="https://github.com/spacelift-io/terraform-starter" target="_blank" rel="nofollow noopener">starter repo</a> to quickly provision a bunch of policies and get a feel for how you can work with them in Spacelift.

Handling interdependencies between projects has always been Terraform’s Achilles&#8217; heel and Atlantis is no different in that regard. The usual approach to this problem is adding another layer of abstraction in the form of a Terraform wrapper like <a href="https://terragrunt.gruntwork.io/" target="_blank" rel="nofollow noopener">Terragrunt</a>. While this breaks the problem into smaller chunks, it’s only a partial solution achieved at a cost of locking yourself into another dependency.
<a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">Spacelift’s trigger policies</a> on the other hand provide a smart, declarative automation layer on top of vanilla Terraform. These allow you to plug into state changes of individual projects and declare dependencies that should be resolved following the changes that have just been applied. In fact, this is just a subset of all use cases covered by trigger policies. <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">Read more</a> to discover other exciting possibilities.

Another problem that one needs to solve externally when using Atlantis is authoring and maintaining reusable Terraform modules for your organization. Terraform is flexible in allowing modules to come from <a href="https://www.terraform.io/docs/modules/sources.html" target="_blank" rel="nofollow noopener">various sources</a> but ensuring confidential access as well as testing and versioning are left to you, the user.
Until now, the golden standard in that regard has been the <a href="https://www.terraform.io/docs/cloud/registry/index.html" target="_blank" rel="nofollow noopener">private module registry from HashiCorp</a>. But Spacelift offers that, and much more. Far from being just a glorified package manager, Spacelift adds a <a href="https://docs.spacelift.io/concepts/modules" target="_blank" rel="noopener">full CI solution for Terraform modules</a>, out of the box and free of charge. You can thus ensure that your private modules are healthy before you distribute them to the rest of your organization.

If you manage a single or a handful of rarely changing projects using Atlantis, it’s likely that you just set it up once and forget about it. But in a more dynamic environment, where microservices come and go, new environments proliferate and new product teams require their own Terraform workspaces, the need to configure Atlantis each and every time becomes a major nuisance putting a lot of pressure on your DevOps team.
Enter Spacelift. In Spacelift, much of the configuration can be handled by the project owners themselves &#8211; you can add Terraform and/or <a href="https://docs.spacelift.io/concepts/environment" target="_blank" rel="noopener">environment variables</a> and mount files (even inject Terraform code!) programmatically or through the GUI without the need for administrative privileges or changing the central server configuration. For administrators, adding new projects requires minimal hassle since there’s no need to set up webhooks or change any YAML. And it can all be done programmatically, using Terraform.

What comes as a pleasant surprise to long-time Atlantis users, Spacelift entities like stacks, contexts, modules or policies as well as their configuration can be managed in a declarative way using your favorite infra-as-code tool. Yes, that’s right &#8211; <a href="https://docs.spacelift.io/integrations/terraform-provider" target="_blank" rel="noopener">Spacelift offers a Terraform provider</a> that allows you to manage the lifecycle of its own resources programmatically.
 Administrative stacks get credential-less access to the subset of our <a href="https://docs.spacelift.io/integrations/api" target="_blank" rel="noopener">GraphQL API</a> that does not involve managing the actual infrastructure. For more sophisticated use cases, Spacelift allows you to generate API keys that are subject to the same access controls as normal users are, allowing you to create single-purpose tokens for restricted use by your internal scripts.

<a href="https://www.hashicorp.com/blog/detecting-and-managing-drift-with-terraform" target="_blank" rel="nofollow noopener">Infrastructure drift happens.</a> Either somebody will make manual changes while debugging and then forget about them, or you might have data sources whose outputs change periodically. Normally, you would notice these changes only after you execute your next plan or apply.
Spacelift has got you covered here. You can configure periodic <a href="https://docs.spacelift.io/concepts/stack/drift-detection" target="_blank" rel="noopener">drift detection</a> to be notified whenever drift happens and take immediate action. You can go a step further too with optional automatic <a href="https://docs.spacelift.io/concepts/stack/drift-detection#to-reconcile-or-not-to-reconcile" target="_blank" rel="noopener">reconciliation</a>, ensuring your infrastructure always resembles your Terraform configuration.

Last but not least, Spacelift puts an emphasis on great user experience, offering a myriad of creature comforts. <a href="https://docs.spacelift.io/concepts/context" target="_blank" rel="noopener">Contexts</a> for example allow you to attach entire collections of configuration to individual stacks and modules. <a href="https://docs.spacelift.io/concepts/task" target="_blank" rel="noopener">Tasks</a> provide a powerful audited way of running one-off administrative commands on an initialized Terraform environment &#8211; subject to <a href="https://docs.spacelift.io/concepts/task" target="_blank" rel="noopener">their own policy constraints</a>. <a href="https://docs.spacelift.io/concepts/stack#stack-locking" target="_blank" rel="noopener">Stack locking</a> allows a single individual to take exclusive control over a stack to ensure that nobody is able to modify its state while crucial changes are being made. The <a href="https://docs.spacelift.io/concepts/resources" target="_blank" rel="noopener">resources visualization</a> shows you all the resources you’re managing in your account, when and how they’ve last been updated, and lets you slice and dice them using a plethora of views, filters and groupings.

How does Open Policy Agent (OPA) work

The top alternatives to Atlantis include Spacelift, Heroku, Red Hat OpenShift, Hasura. Spacelift embraces all the characteristics of Atlantis but offers them in as a modern and sophisticated SaaS product

Spacelift Blog

Categories

How does Open Policy Agent (OPA) work

Managing Azure Resources using Spacelift

How to provision an AWS EKS Kubernetes cluster with Terraform – step by step

Read also

How does Open Policy Agent (OPA) work

Alternative to Atlantis – Spacelift