IaC Security: Securing Your Terraform and OpenTofu Infrastructure

TL;DR

• Shift-left scanning is non-negotiable. Run Checkov, Snyk, or other vulnerability scanners on every PR — 63% of cloud incidents come from misconfiguration, and most of those are catchable in code.
• Treat state files like secrets. Encrypt at rest (KMS, customer-managed keys), restrict IAM access tightly, and never commit them. State leaks are the worst-case Terraform breach.
• Use dynamic, short-lived credentials. OIDC for CI/CD, IAM roles with assume-role chains, and identity-provider integrations beat long-lived access keys every time. Pair with least-privilege IAM.
• Enforce policy at apply time. Layer static analysis with runtime Policy as Code (OPA, Sentinel) so violations can't deploy even if they pass review.
• Audit everything. Plan output, apply logs, who-ran-what — see Terraform audit logs for the patterns that survive a compliance review.

Introduction: The IaC Security Imperative

Infrastructure as Code (IaC) has become central to modern cloud operations, with Terraform and OpenTofu leading the charge in defining and provisioning cloud infrastructure. However, as IaC defines your infrastructure, securing that code becomes paramount. Recent security research indicates that 63% of cloud security incidents stem from misconfigurations rather than sophisticated attacks, making the choice of security tooling and practices a critical decision.

This comprehensive pillar article synthesizes best practices, threat models, tools, and implementation strategies for securing Terraform and OpenTofu deployments. Whether managing AWS, Azure, Google Cloud, or multi-cloud environments, this guide provides the knowledge needed to embed security throughout your IaC lifecycle.

Section 1: The IaC Security Landscape

Understanding the Shift-Left Security Model

Modern IaC security operates on the principle of "shift-left"—catching issues as early as possible in the development lifecycle rather than discovering them in production. This requires a multi-layered approach that addresses security at multiple stages:

Development Time: Developers identify and prevent security issues in their IDEs before code commits.

Pre-Deployment: Automated scanning in CI/CD pipelines catches misconfigurations before infrastructure changes are applied.

Runtime: Continuous monitoring and compliance validation ensure deployed infrastructure remains secure and drift-free.

Operational: Policy enforcement and compliance reporting maintain security standards across environments.

The Static vs. Dynamic Analysis Dichotomy

Two primary methods exist for IaC security analysis:

Static Analysis (SAST) examines your HCL code before deployment:

• Advantages: Early detection, faster fixes, lower remediation costs, covers entire codebase
• Limitations: May produce false positives, lacks runtime context, cannot detect issues from live environment interactions
• Tools: Checkov, tfsec, KICS, Snyk

Dynamic Analysis & Runtime Validation (DAST/CSPM) assesses infrastructure after deployment:

• Advantages: Validates actual security state, detects configuration drift, verifies real-world compliance
• Limitations: Issues found later, remediation more complex, challenges correlating findings to IaC code
• Tools: Cloud Security Posture Management (CSPM) solutions, AWS Security Hub, native cloud provider tools

Best Practice: These methods are complementary, not mutually exclusive. SAST acts as preventative control, while runtime validation ensures ongoing security and detects unauthorized changes.

Section 2: Threat Models for Terraform and OpenTofu

Common Threat Vectors

Understanding the threats your IaC faces is essential for designing effective controls:

Misconfiguration Exposure

• Missing encryption configurations on storage resources
• Overly permissive IAM policies granting excessive access
• Public access enabled on sensitive resources
• Inadequate network segmentation

Secrets Exposure

• Sensitive values (API keys, passwords, tokens) hardcoded in HCL
• Secrets persisted in Terraform state files
• Credentials visible in plan output or CI/CD logs
• Secrets transmitted over unencrypted channels

State File Compromise

• Unauthorized access to state file backends
• State files with plaintext sensitive data stored in Git
• State files lacking encryption at rest or in transit
• Inadequate access controls on state file storage

Supply Chain Attacks

• Malicious modules from untrusted registries
• Compromised providers containing backdoors
• Unsafe plugin execution without verification
• Dependency vulnerabilities in provider code

