Flavius is a passionate Developer Advocate with an Infrastructure as Code mindset and expertise in DevOps & Cloud Engineering.

All posts by Flavius Dinu - DevOps Expert

Flavius Dinu

Author title

Title category

Get all the latest content on Infrastructure as Code, DevOps, Spacelift features & news directly to your inbox!

Level up your IaC knowledge. Stay up to date with educational devops guides & news in infrastructure as code, cloud & more!

Managing Infrastructure at Scale | Spacelift Blog

applepodcasts

spotify

missionctrl

Welcome to missionCTRL, a show dedicated to exploring the frontiers of modern DevOps. Listen (or watch) as we sit down with the practitioners who are pushing the boundaries of development

Infrastructure as Code (IaC) using Terraform

Want to level up your Terraform knowledge? Explore our tutorials and step-by-step guides written by Terraform experts. Learn Terraform best practices and solutions to the most difficult problems.

Terraform Guides and Tutorials | Spacelift Blog

Terraform

Infrastructure as Code (IaC) is the process that enables engineers to define, configure and manage Infrastructure through code. This approach treats underlying infrastructure components, such as networks, virtual machines, storage, databases, and others, in the same way, developers treat their application code. 
When it comes to managing Cloud resources, Terraform is the de-facto standard. <a href="https://spacelift.io/blog/what-is-terraform" target="_blank" rel="noopener">Terraform</a> is an open-source IaC tool that allows engineers to define their infrastructure resources as code, using a declarative programming language called Hashicorp Configuration Language (HCL). It is provider agnostic, meaning that it supports a large number of Cloud providers (AWS, Azure, GCP, OCI, and many more), and the language in which you are writing the code doesn’t change from one provider to another.
By using Terraform, you are not limited to Cloud providers, as you can write Terraform automations for Kubernetes, Helm, Artifactory, Aviatrix, and Spacelift, to name a few. You can even define your own provider → as long as your product exposes an API, a Terraform provider can be built on top of it.
In this article, we will cover:
<ol>
<li><a href="https://spacelift.io/blog/terraform-infrastructure-as-code#clickops-vs-iac">ClickOps vs. IaC</a></li>
<li><a href="https://spacelift.io/blog/terraform-infrastructure-as-code#key-terraform-components">Key Terraform components</a></li>
<li><a href="https://spacelift.io/blog/terraform-infrastructure-as-code#minimal-structure-of-a-terraform-project">The minimal structure of a Terraform project</a></li>
<li><a href="https://spacelift.io/blog/terraform-infrastructure-as-code#reasons-to-choose-terraform-for-your-iac">Reasons to choose Terraform for your IaC</a></li>
<li><a href="https://spacelift.io/blog/terraform-infrastructure-as-code#example-kubernetes-deployment-on-azure-using-terraform">Example Kubernetes deployment on Azure using Terraform</a></li>
<li><a href="https://spacelift.io/blog/terraform-infrastructure-as-code#enhance-your-iac-workflow-with-spacelift">Enhancing your IaC workflow with Spacelift</a></li>
</ol>

ClickOps is the term used to describe the manual management of IT infrastructure from the UI, by clicking into the portal to achieve a desired behavior (create/edit/delete resources). One may argue this process is enough for a small architecture that needs to be deployed, but there actually are some big issues with starting like this: you cannot easily scale and replicate your configuration. 
Imagine you are creating an EC2 Instance inside AWS. By using ClickOps, you are going to create it way faster than you would normally do it through Infrastructure as Code. But what happens if you need to create 10 EC2 instances? What about 100 EC2 instances? 
Let’s suppose it takes an engineer approximately two minutes to create an EC2 through the portal. For 100 instances, this will take a little over three hours, and maybe some can be ok with that. These 100 instances will also need to reside in a network, they will require security groups, maybe some EBS storage, and other things that will again take a lot of time to configure. 
Doing this manually is very error-prone, as our attention span cannot keep up with the large number of things that we have to do. By using Terraform, you can easily define all of these components as code, validate the code, plan to see what is going to happen, and in the end, deploy all resources in one go. Apart from that, you can easily <a href="https://spacelift.io/blog/5-ways-to-manage-terraform-at-scale" target="_blank" rel="noopener">scale</a> and replicate your configuration without spending too much time.

Terraform is stateful, tracking the state of the infrastructure by comparing the current defined IaC configuration and a state file it generates after a Terraform run. This introduces a layer of complexity because you need to manage this state file.
If organizations use a combination of IaC and ClickOps, they will introduce <a href="https://spacelift.io/blog/terraform-drift-detection" target="_blank" rel="noopener">Drift</a> and sometimes even break their infrastructure resources. So if you are getting into IaC, and you should really do, forget about ClickOps.
<h3>Providers</h3>
In essence, Terraform providers function as plugins that enable Terraform to communicate with specific infrastructure resources. These providers serve as a bridge between Terraform and the underlying infrastructure, converting Terraform configurations into relevant API calls and permitting Terraform to handle resources across numerous environments. 
Example provider:

Take a look at <a href="https://spacelift.io/blog/terraform-providers" target="_blank" rel="noopener">Terraform Providers Overview</a>.
<h3>Resources</h3>
In Terraform, resources represent the infrastructure elements that can be managed, such as virtual machines, virtual networks, DNS entries, pods, and more. 
Each resource is identified by a specific type, like &#8220;aws_instance&#8221;, or &#8220;kubernetes_pod,&#8221; and possesses a range of configurable attributes, such as instance size or type. They are the building blocks of Terraform, and every configuration that will create a piece of the infrastructure has to contain a resource.
Example resource:

<h3>Variables</h3>
<a href="https://spacelift.io/blog/how-to-use-terraform-variables" target="_blank" rel="noopener">Terraform variables</a> are similar to variables in any other programming language. They are used to better organize your code, make it easier to change its behavior, and make your configuration reusable. In Terraform, variables can have the following types: string, number, bool, list, set, map, object, and null. 
You cannot use variables to hold expression values built from resources or data sources. For that, you should use a local variable.
Example Variable:

<h3>Outputs</h3>
An output serves as a convenient method for displaying the value of a particular data source, resource, local, or variable once Terraform has completed implementing infrastructure modifications. They can also be used to expose attributes from a <a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work" target="_blank" rel="noopener">Terraform module</a>.
Example Output:

<h3>DataSources</h3>
A data source is an object that retrieves data from an external source and can be used in resources as arguments when they are created or updated, or you can use them in locals to manipulate the data you receive.
Example Datasource:

