Harness Infrastructure as Code

Harness Infrastructure as Code

Terraform, CloudFormation, and Pulumi analysis. Module structure, state management, drift prevention, and security posture for infrastructure definitions.

When to Use

• When reviewing or designing Terraform, CloudFormation, or Pulumi configurations
• When auditing IaC module structure, naming conventions, and state management
• On PRs that modify infrastructure definitions or add new cloud resources
• NOT for CI/CD pipeline configuration (use harness-deployment)
• NOT for container orchestration (use harness-containerization)
• NOT for application-level security (use harness-security-review)

Process

Phase 1: DETECT -- Identify IaC Tool and Structure

1. Detect IaC tooling. Scan the project for infrastructure definitions:

   • *.tf files -- Terraform (HCL)
   • terraform/ directory with .terraform.lock.hcl
   • cloudformation/, *.template.yaml, *.template.json -- CloudFormation
   • Pulumi.yaml, Pulumi.*.yaml -- Pulumi
   • cdk.json, cdk.out/ -- AWS CDK
   • infrastructure/, infra/ -- common IaC directories

2. Identify provider and backend. Parse configuration for:

   • Cloud providers (AWS, GCP, Azure) and their versions
   • State backend (S3, GCS, Azure Blob, Terraform Cloud, local)
   • Provider authentication method (environment variables, profiles, OIDC)
   • Lock file presence and provider version constraints

3. Map module structure. Build a dependency tree of modules:

   • Root modules and their child module references
   • Module source types (local path, registry, git)
   • Module versioning (pinned vs. unpinned)
   • Input variables and output values per module
   • Shared modules used across multiple root configurations

4. Detect environment separation. Identify how environments are managed:

   • Workspaces (Terraform workspaces)
   • Directory-per-environment (environments/dev/, environments/prod/)
   • Variable files per environment (terraform.tfvars, prod.tfvars)
   • Backend configuration per environment

5. Present detection summary:

   IaC Detection:
     Tool: Terraform v1.7
     Provider: AWS (us-east-1, us-west-2)
     Backend: S3 with DynamoDB locking
     Modules: 8 local, 3 registry
     Environments: dev, staging, prod (directory-per-env)
     State files: 3 (one per environment)
   

---

Phase 2: ANALYZE -- Evaluate Patterns and Anti-Patterns

1. Check state management. Verify state is properly configured:

   • Remote backend with locking (not local state for shared infrastructure)
   • State encryption at rest enabled
   • State file does not contain secrets in plain text
   • State is segmented per environment (no single state file for all environments)
   • Backend configuration uses variables, not hardcoded values

2. Evaluate module design. Check modules for:

   • Single responsibility (one module does one thing)
   • Input validation (variable validation blocks or type constraints)
   • Output completeness (downstream consumers can get what they need)
   • No hardcoded values that should be variables
   • README or documentation for each module
   • Consistent naming conventions across modules

3. Check resource naming and tagging. Verify:

   • Resources follow a consistent naming convention (e.g., {project}-{env}-{resource})
   • Required tags are present on all taggable resources (environment, team, cost-center)
   • Tag values are consistent (no mix of "prod" and "production")
   • Names do not contain environment-specific values in shared modules

4. Analyze dependency management. Check for:

   • Provider version constraints (required_providers block)
   • Module version pinning (exact version or range)
   • Lock file committed to version control
   • No circular dependencies between modules
   • Implicit dependencies are made explicit with depends_on where needed

5. Check for common anti-patterns:

   • Monolithic root modules (everything in one configuration)
   • Hardcoded AMI IDs, account numbers, or region values
   • Resources created outside of IaC (drift risk)
   • Overly permissive IAM policies (wildcards on actions or resources)
   • Missing lifecycle rules (prevent_destroy on critical resources)

---

Phase 3: DESIGN -- Recommend Structure and Patterns

1. Recommend module decomposition. If monolithic configurations are detected:

   • Propose a module hierarchy based on service boundaries
   • Separate networking, compute, storage, and security into distinct modules
   • Design shared modules for common patterns (e.g., tagged S3 bucket, VPC)
   • Provide module interface design (inputs, outputs)

2. Design state management strategy. Recommend:

   • One state file per environment per service
   • Remote backend with encryption and locking
   • State import plan for any resources created outside IaC
   • Cross-state data sharing via terraform_remote_state or SSM parameters