Access Control Weaknesses

• Insufficient RBAC for IaC operations
• Lack of approval workflows before infrastructure changes
• Missing audit trails for who made what changes
• Excessive permissions for CI/CD service accounts

Drift and Compliance Violations

• Configuration drift from intended IaC definitions
• Unauthorized manual changes to infrastructure
• Inability to detect non-compliant resource configurations
• Missing enforcement of organizational security standards

Section 3: State File Security

The Critical Importance of Terraform State

Terraform state files represent the source of truth for your infrastructure. Compromising a state file compromises your entire infrastructure, making state security non-negotiable.

State File Security Best Practices

1. Enable Encryption at Rest

# Using AWS S3 for state backend with encryption
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

2. Enable Encryption in Transit

# Force HTTPS for all communication
terraform {
  backend "s3" {
    bucket                         = "my-terraform-state"
    key                            = "prod/terraform.tfstate"
    region                         = "us-east-1"
    encrypt                        = true
    dynamodb_table                 = "terraform-locks"
    skip_credentials_validation    = false
    skip_metadata_api_check        = false
    skip_requesting_account_id     = false
  }
}

3. Implement State Locking

# Use DynamoDB for distributed state locking
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

State locking prevents concurrent operations from corrupting state and is essential in team environments.

4. Restrict Access to State Storage

# AWS S3 bucket policy for state file access
resource "aws_s3_bucket_policy" "terraform_state" {
  bucket = aws_s3_bucket.terraform_state.id
 
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Deny"
        Principal = "*"
        Action = "s3:*"
        Resource = [
          aws_s3_bucket.terraform_state.arn,
          "${aws_s3_bucket.terraform_state.arn}/*"
        ]
        Condition = {
          Bool = {
            "aws:SecureTransport" = "false"
          }
        }
      }
    ]
  })
}

5. Enable Versioning and MFA Delete

# Enable S3 versioning and MFA delete protection
resource "aws_s3_bucket_versioning" "terraform_state" {
  bucket = aws_s3_bucket.terraform_state.id
 
  versioning_configuration {
    status     = "Enabled"
    mfa_delete = "Enabled"
  }
}

6. Never Store State in Git

Always use remote backends (S3, Azure Storage, Terraform Cloud) rather than committing state files to version control. Add to .gitignore:

terraform.tfstate
terraform.tfstate.*
.terraform/

7. Audit State Access

# Enable CloudTrail logging for state access
resource "aws_s3_bucket_logging" "terraform_state" {
  bucket = aws_s3_bucket.terraform_state.id
 
  target_bucket = aws_s3_bucket.log_bucket.id
  target_prefix = "terraform-state-logs/"
}

Section 4: Secret Management and Ephemerality in Terraform

The Challenge of Sensitive Data in IaC

Terraform must handle sensitive information—database passwords, API keys, OAuth tokens—during infrastructure provisioning. Traditionally, this created a security dilemma: sensitive values either needed to be stored in state files or managed through insecure workarounds.

Ephemeral Values: A Security Breakthrough

Introduced in Terraform v1.10 (November 2024), ephemeral resources solve this critical challenge by ensuring sensitive information exists only during execution and is never persisted in state or plan files.

Core Principles of Ephemerality:

• Temporary existence: Values exist only during current Terraform operation
• Non-persistence guarantee: Never written to state files or plan artifacts
• Security by design: Addresses the longstanding sensitive data management challenge
• Runtime-only visibility: Values accessible only during execution in specific contexts

Ephemeral Blocks: Syntax and Functionality

ephemeral "<resource_type>" "<resource_name>" {
  <attributes>
  <meta-arguments>
}

Ephemeral resources participate in Terraform's dependency graph but with unique lifecycle:

1. Opening: Terraform "opens" the resource by executing its logic to fetch or generate data
2. Renewing: For ephemeral resources that may expire during operation (like temporary tokens), Terraform can periodically renew them
3. Closing: Once no longer needed, Terraform explicitly "closes" the resource, allowing proper cleanup