<h3>Locals</h3>
In Terraform, a local variable assigns a name to an expression and makes it easy for the user to utilize it. Typically, in any programming language, when you have a complex expression, you don’t want to write it a million times throughout your code. You are usually defining a variable that holds it or a function that implements it. 
Local variables work similarly to that, and they can be used in conjunction with resource and datasource attributes to build complex expressions.
Example Local:

<h3>Provisioners</h3>
Provisioners exist inside of a resource, and they are used to either run a local command or a remote command or to copy a file from your local environment to a remote virtual machine. 
They are considered a last resort option due to the fact they are not a part of Terraform’s declarative model. You should typically use cloud-init to run different scripts on your vm during the bootstrap phase, or if you can, use a configuration management tool like <a href="https://spacelift.io/blog/ansible-tutorial" target="_blank" rel="noopener">Ansible</a> for this.
Example Provisioner:

Learn more about <a href="https://spacelift.io/blog/terraform-provisioners" target="_blank" rel="noopener">Terraform Provisioners and why you should avoid them</a>.

<ul>
<li><a href="https://spacelift.io/blog/5-ways-to-manage-terraform-at-scale" target="_blank" rel="noopener">5 Ways to Manage Terraform at Scale</a></li>
<li><a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener">How to Automate Terraform Deployments and Infrastructure Provisioning</a></li>
<li><a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener">How to Improve Your Infrastructure as Code using Terraform</a></li>
</ul>

A basic structure of a Terraform project, contains the following files:

In main.tf typically contains the core resource declarations and providers. This is the place in which you would define your EC2 instance configurations and how to authenticate to the AWS provider.
The variables.tf file define the input variables that allow engineers to customize the project. They are referenced in the main.tf and can easily change the behavior of a particular resource, making this easy to reuse the automations.
In the outputs.tf file, engineers define the outputs that are returned to the console after a terraform apply. As a best practice, they shouldn’t return all the data from a resource, only the important fields that are of interest.
Documentation is really important, so having a README.md file inside your Terraform repository that explains how to use the automation (including descriptions of variables and outputs) really help in understanding what has been implemented. To easily generate the description of variables and outputs, you can leverage <a href="https://terraform-docs.io/" target="_blank" rel="nofollow noopener">tfdocs</a>.
This is just a basic structure, but it can be customized depending on the complexity of the automation and, of course, the requirements of the organizations.

All the resources presented above are the building blocks for creating Terraform automations. The declarative syntax that Terraform offers is easy to understand and use and enables engineers to get up to speed quickly with these concepts.
Terraform’s init/plan/apply workflow help prevent unintended changes to your infrastructure by previewing changes before they are actually made. The initialization part also ensures the required providers are downloaded, so you don’t need to push them to your vcs repository to be able to take advantage of them. 
Nowadays, more and more people are using Terraform. The community is large and very active, and there are a lot of resources available, like documentation and tutorials, that can be easily leveraged.
The code you build with Terraform can be packaged as a module and shared across your organization easily. There are many other features available that keep your code DRY, such as for_each, count, functions, ternary operators, loops, and dynamic blocks. 
Due to the fact that it’s cloud agnostic, you can use Terraform to build multi-cloud automations without having to use multiple tools together to achieve this.

The example code can be found <a href="https://github.com/flavius-dinu/terraform-az-free-aks" target="_blank" rel="nofollow noopener">here</a>.
In the above example, we are using two resources:
<ul>
<li style="font-weight: 400;" aria-level="1">azurerm_resource_group → used to create resource groups inside of Azure</li>
<li style="font-weight: 400;" aria-level="1">azurerm_kubernetes_cluster → used to create the Kubernetes cluster inside of Azure</li>
</ul>
For this example, the cluster management will always be free, you will need to pay only for the underlying nodes of the cluster.
On both of the resources, we are using for_each in order to be able to create how many resources of that particular type we want.

If you look at the above resources, you are going to see how the link between them is created on the Kubernetes one, specifically at the location and resource_group_name parameters. Due to the way it’s done, we are ensuring the resource group is created first, and we are accessing its location and name attributed inside of the Kubernetes Cluster. 
In that way, the cluster and the resource group in which the cluster will be created will reside in the same location.
To declare the variables, we are using map(object) types in order to take advantage of the full capabilities of the for_each, and we are also ensuring optional values to make the code easier to use.

To keep it simple, we are providing the values of these variables in the defaults block, but you can use <a href="https://spacelift.io/blog/terraform-tfvars" target="_blank" rel="noopener">terraform.tfvars</a> or a *.auto.tfvars file, or environment variables to pass these values. 
You can even use a local variable to specify the values, or if you want to take it to the next level, you can use a local variable that reads the contents of a YAML file with values by using the file and yamldecode functions.
Right now, with the default values, this looks like this:

For this configuration, we have declared two outputs, one will show a map containing name and location pairs for the resource groups and the other one will have some details related to the Kubernetes cluster in the following format name =&gt; id, fqdn.

In order to run this code we have to go and initialize the working directory by using <code>terraform init</code>.

After that, we can apply the code using the <code>terraform apply</code> command.

You can see the cluster now into the Azure Portal:

terraform-iac-azure-portal

terraform iac azure portal

Terraform is really powerful, but in order to achieve an end-to-end secure Gitops approach, you need to use a product that can run your Terraform workflows. 
Enter Spacelift. Not only <a href="https://docs.spacelift.io/" target="_blank" rel="noopener">Spacelift</a> takes care of your Terraform workflows, but it can also help build workflows for Kubernetes, Pulumi, and CloudFormation. Spacelift is GitOps Native, and by also taking advantage of stack dependencies, you can build really sophisticated workflows.
Your workflows will most likely require policies to ensure the necessary guardrails for your infrastructure. Apart from that, taking advantage of notifications when something goes wrong is really important, so taking advantage of Spacelift’s built-in features will totally help.
Taking advantage of integrations with major cloud providers avoids using static credentials, which can be easily replicated if you are not careful with them.
<a href="https://spacelift.io/blog/integrating-security-tools-with-spacelift" target="_blank" rel="noopener">Integrating security tools</a> in your workflows can be done easily by using Custom Inputs. With this feature, not only are you integrating the tools, but you can easily run policies on it to ensure engineers are not introducing vulnerabilities with their code.
If Terraform modules make your code DRY, check out <a href="https://docs.spacelift.io/concepts/blueprint/" target="_blank" rel="noopener">Spacelift’s Blueprints feature</a>, which really takes reusability to the next level.
Let’s reuse the above example and create a stack for it in Spacelift. We will also apply a policy that ensures that people are not changing the size of the VM. I would suggest creating your own repository that holds the above code to integrate everything.
First, go to stacks and select create a new stack. Add a name for the stack, and optionally you can add labels and a description.

