DevSecOps in Practice

Security Best Practices

Manage Secrets Securely

Never commit sensitive data (passwords, keys, etc.) in Terraform files or state. Instead, use environment variables, encrypted files, or external secret stores to supply secrets at runtime. For example, reference cloud credentials via TF_VAR_... environment variables or store secrets in HashiCorp Vault or cloud secret managers (AWS Secrets Manager, etc.) and fetch them dynamically in Terraform.

Terraform variable definition files (.tfvars) often contain environment-specific values and sometimes secrets (though ideally, secrets should be managed separately). Do not commit files with sensitive values (like terraform.tfvars containing real secrets) into a public or shared repository. If .tfvars must be shared, do so securely:

• Encrypt .tfvars files using tools like Mozilla SOPS or git-crypt. They can be safely stored in Git and can only be decrypted by authorized team members. While this is not a recommended practice, it is still better than using and sharing plain text.
• Use a secret store instead of hardcoding values in files. Store sensitive variables in a secret management system (e.g., Vault, AWS Secrets Manager, Azure Key Vault), and retrieve them dynamically during Terraform execution. Pipelines or Terraform Cloud workspaces can inject these variables at runtime.
• Provide example templates instead of real secrets. Instead of committing actual .tfvars files, add a terraform.tfvars.example file containing placeholders. Each user or pipeline can then supply the actual values out-of-band.
• Ensure your .gitignore excludes .tfvars files to prevent accidental commits of sensitive data.

The goal of these practices is to prevent the leakage of sensitive information while still enabling secure collaboration on Terraform configurations across environments.

Implement Role-Based Access Control (RBAC) and Least Privilege

Follow the principle of least privilege by restricting who can do what in Terraform. Define roles with specific permissions and assign team members appropriately. For example, create read-only roles for plan reviewers and limited roles that can apply changes to certain environments. If using Terraform Cloud or Enterprise, leverage its RBAC features to control access to workspaces and state. On cloud providers, use IAM roles that only allow Terraform to perform necessary actions (no extra privileges). Most modern cloud platforms support fine-grained permissions, so take advantage of them.

This is a basic example of how to divide roles:

The more granular you can make these roles, the better. This way, you will minimize the risk of unauthorized changes.

Also, consider Terraform workspaces or separate state files per environment to segregate access—actions in dev shouldn’t impact prod.

Use Secure Remote State Storage and Locking

Store Terraform state in a remote backend with encryption and locking, rather than local disks. State files often contain sensitive info (resource IDs, maybe secrets), so keep them in secure storage (e.g., AWS S3, Azure Storage, Terraform Cloud) with encryption at rest. Enable state locking to prevent concurrent runs from corrupting state (for instance, Terraform remote backends like S3 can use a DynamoDB table for locking to avoid race conditions).

Remote backends also support versioning and backups – e.g. enable S3 bucket versioning to recover state if needed. Treat state as sensitive: restrict access to it (only Terraform or the pipeline should read/write state) and never check state files into Git. Secure state management protects your infrastructure’s "source of truth" from unauthorized access or edits.

Managed services like Spacelift, env0, or Scalr act as Terraform automation platforms and provide remote state backends, role-based access, policy enforcement, and a user-friendly interface for teams. These can be seen as alternatives or complements to Terraform Cloud, often integrating with your Git repositories and CI/CD pipelines.

They usually include features like drift detection, notifications, and granular permissions on who can trigger plans or applies. As organizations grow, such platforms help scale Terraform usage safely by adding security controls like mandatory approvals for production applies or scheduled compliance checks. If you need collaboration beyond Terraform’s CLI and VCS, these platforms standardize how teams share and manage Terraform workflows, with built-in security features like encrypted state storage and IAM integrations.

Mitigate Drift and Enforce Compliance

Prevent infrastructure drift by making all changes through Terraform and CI/CD pipelines (no out-of-band manual fixes). Adopt a GitOps workflow where any change to infrastructure is done via code and merge requests, never by ad-hoc console clicks. This guarantees that the code and real infrastructure don’t diverge.

Use policy-as-code to enforce compliance – for example, HashiCorp Sentinel or Open Policy Agent (OPA) can check Terraform plans against security rules before applying (e.g. require encryption on S3 buckets). Integrate these checks into your pipeline so that non-compliant changes are flagged early. Additionally, run regular terraform plan (or use drift detection tools) in a read-only mode to detect drift if someone makes manual changes – then correct it via Terraform.

Here is an example of how to write a Sentinel policy to guard against using open security groups on AWS (allowing all traffic). More examples are available in the Sentinel policy library.

// Sentinel policy to prevent open security groups in AWS
import "tfplan/v2" as tfplan

security_groups