Write-Only Arguments

Terraform v1.11 introduced write-only arguments that allow ephemeral values to be used in regular resource blocks while maintaining security:

resource "aws_db_instance" "example" {
  instance_class      = "db.t3.micro"
  allocated_storage   = "5"
  engine              = "postgres"
  username            = "example"
  skip_final_snapshot = true
 
  # Write-only password argument (never persisted in state)
  password_wo         = ephemeral.random_password.db_password.result
  password_wo_version = 1
}

Write-only arguments follow a naming convention with the _wo suffix and include a versioning mechanism for controlled updates.

Practical Example: Secure Database Password Management

# Generate ephemeral random password
ephemeral "random_password" "db_password" {
  length            = 16
  override_special  = "!#$%&*()-_=+[]{}<>:?"
}
 
# Store the password in AWS Secrets Manager
resource "aws_secretsmanager_secret" "db_password" {
  name = "db_password"
}
 
# Set the secret value using write-only argument
resource "aws_secretsmanager_secret_version" "db_password" {
  secret_id              = aws_secretsmanager_secret.db_password.id
  secret_string_wo       = ephemeral.random_password.db_password.result
  secret_string_wo_version = 1
}
 
# Retrieve the password from Secrets Manager (ephemeral)
ephemeral "aws_secretsmanager_secret_version" "db_password" {
  secret_id = aws_secretsmanager_secret_version.db_password.secret_id
}
 
# Use the password to configure the database
resource "aws_db_instance" "example" {
  instance_class      = "db.t3.micro"
  allocated_storage   = "5"
  engine              = "postgres"
  username            = "example"
  skip_final_snapshot = true
 
  # Use the ephemeral password (write-only argument)
  password_wo         = ephemeral.aws_secretsmanager_secret_version.db_password.secret_string
  password_wo_version = 1
}

Best Practices for Secret Management

1. Use ephemeral resources for sensitive values that should never be persisted
2. Integrate with secret managers (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault)
3. Enable secret rotation by managing versions of write-only arguments
4. Never hardcode secrets in HCL or environment variables
5. Use temporary credentials wherever possible instead of long-lived static credentials
6. Implement least-privilege access to secrets based on workload requirements

Section 5: Provider Authentication and Dynamic Credentials

Moving Beyond Long-Lived Static Credentials

The security landscape increasingly favors short-lived, dynamically generated credentials over static API keys and secrets. OpenID Connect (OIDC) enables workload identities to obtain temporary credentials without managing long-lived secrets.

OIDC for Cloud Provider Authentication

AWS OIDC Integration:

# Configure AWS provider with OIDC
provider "aws" {
  assume_role_with_web_identity {
    role_arn            = aws_iam_role.terraform_role.arn
    web_identity_token  = var.oidc_token
    duration_seconds    = 3600
  }
}
 
resource "aws_iam_role" "terraform_role" {
  name = "terraform-oidc-role"
 
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Principal = {
          Federated = "arn:aws:iam::ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com"
        }
        Action = "sts:AssumeRoleWithWebIdentity"
        Condition = {
          StringEquals = {
            "token.actions.githubusercontent.com:aud" = "sts.amazonaws.com"
          }
        }
      }
    ]
  })
}

Azure OIDC Integration:

provider "azurerm" {
  features {}
  use_oidc = true
}

Google Cloud OIDC Integration:

provider "google" {
  project = var.gcp_project
 
  # OIDC configuration handled automatically
  # when running in a workload identity context
}

Scalr and OIDC Integration

Scalr provides built-in support for OIDC-based cloud authentication, eliminating the need to manage long-lived credentials:

# Scalr automatically handles OIDC token exchange
# within its Terraform runs, providing ephemeral
# credentials to cloud providers without requiring
# static API keys or secrets

Provider Configurations in Scalr

Scalr's Provider Configurations feature enables secure centralized management of cloud credentials:

# Provider configuration stored securely in Scalr
# and automatically injected into Terraform runs
resource "scalr_provider_configuration" "aws_prod" {
  account_id    = var.account_id
  name          = "aws-production"
  provider_name = "aws"
 
  # Credentials managed securely by Scalr
  # with OIDC-based authentication
}