terraform-iac-create-new-stack-spacelift

terraform iac create new stack spacelift

After that click continue, and on the Integrate VCS tab, select the repository, and you can leave everything else as a default. 
In the configure backend tab, you can select the backend (in our case, it will be Terraform), the Terraform version, whether or not Spacelift manages your state, and if you want smart sanitization enabled.

terraform-iac-smart-sanitization-spacelift

terraform iac smart sanitization spacelift

Select continue and in the define behavior tab, let’s leave everything as a default.
Now your stack has been created. You need to handle the authentication to Azure before starting to run the stack per se. There are multiple ways in which this can be done, and <a href="https://docs.spacelift.io/integrations/cloud-providers/azure">Spacelift’s documentation</a> is thoroughly explaining this. 
After you are done with this, you can start running your code. By triggering a run, in the end, you are going to see an output of terraform plan. If you want to create the resources inside this plan, you will need to confirm it. Otherwise, you can easily discard it and make other changes to your code.

terraform-iac-run-code-spacelift

terraform iac run code spacelift

After confirming the run, an apply job gets triggered and this is its output.

terraform-iac-apply-spacelift

terraform iac apply spacelift

As you can see, the subscription id is directly masked inside the output, which also makes for easier demonstrations without having any fear that you will be leaking sensitive information.
The workflow can be easily extended each step of the way by either adding commands before and after phases, changing the runner image, integrating security tools, adding policies, and others.

terraform-iac-advanced-options

terraform iac advanced options

Infrastructure as Code has become a standard nowadays in the DevOps and Cloud Engineering world. It makes it easier to create, update and replicate your infrastructure while mitigating human errors. Terraform is very powerful, and the community around it is really big.
Choosing Terraform as your Infrastructure as Code tool and enhancing your workflow with Spacelift to achieve GitOps reduces your time to market, makes the experience more secure, and helps you easily integrate with third-party products.

<span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Build more complex workflows based on Terraform using policy as code, programmatic configuration, context sharing, drift detection, resource visualization and many more.&quot;}" data-sheets-userformat="{&quot;2&quot;:769,&quot;3&quot;:{&quot;1&quot;:0},&quot;11&quot;:4,&quot;12&quot;:0}">Build more complex workflows based on Terraform using policy as code, programmatic configuration, context sharing, drift detection, resource visualization and many more.

Initialize/ plan/ apply your IaC, manage modules, state, and more. 

frame-8479

Frame 8479

Terraform Architecture Overview - Structure and Workflow

Terraform Cloud/Enterprise Pricing - Tiers Overview 2023

How to Deploy your Infrastructure in CI/CD using Terraform

How to manage Infrastructure as Code using Terraform? See the overview, benefits, and different approaches.

193-terraform-infrastructure-as-code

Managing Infrastructure as Code (IaC) With Terraform

<a href="https://developer.hashicorp.com/terraform/cloud-docs" target="_blank" rel="nofollow noopener">Terraform Cloud</a>, developed by HashiCorp, offers a centralized platform for managing Terraform code. Key features include version control integration, secure variable storage, remote state management, and policy enforcement, enabling organizations to efficiently maintain control over their cloud infrastructure.

Before the recent updates, HashiCorp Terraform Cloud was available at multiple price points: The free tier includes some basic features; the Team tier was priced at $20 per user per month and offered everything in the free tier plus role-based access control, the Team and Governance tier was priced at $70/user and included everything in the Team tier plus Policies; the Business tier was their most comprehensive option.
 Below you can see what Terraform Cloud Price looked like before the changes were made.

<table>
<tbody>
<tr>
<td></td>
<td>Free Tier</td>
<td>Team Tier</td>
<td>Team &amp; Governance Tier</td>
<td>Business Tier</td>
</tr>
<tr>
<td>Price (monthly)</td>
<td>Free</td>
<td>20$/user</td>
<td>70$/user + 500$ per extra concurrency</td>
<td>Undisclosed, you need to contact their sales team</td>
</tr>
<tr>
<td>Features</td>
<td>&#8211; State Management &amp; Locking
&#8211; VCS Integration
&#8211; Private Module Registry
&#8211; API Tokens
&#8211; Variable Sets</td>
<td>Free + 
&#8211; RBAC</td>
<td>Team + 
&#8211; Policies 
&#8211; Run tasks 
&#8211; Cost Estimation</td>
<td>Team &amp; Governance + 
&#8211; Agents 
&#8211; SSO Integration 
&#8211; Audit Logs 
&#8211; Drift Detection 
&#8211; Premium support</td>
</tr>
<tr>
<td>Concurrency</td>
<td>1</td>
<td>1</td>
<td>1</td>
<td>Scaling to unlimited</td>
</tr>
</tbody>
</table>

HashiCorp recently switched to a new pricing model for Terraform that includes only three plans for the SaaS version: Free, Standard, and Plus. The Plus plan (quote available from the sales team) is similar to the old Business Tier feature-wise, but the most remarkable change appears in the Free and Standard levels: Hashicorp has switched to a RUM (Resources Under Management) pricing model. 
In the standard tier, they will manage 500 resources in the state for free. For every other resource you have in the state above the 500 resource threshold, you will have to pay $0.00014/hour. In the free tier, the resources will be limited to a maximum of 500, making the upgrade to the standard tier necessary. At first, this doesn’t seem like a big cost, but remember that every security group rule is a resource, and everything you can configure about an S3 bucket (life cycle, versioning, policies, etc.) is a resource.
This pricing model is unsustainable for many customers, as it will be very hard to predict what their bill will look like at the end of the month. There are a couple of resources that Hashicorp states are not taken into consideration in the billing process (null_resource and terraform_data), but still, if you go to your in-app plan &amp; billing tab, you will see them there. In the below example, in my account, I have deployed 600 terraform_data resources and 600 other resources:

tfc-pricing-plan-and-billing

tfc pricing plan and billing

