An in-depth guide to setting up remote backend

In this comprehensive guide, we will delve into the intricacies of remote state backends and their crucial role in Terraform infrastructure management. We'll cover how to establish a remote backend, the process of migrating state files to a remote backend like an S3 bucket, and explore how Firefly's advanced features enhance the security of your Infrastructure as Code (IaC) state files.

What is a Remote State Backend?

A remote state backend is a centralized location where Terraform can store and manage the state of the infrastructure in a more secure and accessible manner. The state file (terraform.tfstate) contains metadata about the infrastructure managed by Terraform, including configuration details, the current state of resources, and dependencies.

Using a remote backend allows teams to work collaboratively on the same Terraform configuration, helps secure state files, and enables versioning and state locking to prevent conflicts.

There are many platforms (AWS S3, Google Cloud Storage, HashiCorp Consul, etc.) you can configure as a remote backend to store your Terraform state files, but for this blog, we’ll mainly focus on AWS S3.

Configuring S3 as a Remote Backend

S3 stands out as the most popular option among our customers for its straightforward setup, and seamless migration process to the S3 backend. S3 is widely known for its reliability and ease of use, being the recommended backend solution to meet our evolving needs.

That being said, let us take a look at a comprehensive hands-on on how to set S3 as a remote backend.

1. Create the S3 bucket

In the AWS Management Console, create an S3 bucket with a unique name in your preferred region (in our case, production-tfstate-backend-bucket with us-west-1 region).

2. Create the DynamoDB Table

Creating a DynamoDB table is recommended when using an S3 bucket as the backend for Terraform state to enable state locking and consistency.

We have created a table production-tfstate-backend-table. Here we have to ensure that the partition key name is named exactly “LockID”.

According to best practices, it is recommended that you select Read/Write capacity as On-demand (you only pay for the actual read/writes) and Turn on the deletion protection for the table (for prevention of accidental deletion).

With this, we have created our table.

3. Define the Backend

Now, we should define our backend configurations in our Terraform settings.tf file. You should specify the bucket name, the key attribute (location for creating the state file in the bucket, and DynamoDB table name)

We then have to run the terraform init command to initialize our S3 backend.

We are done initialization of our backend. Now, let’s create a simple EC2 instance in our Terraform configuration.

After defining our EC2, we run terraform plan and terraform apply -auto-approve to create the infrastructure. We can see that our EC2 New-backend-instance has just been created.

We can see our state file, too was created in a directory called state/, just like the key attribute we defined (state/terraform.tfstate) 

Migrate to S3 Backend

If the necessity arises to transition from a local backend or another remote backend to the AWS S3 remote backend due to unexpected circumstances, Terraform is adept at managing such migrations smoothly. Therefore, the migration procedure remains constant, whether the migration is from a local backend to S3 or from a different remote backend to S3.

Migrating your Terraform state to an S3 remote backend involves a few steps to ensure a smooth transition. 

1. Local Backend

If it is a local backend, you need to follow the steps to create an S3 backend, as discussed above. 

2. Different Remote Backend

If you’re migrating from a different remote backend (like Terraform Cloud, Google Cloud Storage, etc.) to S3, you have to initially create an S3 bucket and a DynamoDB table and then just replace the previous backend configuration with the new S3 backend configuration.

For example,

Make sure to replace the placeholder values (firefly-state-bucket, state/terraform.tfstate, us-east-1, firefly-lock-table) with the actual names and region of your S3 bucket and DynamoDB table.

Then run terraform init to initialize the new S3 backend.

Terraform will detect the change in the backend configuration and prompt you to migrate your existing state to the new S3 backend. Confirm the action when prompted. Terraform will handle the migration of your state file to the specified S3 bucket.

Integrate your Remote Backend with Firefly

Firefly automatically and continually support integration with IaC remote stacks from popular platforms like Terraform Cloud and Google Cloud Storage.

Let's explore the practical steps to seamlessly integrate Terraform Cloud and Google Cloud Storage (GCS) with Firefly.

1. Terraform Cloud

• Login to your Terraform Cloud account and go to Settings > Tokens, and create an API token.

• Give a token name and click on Generate token

• Go to Firefly, and select Settings > Integrations > Add new.