Security Benefits of OIDC

• No static credentials stored or transmitted
• Automatic credential rotation with short-lived tokens
• Auditability of which workload obtained credentials and when
• Revocability through identity provider configuration
• Integration with CI/CD pipeline identity management

Section 6: Static Analysis Tools for IaC Security

Checkov: Comprehensive IaC Scanning

Checkov is one of the most widely adopted static analysis tools for Terraform and OpenTofu, offering graph-based scanning for higher accuracy and fewer false positives. For setup walkthroughs, see our guide on using Checkov with Terraform and the broader landscape of Terraform vulnerability scanning.

Key Capabilities:

• Scans HCL code, JSON, and Terraform plan files
• Supports Terraform, OpenTofu, CloudFormation, and other IaC frameworks
• Provides 1000+ built-in policies covering security and compliance
• Supports custom policies using Python
• Integrates with CI/CD pipelines, IDEs, and VCS providers
• Detects configuration drift by analyzing terraform plan output

Integration in CI/CD:

# GitHub Actions example
name: IaC Security Scan
on: [pull_request]
 
jobs:
  checkov:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run Checkov
        uses: bridgecrewio/checkov-action@master
        with:
          directory: .
          framework: terraform
          quiet: false
          soft_fail: false
          compact: false

tfsec: Fast Terraform Security Scanning

tfsec is a Terraform-specific scanner written in Go, optimized for speed while maintaining comprehensive coverage.

Key Capabilities:

• Fast scanning of large Terraform codebases
• Cloud-agnostic checks for Terraform security best practices
• Supports custom checks with plugin system
• Minimal false positives through precise rule definitions
• IDE integration for immediate developer feedback

Configuration Example:

# .tfsec/config.json
{
  "checks": {
    "aws-s3-enable-bucket-encryption": "error",
    "aws-s3-block-public-access": "error",
    "aws-iam-require-mfa": "error"
  }
}

KICS: Infrastructure as Code Security

KICS (Keeping Infrastructure as Code Secure) offers support for multiple IaC frameworks and cloud platforms.

Supported Formats:

• Terraform / OpenTofu
• CloudFormation
• Kubernetes
• Docker
• Ansible
• And 20+ additional frameworks

Snyk: Developer-Centric Security

Snyk provides a developer-first approach to IaC security with strong IDE integration and actionable remediation guidance.

Key Features:

• Real-time scanning in development IDEs
• Detailed remediation suggestions with code examples
• Integration with GitHub, GitLab, Azure DevOps
• Support for both code and supply chain vulnerabilities
• Automatic pull request creation for fixes

Making an Informed Choice

When selecting IaC security tools, consider:

1. OpenTofu Support: Tools must understand OpenTofu's independent features including check blocks, client-side state encryption, and .tofu file discovery
2. Accuracy: Graph-based scanning provides higher fidelity than simple HCL parsing
3. Integration: Seamless CI/CD and IDE integration enables shift-left security
4. Plan File Scanning: Analyzing terraform/tofu plan JSON output provides higher-fidelity pre-deployment checks
5. Policy Management: Ability to use pre-built and custom policies tailored to organizational needs
6. Performance: Scanning speed matters for large codebases and frequent CI/CD runs

Section 7: DevSecOps Practices for IaC

The DevSecOps Paradigm

DevSecOps integrates security throughout the software development lifecycle. Key principles include:

Shift Left (and Everywhere): Address security concerns as early as possible while maintaining vigilance throughout the entire lifecycle.

Holistic Automation: Automate security checks, tests, policy enforcement, and remediation to match modern development velocity.

Continuous Security Testing: Employ multiple testing techniques (SAST, DAST, SCA, infrastructure scanning) continuously.

Collaborative Culture: Break down silos between development, security, and operations teams.

Security as Code: Define security policies and controls as code for consistency and auditability.

IaC in the DevSecOps Toolchain