Billing doesn’t update in real-time or not even near real-time, and you can’t even see these updates in your HCP account.
In the previous pricing tiers, they weren’t offering any premium features in the free tier or in the predecessors of the standard tier. In my opinion, they are still not doing that, as you only get a taste of policies and run tasks, which are two essential features that make your workflows usable. Now, instead of nothing, you get a mere 5 policies in both free and standard tiers, one Run Task integration, and ten Workspace Run Tasks. Some may argue these are enough, and in some cases, that might be true, but there is a catch: 
Only one policy can be Soft/Hard mandatory, and one run task can be mandatory, so you will need to pay extra attention to your runs, or else you will have to upgrade to the Plus or Enterprise tier.
Implementing a custom workflow is still really difficult because you are limited to what Terraform Cloud offers in their run tasks. It’s impossible to integrate other tools into your workflow without using an external CI/CD platform like Github Actions.

Another option Hashicorp offers for Terraform Cloud is its Enterprise solution. The main difference is that Terraform Enterprise is self-hosted and offered as a private installation rather than a SaaS solution. Terraform Enterprise offers most of the same features as the Terraform Business tier.

<ul>
<li><a title="Terraform Cloud / Enterprise Alternative" href="https://spacelift.io/terraform-cloud-alternative" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Atlantis vs. Terraform Cloud vs. Terraform Enterprise&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Alternative to Terraform Cloud / Enterprise</a></li>
<li><a href="https://spacelift.io/blog/why-devops-engineers-recommend-spacelift" target="_blank" rel="noopener">Why DevOps Engineers Love and Recommend Spacelift</a></li>
<li><a href="https://spacelift.io/blog/how-to-migrate-from-terraform-cloud" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;How to Automate Terraform Deployments and Infrastructure Provisioning&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">How to Migrate from Terraform Cloud to Spacelift</a></li>
</ul>

Judging from the AWS Marketplace and Azure Marketplace offerings of Terraform Enterprise, pricing starts from $15,000/year, but it includes only five workspaces, which of course, won’t be enough for an enterprise prepared to spend this kind of money on an enterprise-grade solution.

Spacelift is a <a href="https://spacelift.io/terraform-cloud-alternative" target="_blank" rel="noopener">Terraform Cloud alternative</a> that offers a customizable GitOps workflow for managing infrastructure at scale.
<h3>Powerful free tier</h3>
As well as the ability to run Terraform workflows and offer feature parity, Spacelift also enables you to create workflows with Kubernetes, Pulumi, and Cloud Formation. This, combined with the <a href="https://docs.spacelift.io/concepts/stack/stack-dependencies#how-it-works" target="_blank" rel="noopener">stack dependencies</a> feature, gives you the flexibility to build end-to-end workflows. By defining dependencies, you have a way of triggering runs on multiple stacks without having to go through each manually. 
You also fully own your workflow: You can bring custom code, custom <a href="https://docs.spacelift.io/concepts/run/task.html" target="_blank" rel="noopener">tasks</a>, and even a <a href="https://docs.spacelift.io/integrations/docker.html#customizing-the-runner-image" target="_blank" rel="noopener">custom runner image</a>, and you can install and configure any third-party security tools and embed them in your use case. In Terraform Cloud, you can only leverage run tasks, which will always be limited to what Terraform Cloud supports at a given moment.
All of these features are offered in the free tier. Combined with <a href="https://docs.spacelift.io/concepts/policy/" target="_blank" rel="noopener">Spacelift’s Policy As Code</a> framework based on OPA (plan and approval policies included for free), this makes it really easy to use the free tier to host your personal projects, and utilizing all these features will really help you become more skilled at handling enterprise workloads. You can even define custom plan policies based on your third-party integrations, using <a href="https://spacelift.io/blog/integrating-security-tools-with-spacelift" target="_blank" rel="noopener">Custom inputs</a>. 
OPA uses Rego to define policies, and Rego can be hard to master. At Spacelift, you can harness the <a href="https://docs.spacelift.io/concepts/policy/#policy-workbench" target="_blank" rel="noopener">Policy workbench</a> to help you speed up policy development by <a href="https://docs.spacelift.io/concepts/policy/#sampling-policy-inputs" target="_blank" rel="noopener">sampling</a> the inputs. In addition to that, you can leverage <a href="https://github.com/spacelift-io/spacelift-policies-example-library" target="_blank" rel="noopener">Spacelift’s policy library</a> to get started.
Terraform Cloud does not provide an overview of all of your deployed resources, whereas Spacelift’s Resource Visualization feature makes it really easy to understand what has been deployed in your infrastructure.

resource-visualization

resource visualization

Security is key for Spacelift. That’s why we are strongly against using static credentials so you can take advantage of our integrations with AWS, Azure, and GCP.
Cost estimation is another feature that Spacelift offers free, via <a href="https://spacelift.io/blog/terraform-cost-estimation-using-infracost" target="_blank" rel="noopener">Infracost</a>. This allows you to predict what your bills will be for your cloud resources at the end of the month. You can easily define policies to do things like restrict creating resources if the hourly or monthly cost exceeds a set threshold. 
Terraform Cloud also offers a cost estimation option, but it will most likely confuse everybody, as it only takes into consideration what you are going to pay for the resource in a specific cloud provider and not how much that resource will cost to be held in the state for a month.

cost-estimation

cost estimation