3. Recommend drift detection workflow. Design a process to catch manual changes:

   • Scheduled terraform plan in CI to detect drift
   • Alert on any planned changes that were not initiated by a PR
   • Runbook for reconciling detected drift (import vs. revert)
   • Tag resources as IaC-managed for auditability

4. Design environment promotion. Recommend a workflow for infrastructure changes:

   • Changes applied to dev first, then promoted to staging, then production
   • Variable files per environment with appropriate overrides
   • Approval gates before production applies
   • Plan output reviewed as part of PR process

5. Recommend security hardening. For each provider:

   • Least-privilege IAM roles for IaC execution
   • No inline policies (use managed policies or policy documents)
   • Encryption enabled by default on all storage resources
   • Network security groups with explicit deny rules
   • Sensitive variables marked with sensitive = true

---

Phase 4: VALIDATE -- Verify Configuration Correctness

1. Run static analysis. Execute available validation tools:

   • Terraform: terraform validate, terraform fmt -check
   • CloudFormation: cfn-lint or aws cloudformation validate-template
   • Pulumi: type checking via the chosen language runtime
   • CDK: cdk synth to verify template generation
   • General: tflint, checkov, or tfsec for security checks

2. Verify variable completeness. For each root module:

   • All declared variables have descriptions
   • Required variables have no default values
   • Optional variables have sensible defaults
   • Variable types are specific (not any)
   • Validation blocks exist for constrained values (e.g., allowed regions)

3. Check plan safety. If a plan output is available:

   • No unexpected resource deletions
   • No changes to resources marked with prevent_destroy
   • Replacements are expected (not caused by force-new arguments)
   • Plan matches the intended change described in the PR

4. Verify security posture. Run security-focused checks:

   • No public S3 buckets or storage accounts
   • No security groups allowing 0.0.0.0/0 on sensitive ports
   • Encryption enabled on RDS, EBS, S3, and other storage
   • IAM policies follow least privilege
   • No credentials or secrets in variable defaults or outputs

5. Generate validation report:

   IaC Validation: [PASS/WARN/FAIL]
   
   Format check: PASS (all files formatted)
   Validate: PASS (no syntax errors)
   Security scan: WARN (2 findings)
     - modules/storage/main.tf: S3 bucket missing server-side encryption
     - modules/network/main.tf: security group allows 0.0.0.0/0 on port 22
   Module design: WARN (3 modules missing input validation)
   State management: PASS (remote backend with locking)
   
   Recommendations:
     1. Add aws_s3_bucket_server_side_encryption_configuration resource
     2. Restrict SSH access to VPN CIDR range
     3. Add variable validation blocks to network, compute, and storage modules
   

---

Harness Integration

• harness skill run harness-infrastructure-as-code -- Primary invocation for IaC analysis.
• harness validate -- Run after configuration changes to verify project health.
• harness check-deps -- Verify IaC tool dependencies are installed.
• emit_interaction -- Present design recommendations and gather decisions on module structure.

Success Criteria

• IaC tooling, provider, and backend are correctly identified
• Module structure is mapped with dependency relationships
• State management is verified as remote, encrypted, and locked
• Resource naming and tagging follow consistent conventions
• Security posture is evaluated with no critical findings unaddressed
• Static analysis tools pass without errors

Examples

Example: Terraform AWS Multi-Environment Setup

Phase 1: DETECT
  Tool: Terraform v1.6.4
  Provider: AWS (hashicorp/aws ~> 5.0)
  Backend: S3 (us-east-1) with DynamoDB locking
  Modules: 5 local (vpc, ecs, rds, s3, iam), 2 registry (datadog, cloudwatch)
  Environments: dev, staging, prod (directory-per-env with shared modules)

Phase 2: ANALYZE
  State management: PASS (remote, encrypted, locked, per-env)
  Module design: WARN
    - modules/ecs has 450 lines -- recommend splitting into ecs-cluster
      and ecs-service modules
    - modules/rds missing variable validation for instance_class
  Naming: PASS (consistent {project}-{env}-{resource} pattern)
  Tags: WARN (cost-center tag missing on 3 resources)
  Anti-patterns: 1 hardcoded AMI in modules/ecs/main.tf