Infrastructure as Code occupies a critical position in DevSecOps, forming the foundation upon which applications and security controls run.

SAST for Application Code scans application source code for vulnerabilities.

SCA (Software Composition Analysis) identifies vulnerabilities and license issues in open-source dependencies.

IaC Security Scanning identifies misconfigurations in Terraform, CloudFormation, and other infrastructure definitions—a layer often overlooked.

DAST tests running applications for vulnerabilities.

CSPM (Cloud Security Posture Management) continuously monitors deployed resources for drift and non-compliance.

Complete DevSecOps Tool Strategy

A robust DevSecOps strategy leverages diverse tooling across multiple categories:

Section 8: AWS Security Best Practices with Terraform

The AWS Shared Responsibility Model

AWS secures the infrastructure (physical security, hypervisor, host OS, network infrastructure), while customers are responsible for securing what they deploy (service configuration, customer data, identity & access management, network controls, operating system, application security).

Critical AWS Security Risks

Misconfiguration remains the most common vulnerability, accounting for 63% of AWS security incidents.

IAM Issues represent the second most critical risk area, contributing to 47% of successful breaches. See our practical guide on streamlining AWS IAM role creation with Terraform for least-privilege patterns.

Data Exfiltration from improperly configured S3 buckets remains a persistent threat.

Supply Chain Attacks through compromised CI/CD pipelines increased 73% year-over-year.

AWS Security Best Practices in Terraform

1. Identity and Access Management

# Implement least-privilege IAM policies
resource "aws_iam_policy" "limited_s3_access" {
  name = "s3-read-only"
 
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = [
          "s3:GetObject",
          "s3:ListBucket"
        ]
        Resource = [
          aws_s3_bucket.app_data.arn,
          "${aws_s3_bucket.app_data.arn}/*"
        ]
      }
    ]
  })
}
 
# Use temporary credentials instead of long-term access keys
resource "aws_iam_role" "app_role" {
  name               = "app-execution-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Principal = {
          Service = "ec2.amazonaws.com"
        }
        Action = "sts:AssumeRole"
      }
    ]
  })
}

2. Data Protection

# Encrypt S3 buckets with KMS
resource "aws_kms_key" "s3_encryption_key" {
  description             = "KMS key for S3 bucket encryption"
  deletion_window_in_days = 10
  enable_key_rotation     = true
}
 
resource "aws_s3_bucket_server_side_encryption_configuration" "secure_bucket" {
  bucket = aws_s3_bucket.app_data.id
 
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.s3_encryption_key.arn
    }
  }
}
 
# Block public access
resource "aws_s3_bucket_public_access_block" "app_data" {
  bucket = aws_s3_bucket.app_data.id
 
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

3. Network Security

# Implement VPC Flow Logs
resource "aws_flow_log" "main" {
  log_destination      = aws_s3_bucket.flow_logs.arn
  log_destination_type = "s3"
  traffic_type         = "ALL"
  vpc_id               = aws_vpc.main.id
  log_format           = "${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol}"
}
 
# Create security groups with minimal access
resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Allow TLS inbound traffic"
  vpc_id      = aws_vpc.main.id
 
  ingress {
    description = "TLS from anywhere"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
 
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}
 
# Use VPC endpoints for service connections
resource "aws_vpc_endpoint" "s3" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.us-east-1.s3"
  vpc_endpoint_type = "Gateway"
}

4. Continuous Monitoring and Response

# Configure CloudTrail for audit logging
resource "aws_cloudtrail" "main" {
  name                          = "main-trail"
  s3_bucket_name                = aws_s3_bucket.cloudtrail_logs.id
  include_global_service_events = true
  is_multi_region_trail         = true
  enable_log_file_validation    = true
  kms_key_id                    = aws_kms_key.cloudtrail.arn
 
  event_selector {
    read_write_type           = "All"
    include_management_events = true
 
    data_resource {
      type   = "AWS::S3::Object"
      values = ["arn:aws:s3:::"]
    }
  }
}
 