Even the free Spacelift tier offers some enterprise features, making it a real game-changer for most users. 
<h3>Cloud tier</h3>
With the Cloud tier, you can unlock all policies and integrate with monitoring, chat, and other DevOps tools using notification policies, as well as make decisions in your runs based on what happens in response to a Git push or pull request. Pricing starts at $250/month and includes 5 users and a concurrency of 2.
This tier also offers a Datadog integration you can leverage to take observability to the next level inside Spacelift. Read more about it <a href="https://docs.spacelift.io/integrations/observability/datadog" target="_blank" rel="noopener">here</a>. Other integrations can be easily built by following the same approach with our notification policy.
Using <a href="https://docs.spacelift.io/integrations/cloud-providers/oidc" target="_blank" rel="noopener">OpenID Connect</a>, you can easily exchange short-lived Spacelift credentials for temporary credentials valid for external service providers such as AWS, Azure, GCP, Vault, and others. 
Multitenancy with <a href="https://docs.spacelift.io/concepts/spaces/" target="_blank" rel="noopener">Spaces</a> is also available in this tier, making access control easier. With Spaces, you can delegate limited admin access to some of your users in a particular space.
<h3>Enterprise tier and Self-Hosted</h3>
Similar to Terraform Cloud, Spacelift’s Enterprise tier offers private workers, Drift Detection, and many other interesting features:
Advanced Scheduling enables you to delete all the resources inside your stack and the stack itself. This is a helpful way to save costs by deleting all the resources after working hours and on the weekends. With this feature, you can also schedule arbitrary tasks that you want to happen on a particular schedule.
<a href="https://docs.spacelift.io/concepts/blueprint/" target="_blank" rel="noopener">Blueprints</a> are really powerful. You can create templates with the code, as well as the policies attached to that code, the authentication to the cloud provider, environment variables, shared variables, advanced scheduling, drift detection, and more. This takes reusability to the next level: You configure the template once and use it to create as many stacks as you want. 
Terraform Cloud has two features that combined don’t even come close to Blueprints: Design configuration (which just generates simple code that leverages an existing module, based on its input variables) and No-Code provisioning (don’t get too excited, you will still write the Terraform code) which just gives the option to give some predefined values to the variables of a module and enable users to deploy workspaces from that without giving them the possibility to make any changes.
Spacelift supports auditing of all operations that happen inside the platform on the resources. With the <a href="https://docs.spacelift.io/integrations/audit-trail" target="_blank" rel="noopener">Audit Trails</a> feature, you can easily send your audit trails to an endpoint you provide.
To see which tier of Spacelift best suits your business, check out our <a href="https://spacelift.io/pricing" target="_blank" rel="noopener">various pricing plans</a>.
<h3>Migrate from Terraform Cloud to Spacelift</h3>
Many people can be reluctant to change, as it usually involves a lot of manual steps that have to be done, and the process can be really error-prone. At Spacelift, we understand this, and we’ve provided a seamless way of migrating your Terraform Cloud Workspaces. The steps on how to do it are available in this <a href="https://spacelift.io/blog/how-to-migrate-from-terraform-cloud" target="_blank" rel="noopener">7-minute article</a>.
We already have a couple of customers that migrated from Terraform Cloud to Spacelift, and you can read more about one of them <a href="https://spacelift.io/customers/logixboard" target="_blank" rel="noopener">here</a>.

Although Terraform Cloud offers many interesting features for managing your Terraform workflow, you need to upgrade to the Plus tier to leverage it fully. Even if you are happy with what the Standard tier is offering, many people have already reported they are going to pay more for Terraform Cloud than they are paying their cloud providers for the actual resources. 
The key fear for customers is the inability to predict what their Terraform Cloud bill will look like &#8211; something that creates real difficulties for scaling companies.
On the other hand, Spacelift’s free tier is a powerhouse, packed with many features you won’t find even in Terraform Cloud’s top offering. With Spacelift, you unlock workflows for Kubernetes, CloudFormation, Ansible, and Pulumi too.
Upgrading to our Cloud or Enterprise tier will unlock even more features you can easily leverage to build sophisticated workflows that would be really hard to implement in other products and Spacelift pricing is transparent and predictable, so you can scale safely, knowing you are within your planned budget.

InfraCost - How to Estimate Cloud Costs with Terraform

Spacelift Module Registry - What It is and How to Use It

Infrastructure Problems that Spacelift Solves

How much does Terraform Cloud and Terraform Enterprise cost? See what features are available at different price tiers and learn about a cost-effective alternative.

182-terraform-cloud-pricing

Terraform Cloud Pricing

Terraform Cloud / Enterprise Pricing - Tiers Overview 2023

Learn more about new features, updates, and Spacelift product announcements.

Product Features and Updates | Spacelift Blog

Product

When it comes to changing products, the biggest obstacle is often migration. Yes, the product looks amazing, but once you start thinking about all the work involved migrating from the old one to the new one, you abandon the idea. A seamless migration experience would stop you missing out. Think of how Apple enables painless device upgrades: You simply keep your old phone next to your new one for less than an hour, and everything migrates. 
Terraform Cloud (TFC) recently switched to a RUM (Resources Under Management) pricing model. But this model is unsustainable for many customers, as it will be tough to predict what their bill will look like at the end of the month. You can read more about the changes <a href="https://spacelift.io/blog/terraform-cloud-pricing" target="_blank" rel="noopener">here</a>.
Migrating from Terraform Cloud is easier than enduring their new pricing model, so at Spacelift, we developed a way to speed up the migration process: We call it the <a href="https://github.com/spacelift-io/spacelift-migration-kit" target="_blank" rel="nofollow noopener">Spacelift Migration Kit</a>. 
To migrate from Terraform Cloud and move your workspaces in bulk, take the following steps:
<ol>
<li style="font-weight: 400;" aria-level="1">Clone the <a href="https://github.com/spacelift-io/spacelift-migration-kit" target="_blank" rel="nofollow noopener">Spacelift Migration Kit</a>.</li>
<li style="font-weight: 400;" aria-level="1">Log in to both Spacelift and Terraform Cloud using the `terraform login` command.</li>
<li style="font-weight: 400;" aria-level="1">Modify the exporter.tfc.example.tfvars and make changes to the values related to your Terraform Cloud account. Copy this file to exporters/tfc and rename this file to terraform.tfvars.</li>
<li style="font-weight: 400;" aria-level="1">Run terraform init and terraform apply in the exporters/tfc directory to export the tfc configuration → this will generate an out directory with a file called data.json.</li>
<li style="font-weight: 400;" aria-level="1">Go to the generator directory and run init and apply using the data.json as a variable file.</li>
<li style="font-weight: 400;" aria-level="1">Review and edit (if necessary) the generated code and commit it to a repository.</li>
<li style="font-weight: 400;" aria-level="1">Modify the manager-stack.example.tfvars file to reflect your environment, change its name to terraform.tfvars and copy it to the manager-stack directory (add here the name and the branch of the created repository).</li>
<li style="font-weight: 400;" aria-level="1">Run terraform init and apply. You will get the manager stack in your Spacelift account and once this runs, all of your Terraform Cloud workspaces will be migrated.</li>
</ol>
Let’s cover these steps in detail. 
Cloning the repository is a fairly simple process. Simply go to <a href="https://github.com/spacelift-io/spacelift-migration-kit" target="_blank" rel="noopener">Spacelift Migration Kit</a>, and select either the ssh or http links and run git clone.

You will need to log in to Spacelift from your CLI. This step will be valid for every migration:

Add &#8220;yes&#8221; to the prompt and your browser will open:

spacelift-migration-tool-log-in-to-spacelift

spacelift migration tool log in to spacelift

Make sure you clone the <a href="https://github.com/spacelift-io/spacelift-migration-kit" target="_blank" rel="nofollow noopener">Spacelift Migration Kit</a> GitHub Repository.