• Scroll down and under the IaC Remote State, select Terraform Cloud.

• Enter a Nickname and paste the API token you created from Terraform Cloud. Click Next, and you have completed the integration.

2. Google Cloud Storage

• Login to your Google Cloud account and select IAC and Admin > Service Accounts

• Select Create a Service Account and enter the Service Account details.

• Give the scope of Storage Object Viewer to this Service Account. Then click on Save > Done.

• Under the hamburger menu, select Manage keys > Create a new key. Select the key type as JSON. The service account key will be created and saved as a JSON file on your local system.

• Go to Firefly, select Settings > Integrations > Add New. Under the IaC Backend section, select Google Cloud Storage.

• Enter the Nickname, your Google Cloud Project ID, and the upload Service Account key (JSON file). Select Next, and your integration is complete.

Security Best Practices for Remote Backend

Here are some best practices engineers should keep in mind to consider when configuring and using Terraform with an S3 backend:

1. Enable Bucket Versioning

Versioning in AWS S3 buckets enables the preservation of a historical log for all changes made to files within the bucket. This capability facilitates easier recovery of the state file in case of a disaster or file corruption, as prior versions are readily accessible.

For instance, if an accidental deletion of a Terraform state file occurs, versioning allows for the retrieval of the last known good state. By simply navigating to the S3 console, you can select the desired previous version of the file and restore it. This reverts the deletion, mitigating potential disruptions to your infrastructure.

2. Use State Locking

Terraform supports state locking with the S3 backend by integrating with AWS DynamoDB. State locking prevents concurrent operations that could lead to state corruption.

For instance, whenever an infrastructure engineer initiates operations involving state files (such as plan, apply, or destroy), Terraform secures the file by modifying the LockID column in the specified DynamoDB table to initiate a lock.

Therefore, DynamoDB plays a crucial role in preventing race conditions.

3. Implement Fine-grained Access Control

Use AWS Identity and Access Management (IAM) policies to control access to the S3 bucket and DynamoDB table. Ensure that only authorized users and systems have the necessary permissions to read, write, and delete state files or access the locking mechanism.

For example, you can create an IAM policy that grants specific permissions (s3:ListBucket, s3:GetObject, s3:PutObject for S3; dynamodb:GetItem, dynamodb:PutItem for DynamoDB) to a user or role. Attach this policy to the users that manage your Terraform infrastructure. This setup restricts operations on the S3 bucket and DynamoDB table to only those entities with authorized access.

4. Encrypt your State files

Enable server-side encryption (SSE) for your S3 bucket to protect your state files at rest. You can use S3-managed keys (SSE-S3), AWS Key Management Service (KMS) keys (SSE-KMS), or a customer-provided encryption key (SSE-C). Using SSE-KMS provides additional benefits like key rotation and audit trails.

5. Monitor and Audit Access

Enable AWS CloudTrail logging for your S3 buckets and DynamoDB tables to monitor access and operations performed on your Terraform state files. Regular auditing helps in identifying unauthorized access or unintended operations that could affect your infrastructure.

You could do this by:

• Configuring CloudTrail to log S3 bucket and DynamoDB table activities
• Setting up alarms or notifications based on specific CloudTrail log events to immediately detect unusual or unauthorized activities.
• Perform periodic audits of the CloudTrail logs to ensure compliance.

Backup Mechanism of Remote State

When you run a Terraform operation that modifies the state(plan apply, destroy), Terraform automatically creates a backup of the current state file called terraform.tfstate.backup before applying any changes. The terraform.tfstate.backup file resides in the same location as the terraform.tfstate file, and is updated with each modification Terraform applies to the state file.

Here's how the backup mechanism supports handling future configuration changes:

• Pre-Operation Save: Before modifying operations, Terraform saves the current terraform state as a .backup file, ensuring a recovery point is available.
• Execute Changes: Terraform applies your configuration changes to the infrastructure, updating resources as defined.
• Update State File: Post-change, Terraform updates the tfstate to map the new infrastructure state, capturing all changes.
• Maintain Backup: The .backup file acts as a pre-change snapshot, ready for recovery if the updated terraform.tfstate is compromised.
• Future Operations: Terraform repeats this backup process with each infrastructure modification, ensuring a recent backup is always at hand.