Phase 3: DESIGN
  1. Split modules/ecs into ecs-cluster and ecs-service
  2. Add data source for AMI lookup instead of hardcoded value
  3. Add variable validation: instance_class must be db.t3.* or db.r6g.*
  4. Add cost-center tag to default_tags in provider configuration
  5. Add scheduled terraform plan for drift detection in CI

Phase 4: VALIDATE
  terraform fmt: PASS
  terraform validate: PASS
  tfsec: WARN (2 findings -- see above)
  checkov: PASS
  Result: WARN -- 5 improvements recommended, no blocking issues

Example: CloudFormation with CDK

Phase 1: DETECT
  Tool: AWS CDK v2.120 (TypeScript)
  Provider: AWS (us-west-2)
  Backend: CloudFormation (managed by CDK)
  Stacks: 3 (NetworkStack, ComputeStack, StorageStack)
  Environments: dev and prod via CDK context

Phase 2: ANALYZE
  Stack design: PASS (clean separation by concern)
  Cross-stack references: PASS (using CfnOutput and Fn::ImportValue)
  Security: WARN
    - ComputeStack: EC2 instance has public IP and open SSH
    - StorageStack: DynamoDB table missing point-in-time recovery
  CDK constructs: Using L2 constructs (good -- higher abstraction)

Phase 3: DESIGN
  1. Add bastion host pattern instead of direct SSH to EC2
  2. Enable point-in-time recovery on DynamoDB table
  3. Add cdk-nag for automated security checks in synthesis
  4. Add stack-level tags via Tags.of(stack).add()

Phase 4: VALIDATE
  cdk synth: PASS (3 templates generated)
  cfn-lint: PASS (all templates valid)
  Security: WARN (2 findings)
  Result: WARN -- 2 security improvements needed

Rationalizations to Reject

Rationalization	Reality
"We store state locally because it's just a dev environment"	Local state is not shared between team members. Two developers running terraform apply against the same environment with diverged local state will produce conflicting resource definitions, duplicate resources, or state corruption that requires manual recovery.
"We haven't pinned the provider version because we want to automatically get security patches"	Unpinned providers can silently change resource behavior on terraform init. A ~> 5.0 constraint without an upper bound can pull a provider with breaking changes. Pin the minor version and upgrade explicitly via reviewed PRs so changes are intentional.
"That S3 bucket has public access because it hosts our static site"	Static site hosting does not require a public bucket ACL. CloudFront with an Origin Access Control (OAC) policy serves files from a private bucket. Public bucket ACLs are a common misconfiguration vector because they apply to all objects, including accidentally uploaded sensitive files.
"We'll tag resources properly before we go to production"	Untagged resources accumulate. Cost allocation reports become impossible, security audits cannot identify owners, and decommissioning requires manual investigation of every resource. Tagging must be enforced at resource creation — retroactive tagging at scale is a weeks-long engineering project.
"Manual changes are fine for urgent hotfixes — we'll import them to Terraform afterward"	Manual changes without immediate import create drift that may be overwritten by the next terraform apply. The "import it later" step is almost never done. Every manual change that goes unimported erodes the reliability guarantee that IaC provides.

Gates

• No local state for shared infrastructure. Terraform configurations managing shared resources must use a remote backend with locking. Local state is blocking for any non-experimental configuration.
• No unpinned provider versions. Provider version constraints must be explicit. Using >= without an upper bound or omitting version constraints entirely is a blocking finding.
• No public access to sensitive resources. S3 buckets, databases, or storage accounts with public access enabled are blocking security findings.
• No credentials in IaC files. Hardcoded access keys, passwords, or tokens in Terraform variables, CloudFormation parameters, or Pulumi configuration are blocking findings.

Escalation

• When state is corrupted or diverged: Do not attempt automatic recovery. Report the state of divergence, recommend terraform state pull for backup, and advise manual reconciliation with a plan review before any apply.
• When resources exist outside IaC management: Recommend a phased import strategy. Provide terraform import commands for each resource and note that import does not generate configuration -- the HCL must be written manually.
• When module versions are significantly outdated: Present the version gap and changelog summary. If breaking changes exist, recommend a separate PR for the upgrade with a plan review before applying.
• When IaC tool version conflicts exist between team members: Recommend pinning the tool version in .terraform-version (tfenv) or Pulumi.yaml and adding version checks to CI.