To start, you will also need to log in to Terraform Cloud. To do that, you will need to run a similar command to the one we’ve done for Spacelift:

Again, say &#8220;yes&#8221; to the prompt, generate your API token, and you are good to go.

spacelift-migration-tool-api-token

spacelift migration tool api token

<h3>Exporting Terraform Cloud Resources</h3>
Open exporter.tfc.example.tfvars and modify it with values related to your Terraform Cloud account:

After you have completed the changes, you can copy the file to the exporters/tfc directory, and rename it to terraform.tfvars to avoid having to pass the variable file to the Terraform commands that you are going to use.
Go to the exports/tfc directory and run the following commands:

The apply command will generate an out directory containing:
 .
├── data.json
└── state-files
    ├── stack1.tfstate
    └── stackn.tfstate
In the state-files directory, you will have all the state files downloaded for all of your workspaces. In the data.json file, you will have the Terraform Cloud Workspaces information exported as Spacelift Stacks. 
Once they are exported, the state files can be imported into Spacelift or any other backend supported by Terraform. 
<h3>Generate Spacelift Configuration</h3>
When you have done this, go to the generator directory. The generator.tftpl file is the template file that will generate the configuration for the Spacelift Stacks and Environment Variables. You don&#8217;t need to make any changes here, but you have the option to easily customize it to add other parameters to those resources. Just make sure you are building a valid configuration because otherwise, you will receive errors.
To generate the configuration per se, all you have to do is:

This will generate a main.tf file in the out directory, containing information related to the Stacks:
.
├── data.json
├── main.tf
└── state-files
    ├──stack1.tfstate
    └── stackn.tfstate
Mapping resources from a vendor to Spacelift resources is an inherently complex task that does not always produce a precise or definitive outcome. This is primarily due to the presence of certain discrepancies or limitations in the functionality of the resources, as well as potential challenges that may arise during the mapping process. 
In light of this, it is imperative to exercise due diligence with the generated Terraform code to ensure that it aligns with your expectations and requirements. If the code fails to meet these standards, you may need to either attempt the mapping process again with an alternative configuration or make necessary modifications to the Terraform code itself.
After you finish the changes related to Terraform code, you should create a VCS repository containing the main.tf file from the out directory. Your Spacelift account should have access to the VCS provider in which the Terraform Cloud provider repositories were initially created.
<h3>Creating the Stacks</h3>
To create the stacks, you will need to copy the manager-stack.example.tfvars file to the manager-stack directory and rename it terraform.tfvars to avoid having to pass it to the Terraform commands.
You will need to make changes to this file to reflect your Spacelift environment:

If you don’t already have a Spacelift API key, you can go to Settings → API keys and generate one:

spacelift-migration-tool-account-settings

spacelift migration tool account settings

After you click Add Key, a file will be downloaded that contains the API key secret. The API Key ID can be found in the previous screen.
The keys can be passed directly to the tfvars file, which is not recommended, or you can load them from environment variables.
Now that you have completed the changes, all you have to do is go to the manager-stack directory and run the following:

After the apply finishes, you can go to the Spacelift console and see the management stack in action. This stack will be responsible for the lifecycle of all the other stacks that are migrated from Terraform Cloud Workspaces. After this stack finishes running, all of your Terraform Cloud Workspaces will be migrated.
<h3>Post-Migration Cleanup</h3>
Before you can use Spacelift to manage your infrastructure, you may need to make changes to the Terraform code for your infrastructure, depending on how the Terraform state is managed.
If the Terraform state is managed by Spacelift, perform the following actions. Otherwise, you can skip this section:
<ul>
<li style="font-weight: 400;" aria-level="1">Remove any backend/cloud block from the Terraform code that manages your infrastructure to avoid a conflict with Spacelift&#8217;s backend.</li>
<li style="font-weight: 400;" aria-level="1">Delete the import_state_file arguments from the main.tf file in the Terraform code repository you have created.</li>
<li style="font-weight: 400;" aria-level="1">After the manager stack has successfully run, the mounted Terraform state files are not needed anymore and can be deleted by setting the import_state argument to false in the terraform.tfvars file from the manager-stack directory and running terraform apply -auto-approve</li>
</ul>
Starting Fresh
You can delete all the changes that you’ve made by running:

This will help you start a new migration.

<ul>
<li><a href="https://spacelift.io/blog/why-devops-engineers-recommend-spacelift" target="_blank" rel="noopener">Why DevOps Engineers Recommend Spacelift</a></li>
<li><a href="https://spacelift.io/blog/infrastructure-problems-that-spacelift-solves" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Infrastructure Problems that Spacelift Solves&quot;}" data-sheets-userformat="{&quot;2&quot;:4224,&quot;10&quot;:2,&quot;15&quot;:&quot;Arial&quot;}">Infrastructure Problems that Spacelift Solves</a></li>
<li><a href="https://spacelift.io/blog/5-ways-to-manage-terraform-at-scale" target="_blank" rel="noopener">5 Ways to Manage Terraform at Scale</a></li>
</ul>

Right now, this migration kit works only for Terraform Cloud and Terraform Enterprise. 
For Terraform Cloud and Enterprise, the following limitations have been identified:
<ul>
<li style="font-weight: 400;" aria-level="1">The variable sets are not exposed, so they cannot be listed and exported.</li>
<li style="font-weight: 400;" aria-level="1">The name of the Version Control System (VCS) provider for a stack is not returned, so it has to be set in the exporter configuration file.</li>
<li style="font-weight: 400;" aria-level="1">When the branch for the stack is the repository default branch, the value is empty. You can set the value for the default branch in the exporter configuration file or edit the generated Terraform code.</li>
</ul>

This automation makes it easier to migrate from one vendor to Spacelift by getting the existing configuration and state and mapping it to Spacelift resources. We know that Terraform Cloud’s new pricing model is causing problems, so we really wanted to build something that will make it quicker for you to migrate to a product that offers more for less.
To learn more about the advantages of migrating from Terraform Cloud to Spacelift, check out our <a href="https://spacelift.io/terraform-cloud-alternative" target="_blank" rel="noopener">Terraform Cloud alternative page</a>.
This is not a one-size-fits-all solution. You will probably need to tweak it to adapt it to your requirements. Nonetheless, it saves considerable time and makes the overall process leaner.