# Enable GuardDuty for threat detection
resource "aws_guardduty_detector" "main" {
  enable            = true
  finding_publishing_frequency = "FIFTEEN_MINUTES"
}

Section 9: Security in CI/CD Pipelines

Integrating IaC Security Scanning

Modern CI/CD pipelines should include automated security scanning at multiple stages:

Pre-Commit Hooks: Prevent secrets and misconfigurations from entering the repository.

Build Stage: Run comprehensive static analysis on all IaC code.

Plan Stage: Analyze terraform/tofu plan output for security issues.

Policy Evaluation: Enforce organizational security policies before deployment.

Post-Deployment Validation: Verify deployed resources match intended configuration.

Example CI/CD Pipeline with Security

# GitHub Actions workflow
name: Terraform Security Pipeline
 
on:
  pull_request:
    paths:
      - 'terraform/**'
  push:
    branches:
      - main
 
jobs:
  terraform_validation:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
 
      - name: Terraform Format Check
        run: terraform fmt -check -recursive terraform/
 
      - name: Terraform Validate
        run: terraform -chdir=terraform/prod validate
 
      - name: Run Checkov
        uses: bridgecrewio/checkov-action@master
        with:
          directory: terraform/
          framework: terraform
          quiet: false
 
      - name: Run tfsec
        uses: aquasecurity/[email protected]
        with:
          working_directory: terraform/
 
      - name: Terraform Plan
        run: terraform -chdir=terraform/prod plan -json -out=tfplan.json
 
      - name: Analyze Plan with Snyk
        run: |
          npm install -g snyk
          snyk iac test tfplan.json --json-file-output=snyk-results.json
 
      - name: Upload SARIF Results
        uses: github/codeql-action/upload-sarif@v2
        if: always()
        with:
          sarif_file: snyk-results.sarif
 
  terraform_apply:
    needs: terraform_validation
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
 
      - name: Terraform Apply
        run: |
          cd terraform/prod
          terraform init
          terraform apply tfplan.json

Section 10: Scalr Security Features for Infrastructure Management

Scalr as an IaC Governance Platform

Scalr extends Terraform and OpenTofu with enterprise governance capabilities, enabling secure, compliant infrastructure operations at scale. For audit and compliance evidence, see Terraform audit logs; for runtime scanning integrations, see automating Terraform security in Scalr deployments with Regula and using Scalr hooks with Bridgecrew Yor.

Identity and Access Management

SAML 2.0 & SCIM Integration:

# Scalr integrates with corporate identity providers
# for unified authentication and provisioning

OIDC for API Access:

# Authenticate programmatically with OIDC tokens
# instead of static API keys

Policy Enforcement

Open Policy Agent (OPA) Integration:

# Scalr enforces OPA policies before infrastructure changes
package terraform.policies
 
deny[reason] {
    resource := input.resource_changes[_]
    resource.type == "aws_s3_bucket"
    not resource.change.after.server_side_encryption_configuration
 
    reason := sprintf("S3 bucket '%s' must have encryption enabled", [resource.name])
}

Checkov Integration:

# Scalr automatically scans Terraform/OpenTofu
# configurations with Checkov before execution

Credential Management

Provider Configurations:

Scalr centrally manages and securely stores credentials for cloud providers and other services, then automatically injects them into Terraform runs.

OIDC for Dynamic Cloud Credentials:

# Scalr supports OIDC for obtaining temporary
# credentials from AWS, Azure, and GCP
# eliminating long-lived static credentials

Infrastructure and Data Security

VCS Agents for Internal Repositories:

For organizations with self-hosted version control systems, Scalr's VCS Agents establish secure connections without exposing internal repositories to the public internet.

Self-Hosted Agents:

# Run Terraform/OpenTofu operations within
# your own network infrastructure for complete control

State Encryption:

• Scalr-managed state files are encrypted at rest
• Customer-managed backends use provider-native encryption
• Sensitive variables are encrypted and never exposed

Comprehensive Reporting

OPA Policy Violation Reporting:

Tracks which workspaces violate policies and provides remediation guidance.

Resource and Configuration Tracking:

