⇠ Back to the blog
Cover for Cased Study: Working with Terraform in production

Cased Study: Working with Terraform in production

Christian Nguyen avatarWritten by Christian Nguyen


With over 100 million downloads and 1200 enterprise customers, Terraform is known as the lingua franca of cloud infrastructure automation. Terraform is a multi-faceted tool that allows organizations to adopt, build, standardize and innovate through infrastructure as code. Whether you're trying to automate the provisioning of your cloud infrastructure, manage Kubernetes clusters, integrate with existing workflows, or even adopt a multi-cloud environment, Terraform is the industry standard tool to use.

For such a powerful tool, having the ability to provision and destroy infrastructure with just one line of code in production, there needs to be certain security and compliance workflows in place to make sure you can reap the full benefits Terraform provides. You need the ability to do code review in production.

Cased Shell's groups and permissions, inline approvals, and audit logs help reduce mistakes and errors caused by oversight so that you can run Terraform in production confidently.

Terraform setup with Cased

It's straight-forward to get Terraform production-ready with Cased's engineering enablement platform. For this example, we'll be assuming that all of your hosts and containers are already set up with host and container auto-detection. First, you'll want to control access to the specific prompts and containers with groups and permissions. This is achieved by writing simple JSON policies in the Settings tab. These policies can be written at the user or group level, with priority being given to the user-level.

From there, you'll want to add Terraform as a CLI tool to your environment. This takes less than five minutes. Head over to the Cased dashboard, press "Set up local CLI program", click on the picture of Terraform, add a description, and click "Create". Once created, it will take you to the Terraform settings page where you can enable approval workflows. You will be able to configure additional settings such as setting up peer approvals in Slack, and advanced approvals settings and privileges. Advanced approvals settings include - allowing automatic approval while an engineer is on-call, certain commands being auto-approved, session duration and more.

And finally to get audit trails for Terraform, you don't need to set up anything. All activity in Cased is recorded in SOC 2 and HIPAA compliant audit trails.

Workflow with Cased

Let's say for your organization, your DevOps team is the one responsible for all things Terraform. You've followed the setup to get Terraform production ready in Cased and you're now ready to do your job. The task you're assigned with is creating a new EC2 instance for an application, and then deleting the old EC2 instance it used to run on.

Simple enough. You start off by creating the relevant terraform file in your local IDE. From there, you go to the Cased Dashboard and access the corresponding AWS environment with Cased's one-click access. Once in, you navigate to the right section and make a directory to drag and drop the main.tf file to add it to the environment. From there you terraform init and add the reason why you're running the command. The senior engineer approves it. You terraform fmt and terraform validate just to make sure everything is working and it does. These require no approvals as your team set that up earlier when getting Terraform production ready.

You then terraform apply and get it reviewed and approved by your supervisor.

Now before deleting your server, your manager has some updates for you.

Due to the app gaining more and more traffic, the EC2 instance needs to have autoscaling.

You vim into your main.tf file and add the required material: a load balancer, dynamic load balancing, and a relevant security group.

terraform init, and then terraform apply to see the changes (with approvals by your senior employees of course).

Now that the new instance is up and running you can now delete the old server.

You cd back into the directory where both the old and current server are and type terraform destroy. This new command requires Cased's inline approvals before being able to run. You get denied approval to run this with a Slack message noting that you need to specify a resource to destroy. You then realize you would've just destroyed the instance you made. You then run terraform destroy --resource , get approved, and your task is finally finished.

Cased's inline approvals, and one-click access to your prompts and containers makes using Terraform in production faster and safer. A simple review process for another set of eyes, allows your team to have code review in production. Increase uptime by catching simple mistakes with Cased's inline approvals.

If you're interested and want to learn more schedule a demo or visit our documentation.