<span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Spacelift effectively manages Terraform state, more complex workflows, supports policy as code, programmatic configuration, context sharing, drift detection, resource visualization and includes many more features.&quot;}" data-sheets-userformat="{&quot;2&quot;:769,&quot;3&quot;:{&quot;1&quot;:0},&quot;11&quot;:4,&quot;12&quot;:0}">Spacelift effectively manages Terraform state and more complex workflows, and it supports policy as code, programmatic configuration, context sharing, drift detection, and resource visualization, as well as many other features.

How to Build on AWS with CDK for Terraform (CDKTF)

Atlantis vs. Terraform Cloud / Terraform Enterprise - Comparison

If you want to migrate from Terraform Cloud, we are here to help - learn how you can use our Spacelift Migration Kit to speed up the process.

170-migrate-from-terraform-cloud

170.migrate from terraform cloud

How to Migrate From Terraform Cloud to Spacelift

How to integrate the common security tools with Spacelift using the custom inputs

Security is one of Spacelift’s biggest priorities, and apart from the state-of-the-art <a href="https://docs.spacelift.io/product/security.html" target="_blank" rel="noopener">security solutions</a> that are embedded inside the product like <a href="https://docs.spacelift.io/concepts/policy/index.html" target="_blank" rel="noopener">Policy as Code</a>, Encryption,  <a href="https://docs.spacelift.io/integrations/single-sign-on/index.html" target="_blank" rel="noopener">Single Sign On (SSO)</a>, <a href="https://docs.spacelift.io/concepts/worker-pools" target="_blank" rel="noopener">Private Worker Pools</a>, and others, in some organizations, there are tools that engineers were accustomed to and want to have the possibility to integrate them.
When it comes to integrating security tools in your workflows, Spacelift has you covered with the Custom Inputs feature. 
The way this works, in a nutshell, is:
<ul>
<li style="font-weight: 400;" aria-level="1">Install the security tool either directly on the Runner Image or as part of your <a href="https://docs.spacelift.io/concepts/configuration/runtime-configuration/index.html#before_-and-after_-hooks" target="_blank" rel="noopener">before_init</a> hook.</li>
<li style="font-weight: 400;" aria-level="1">Run the security tool as part of a before_init hook or any other hook that makes sense for your use case and save its output to a json file in the &lt;key&gt;.custom.spacelift.json format (case-sensitive, and &lt;key&gt; can be whatever you want).</li>
<li style="font-weight: 400;" aria-level="1">Access the data in a <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy.html" target="_blank" rel="noopener">plan policy</a> under input.third_party_metadata.custom.&lt;key&gt; and manipulate it to accomplish what you want.</li>
</ul>
Only three steps have to be defined in order to accomplish an integration with any tool, so let’s see the most common ones in action:
<ol>
<li><a href="https://spacelift.io/blog/integrating-security-tools-with-spacelift#tfsec-integration">Tfsec</a></li>
<li><a href="https://spacelift.io/blog/integrating-security-tools-with-spacelift#checkov-integration">Checkov</a></li>
<li><a href="https://spacelift.io/blog/integrating-security-tools-with-spacelift#terrascan">Terrascan</a></li>
<li><a href="https://spacelift.io/blog/integrating-security-tools-with-spacelift#checkmarx-kics">Kics</a></li>
</ol>

In this <a href="https://github.com/saturnhead/spacelift-security-integrations" target="_blank" rel="nofollow noopener">repository</a>, there is some dummy Terraform code, that will create two EC2 instances. Due to the fact that it just uses an ami id and an instance type the code will be marked as vulnerable by many security tools we are going to use. 
You can replicate this repository and create a stack based on it in order to follow through with this setup.

terraform-sample-code-danger

terraform sample code danger

<a href="https://github.com/aquasecurity/tfsec" target="_blank" rel="nofollow noopener">Tfsec</a> is an awesome open-source static analysis security scanner for Terraform code. It checks Terraform code for potential security issues and provides clear and actionable feedback to help developers secure their Infrastructure as Code deployments. 
As mentioned above, in order to integrate a tool with Spacelift, we must first install it as part of the runner image or as a before_init hook. 
I am going to show you easy it is to install as part of a before_init hook. 
<h3>Installing and configuring tfsec as a before_init hook</h3>
Navigate in the Spacelift UI to your Stack → Settings → Behavior → Show Advanced Options → Initializations and add the following command before the Initialization Phase

You can drag and drop the commands to place them before the Initialization Phase, and in the end, this should look similar to this.

tfsec

If you are using the GitHub repository from above and you trigger a run, this code will not even pass the before_init phase due to the fact that it’s going to return some High vulnerabilities:

tfsec-github-repository-high-vulnerabilities

tfsec github repository high vulnerabilities

tfsec-github-repository-potential-problems-detected

tfsec github repository potential problems detected

This is not very useful because we are going to be limited to what Tfsec is offering, and maybe some of these high vulnerabilities are not such a big deal for us. The before_init phase is not passing due to the fact that by default, Tfsec will return an exit code different than 0 on a Linux based system, whenever it finds an issue that is High or Critical.
But don’t worry, we will easily overcome this. Let’s go back to the Initializations and change the last command that we are running:

Great, now if we are going to retrigger a run, we are going to see that we arrived at the Initialization Phase:

tfsec-github-repository-retriggered-run

tfsec github repository retriggered run

That’s good, but we want to make sure that we are controlling vulnerabilities through our plan policies. So, as mentioned before, we have to save the json plan in a &lt;key&gt;.custom.spacelift.json file.
Let’s go back to the Initialization Phase and change the tfsec command run as follows:

It should look like this:

tfsec-custom-spacelift-json

tfsec custom spacelift json

<h3>Tfsec plan policy</h3>
Due to the fact that we’ve added tfsec as the value for &lt;key&gt;, this means that we can access the data in our plan policy by using input.third_party_metadata.custom.tfsec.
Let’s see a simple plan policy in action that uses this input:

This policy checks the number of high-severity issues and raises a warning if their number is less than five. Of course, you can create whatever policy you want, this is just a simple example.
In order to create the Policy go to Policies → Add Policy: 
<ul>
<li style="font-weight: 400;" aria-level="1">Add a name to your policy</li>
<li style="font-weight: 400;" aria-level="1">Select Plan Policy</li>
<li style="font-weight: 400;" aria-level="1">Select the Space in which your stack resides</li>
<li style="font-weight: 400;" aria-level="1">Paste the code inside of it</li>
</ul>
After you save, it should look like this:

tfsec-policy

tfsec policy

In order to attach the policy, go back to your Stack → Settings → Policies and select the newly created policy.