Aggregates all resources across state files for visibility and audit purposes.

Drift Detection Reports:

Identifies discrepancies between intended and actual infrastructure configuration.

Version Management Reports:

Tracks Terraform/OpenTofu, module, and provider versions to identify outdated components with known vulnerabilities.

Stale Workspace Reports:

Identifies workspaces with active resources that haven't been recently updated, which may not reflect current security policies.

API Token Management:

Tracks token rotation and usage patterns to enforce security best practices.

Audit Logs:

Comprehensive activity logs with integration to AWS EventBridge or Datadog for centralized security analysis.

Section 11: Best Practices for IaC Security in 2026

1. Implement Zero Trust Architecture

Treat all networks as potentially hostile and enforce strict least-privilege principles:

• Require strong authentication for all API access
• Use temporary credentials instead of long-lived secrets
• Implement MFA for sensitive operations
• Audit all access and changes

2. Automate Security Assessment

Manual security reviews no longer suffice for infrastructure operating at cloud scale:

• Integrate static analysis into every CI/CD pipeline
• Use plan file analysis for pre-deployment validation
• Implement continuous post-deployment scanning
• Establish automated remediation workflows for policy violations

3. Adopt Permissions-on-Demand

Static permissions are inherently risky:

• Implement just-in-time (JIT) access for sensitive operations
• Use temporary credentials with short lifespans
• Leverage ephemeral resources for secrets and provider authentication
• Require explicit approval for privileged operations

4. Shift Left on Security

Catch issues as early as possible:

• Implement pre-commit hooks to prevent secrets and misconfigurations
• Use IDE integrations for real-time security feedback
• Enforce scanning in CI/CD before any deployment
• Empower developers with security tools that integrate into their workflows

5. Embrace Immutable Infrastructure

Rather than patching and modifying:

• Rebuild infrastructure from secure templates
• Use infrastructure as code to define everything
• Treat infrastructure as replaceable rather than precious
• Practice frequent, repeatable deployments

6. Manage Secrets Securely

Never trust hardcoded values:

• Use ephemeral resources for secrets that should not be persisted
• Integrate with external secret managers
• Implement secret rotation policies
• Enable MFA delete on secret storage
• Use OIDC for workload identity instead of static credentials

7. Enforce Policy as Code

Define and enforce security standards programmatically:

• Use OPA/Rego for custom security policies
• Define compliance requirements as code
• Make policies understandable and actionable for developers
• Implement dry-run modes to prevent surprise policy violations

8. Maintain Comprehensive Audit Trails

Security requires accountability:

• Enable CloudTrail, VPC Flow Logs, and application logging
• Integrate logs into SIEM for analysis
• Maintain audit trails of all infrastructure changes
• Track who made what changes and when

9. Manage Configuration Drift

Prevent unauthorized or unintended changes:

• Enable drift detection in Scalr or equivalent platforms
• Establish remediation workflows for detected drift
• Prevent manual changes to infrastructure
• Regularly verify deployed configuration matches intent

10. Build a Security Culture

Tooling alone is insufficient:

• Foster shared responsibility between development and security teams
• Provide security training for infrastructure engineers
• Reward and recognize security-conscious practices
• Make security part of the developer experience, not an obstacle

Conclusion

Securing Infrastructure as Code is a continuous journey requiring multiple layers of controls, tools, and practices. The security landscape continues to evolve, with new threats emerging and new solutions addressing longstanding challenges like ephemeral resource handling and dynamic credentials.

Success in 2026 requires:

• Comprehensive approach: Combine static analysis, runtime validation, and policy enforcement
• Automation: Integrate security into every stage of the development and deployment lifecycle
• Culture: Foster security awareness and shared responsibility across teams
• Platform: Leverage governance platforms like Scalr for consistent policy enforcement at scale

By implementing the practices and tools outlined in this guide, organizations can maintain secure, compliant, and efficiently managed infrastructure even as cloud complexity and threat sophistication continue to increase. Security is not a destination but an ongoing practice—one that becomes progressively more effective with proper tooling, automation, and organizational commitment.