attached-policy-tfsec

attached policy tfsec

As we know, we are going to receive four high severity issues for the sample code. This means, that this policy is going to warn us after <code>terraform plan</code> executes.

plan-policy-tfsec

plan policy tfsec

If you want to deny the run if the number of high-severity issues is greater than a threshold, you can simply change the warn from the policy to deny.
And that’s it, you can customize the policies however you want based on the tfsec input.

<a href="https://github.com/bridgecrewio/checkov" target="_blank" rel="nofollow noopener">Checkov</a> is a static code analysis tool that is used to validate Terraform code for security and best practices. It scans Terraform code for potential security issues and recommends changes to improve the security and reliability of the infrastructure.
<h3>Installing and configuring checkov in before_init hook</h3>
As before, go to Stack → Settings → Behavior → Show Advanced Options → Initializations and add the following command before the Initialization Phase.

It should look similar to this:

checkov-initiialization

checkov initiialization

We are using the -s option as we don’t want the command to fail if our code has any vulnerabilities. We want to manipulate these vulnerabilities in our plan policies using custom inputs.
<h3>Checkov plan policy</h3>
We’ve now used checkov as the key for our file, so we will be able to access the result of this run in input.third_party_metadata.custom.checkov.
Let’s define a simple plan policy that counts the number of failed checks:

This policy will give you a warning if your failed checks are less than 10, but will not fail your run. Similarly, as we’ve done for tfsec, you can change warn to deny and change the condition however you please and the run is not going to happen.

checkov-policy

checkov policy

Attach the policy to the stack, and now trigger a run to see it in action.

plan-policy-checkov

plan policy checkov

By having the sample set to true, you can even see what’s going to happen in real time, exactly like you would do in the Rego Playground.

checkov-policy-preview

checkov policy preview

<ul>
<li><a href="https://spacelift.io/blog/spacelift-module-registry" target="_blank" rel="noopener">How to Use Spacelift Module Registry</a></li>
<li><a href="https://spacelift.io/blog/why-devops-engineers-recommend-spacelift" target="_blank" rel="noopener">Why DevOps Engineers Recommend Spacelift</a></li>
<li><a href="https://spacelift.io/blog/prometheus-exporter-for-spacelift" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Monitoring Your Spacelift Account via Prometheus&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Monitoring Your Spacelift Account via Prometheus</a></li>
</ul>

<a href="https://github.com/tenable/terrascan" target="_blank" rel="nofollow noopener">Terrascan</a> is another static code analysis tool that checks for security vulnerabilities.
<h3>Installing and configuring Terrascan in a before_init hook</h3>
As we’ve done for the other tools, go to Stack → Settings → Behavior → Show Advanced Options → Initializations and add the following command before the Initialization Phase:

terrascan-initialization

terrascan initialization

As Terrascan doesn’t have any soft check implemented and the command will return a non 0 exit code, even for the smallest vulnerabilities it finds, we have used the “|| true” option to force a 0 exit code to be able to use output inside a plan policy.
<h3>Terrascan plan Policy</h3>
As we’ve used terrascan as the key for our file, we will be able to manipulate the output from the terrascan run in the plan policy using input.third_party_metadata.custom.terrascan.
Let’s define a plan policy that checks the number of violated policies and shows a warning with the number of them, also, if the number of violated policies is greater than 2, let’s deny the run.

terrascan-policy

terrascan policy

terrascan-trigger-run

terrascan trigger run

You can see the number of violated policies as a warning first and due to the fact that is greater than 2, you will get an error and the run will fail.

<a href="https://github.com/Checkmarx/kics" target="_blank" rel="nofollow noopener">Checkmarx Keeping Infrastructure as Code Secure (KICS)</a>, is in charge of finding vulnerabilities, compliance issues, and infrastructure misconfiguration early in the development cycle. This tool is also open-source, like the others, and it’s getting some traction. 
<h3>Installing and configuring Kics using a runner image</h3>
To spice things up, we will now configure a docker image with Kics and use it as a runner in Spacelift.
Example DockerFile:

You can build the image and push it to one of the supported registries for public runners. A list is available <a href="https://docs.spacelift.io/integrations/docker" target="_blank" rel="noopener">here</a>.
If you don’t want to use your own, the image is already available <a href="https://hub.docker.com/repository/docker/flaviuscdinu93/spacelift_kics/general" target="_blank" rel="nofollow noopener">here</a>.
After you have the image name, you can easily add it to the runner image section on the stack level. To do that, you will need to go to Stack → Settings → Behavior → Runner Image and add the image name here. 
Similar to this:

runner-image

runner image

After that, you are good to go.
We will need to generate a json file in the same way we were doing for the other tools. For that, we will use a before_init hook.

kics-initialization

kics initialization

Now we are ready to define a policy for this.

This policy will give you a warning with all the info, low and medium issues number and deny any run that has a high severity issue. 
It should be similar to this:

kics-policy

kics policy

After this, let’s attach it to our stack and trigger a run to see the policy in action.

kics-trigger-run

kics trigger run

We will see a warning with all the info, low and medium severity issues, and due to the fact that we have two high-severity issues, our run will be denied.

Custom inputs are a very powerful feature that can integrate with any json file. This means that the possibilities of what tools you can integrate into your plan policies is endless. Also, keep in mind that all policies defined inside of this post are just examples. You can create those however you want to accommodate your use case. Using the sample = true option will give you the possibility of seeing all the input that can be passed to your policy, and it makes it easy to write powerful policies.
At Spacelift, we care about your needs, and we understand that sometimes you want to go deep when it comes to security, so having this feature will improve your overall workflow.

<span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;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.&quot;}" data-sheets-userformat="{&quot;2&quot;:769,&quot;3&quot;:{&quot;1&quot;:0},&quot;11&quot;:4,&quot;12&quot;:0}">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.

Open Policy Agent: What Is OPA and How It Works (Examples)

Automated and Manual Code Testing with DevSecOps

See how to integrate common security tools (tfsec, checkov, terrascan and kics) with Spacelift using custom inputs.

Flavius Dinu

Managing Infrastructure as Code (IaC) With Terraform

Get the newsletter

Recent posts

Terraform Cloud/Enterprise Pricing – Tiers Overview 2023

How to Migrate From Terraform Cloud to Spacelift

Integrating Security Tools With Spacelift Using Custom Inputs

Why DevOps Engineers Recommend Spacelift

InfraCost – How to Estimate Cloud Costs with Terraform