Join our next Live Demo on Mar 16th!

Resource Blog News Customers Stories

Updated: Feb 17, 2026 Upd: 17.02.26

4 min read

Start Safe: Terragrunt Import For Multi-Account AWS

Daniel Alfasi

Daniel Alfasi

Backend Developer and AI Researcher

Start Safe: Terragrunt Import For Multi-Account AWS

Terragrunt Import lets you bring brownfield infrastructure under Terraform control across multi-repo and multi-account setups. Done right, you’ll avoid state drift, unstable addresses, and risky access patterns.

The goal is a reproducible, auditable workflow with clean plans and minimal permissions. Use a consistent remote state, pin tooling versions, and validate every step in CI. 

At a Glance: Terragrunt Import Best Practices

  • Standardize remote state and lock it
  • Pin Terraform, providers, and Terragrunt versions
  • Document intent with Terraform import blocks
  • Automate plans and halt on drift or diffs
  • Use least-privilege, short-lived credentials

Do: Prepare State, Providers, and Repo for Safe Terragrunt Import

Use a remote backend with locking and encryption (e.g., S3/GCS/Azure Blob) and inherit backend config via a root terragrunt.hcl. This prevents divergent state and protects you from concurrent writes.

Pin Terraform, provider, and Terragrunt versions; run terraform init -upgrade only in controlled windows, and validate in CI with terraform validate and terraform plan -detailed-exitcode gates.

Preflight with snapshots: enable bucket/container versioning and take a state backup before each import; start with a read-only discovery run.

Two-sentence mini-story: An engineer imported dozens of resources on a laptop with a newer provider than CI. The next pipeline showed a wall of “changes,” all caused by version drift; pinning would have caught this earlier.

Do: Use Import Blocks and Hooks for Terragrunt Import With Clear, Stable Addresses

Prefer Terraform 1.5+ import blocks to document import intent in code and keep resource addresses stable across runs. Combine with Terragrunt before/after hooks to generate import IDs, run a plan immediately after import, and fail on any nonzero exit or unwanted diff. Start with a skeleton HCL: declare essential arguments only; add lifecycle ignore_changes for noisy attributes until parity is verified. Caveat: import blocks require Terraform 1.5 or later.

Canonical snippet (HCL):

```hcl

# modules/storage/main.tf

resource "aws_s3_bucket" "logs" {

  bucket = var.bucket_name

  lifecycle {

    ignore_changes = [tags]

  }

}

# modules/storage/import.tf (Terraform ≥ 1.5)

import {

  to = aws_s3_bucket.logs

  id = "my-company-logs"

}

# live/prod/storage/terragrunt.hcl

terraform {

  source = "../../../modules/storage"

}

inputs = {

  bucket_name = "my-company-logs"

}

# Optional Terragrunt hook to halt on drift after import

hook "after_import_plan" {

  commands = ["import"]

  execute  = ["bash", "-lc", "terraform plan -detailed-exitcode || exit 1"]

}

Reference the import block snippet above in each environment and keep module paths stable.

Don’t: Change Module Structure Mid-Import or Apply Without a Clean Plan

Don’t refactor module names, move modules, or rename resources during a Terragrunt Import; that changes addresses and breaks state mapping. Never apply after an import unless the plan shows no unintended creates or destroys; enforce this with -detailed-exitcode in CI. If you discover an address mismatch, fix it with terraform state mv rather than re-importing or editing state by hand. Caveat: state mv operations should be reviewed in PRs and run from the same pinned toolchain as your plans.

Do: Enforce Least-Privilege and Short-Lived Access for Terragrunt Import

Use assume-role (or equivalent) with external IDs/MFA and short sessions, scoped to import-only APIs for the target services. Separate read-only discovery from write operations, rotate credentials, and store secrets in CI securely. Keep audit trails: confirm who imported what and when using provider logs (e.g., CloudTrail, Activity Logs, Audit Logs). Caveat: provider logs can lag; keep local CI run metadata for cross-checks.

Example: Importing a Storage Bucket (Concepts Apply Across Clouds)

Create a minimal resource block and keep the terragrunt.hcl path stable. Add a Terraform 1.5 import block with the bucket’s canonical ID. Run terraform init, then nudge Terragrunt to run a plan: terragrunt run-all plan -detailed-exitcode. The plan should show “no changes” except legitimate drift. If noise appears (e.g., tags, server-generated fields), add temporary lifecycle ignore_changes as in the snippet above, reconcile configuration to match reality, then remove ignores once parity is achieved. Finally, commit the import block and configuration together so future plans remain clean.

For syntax specifics, see Terraform’s Import documentation (Terraform import language reference).

## Bring It Together With Guardrails

A disciplined Terragrunt Import flow yields reproducible, auditable results with clean plans and least-privilege access. Codify intent with import blocks, keep addresses stable, and block applies on drift. ControlMonkey can accelerate this with discovery, safe sequencing, and policy guardrails. Request a demo to see it in action.

Bottom CTA Background

A 30-min meeting will save your team 1000s of hours

A 30-min meeting will save your team 1000s of hours

Book Intro Call

Author

Daniel Alfasi

Daniel Alfasi

Backend Developer and AI Researcher

Backend Developer at ControlMonkey, passionate about Terraform, Terragrunt, and AI. With a strong computer science background and Dean’s List recognition, Daniel is driven to build smarter, automated cloud infrastructure and explore the future of intelligent DevOps systems.

    Sounds Interesting?

    Request a Demo

    FQA

    Terragrunt less verbose refers to configuring Terragrunt and Terraform to reduce console output in CI while preserving key signals such as exit codes, warning summaries, and plan artifacts.ControlMonkey automates the safety checks: drift scans, blast-radius scoring, policy gates, and audit trails. Instead of juggling scripts, you get guardrails built in, so imports become predictable and boring — the way they should be

    Yes. Terragrunt import works well for AWS accounts and VPC modules where you need orchestration across regions or accounts

    The resource itself doesn’t change, but the state file is updated. If the mapping is wrong, it can cause drift or corrupt state on the next apply.

    Resource Blog News Customers Stories

    Updated: Sep 30, 2025 Upd: 30.09.25

    5 min read

    Terragrunt Less Verbose: SOC 2–Ready Log Sanitization

    Daniel Alfasi

    Daniel Alfasi

    Backend Developer and AI Researcher

    Terragrunt Less Verbose: SOC 2–Ready Log Sanitization

    When teams say “terragrunt less verbose,” they usually want quieter pipelines. For SOC 2, you need more than silence: you need sanitized logs that never leak secrets, yet still carry enough context to debug failures. This guide shows how to configure Terraform and Terragrunt for minimal chatter, apply CI-native masking, and gate outputs so sensitive values don’t escape. You’ll get practical flags, a portable redaction wrapper, and a plan for capturing the right evidence. The goal: quiet by default, sanitized always, loud only on controlled failure paths.

    At a Glance: Terragrunt Less Verbose in Practice

    – Identify where secrets leak in Terraform/Terragrunt logs and what to suppress.

    – Apply “terragrunt less verbose” defaults in CI without losing signal.

    – Add CI-native masking and a redaction wrapper before logs persist.

    – Configure Terraform to prevent printing secrets at the source.

    – Map controls and evidence to SOC 2 expectations.

    Why “Terragrunt Less Verbose” Matters for SOC 2

    Excess verbosity increases exposure risk. Tokens, keys, account IDs, and internal URLs frequently appear in provider initialization and error traces, and they slow reviews. SOC 2 expects principle-of-least-privilege logging, retention control, and clear evidence of guardrails, not just less noise. Aim for quiet by default and redact consistently, then permit targeted verbosity only in isolated, masked re-runs.

    These controls also support shift-left compliance and security practices, reducing review time and risk drift across pipelines. See how organizations standardize guardrails with ControlMonkey’s Shift Left Compliance & Security.

    Where Secrets Actually Leak in Terraform/Terragrunt Logs

    Provider initialization and authentication traces (e.g., cloud SDKs) can echo credentials, account IDs, or endpoint URLs if debug is enabled. Error stacks and panics may dump environment variables and interpolated values, especially when TF_LOG is set or modules print helpful but unsafe diagnostics. terraform output and module debug prints will expose values unless output blocks are marked sensitive = true, and plan JSON artifacts can include attribute values if you emit them to the console.

    One team enabled debugging globally in order to investigate an intermittent plan failure. The CI log captured a short-lived cloud token and a private domain—enough for an auditor to flag a gap and for the team to rotate credentials overnight.

    Terragrunt Less Verbose Defaults That Also Reduce Leakage

    Set safe environment defaults:

    • 1. TERRAGRUNT_LOG_LEVEL=error
    • 2. Leave TF_LOG empty (do not set in CI)
    • 3. TF_IN_AUTOMATION=1

    Use quiet CLI flags for signal with minimal chatter:

    • -no-color, -compact-warnings, -input=false
    • Prefer -detailed-exitcode to convey drift without verbose logs

    Operational caveats:

    • Don’t set TF_LOG_PATH on shared runners; logs can persist beyond job scope.
    • Never enable debug/trace globally; re-run in isolated jobs with masked vars and short retention.
    • Some providers emit important warnings; review the impact of -compact-warnings in staging before broad rollout.

    CI-Native Masking and Redaction Patterns

    Use provider-agnostic masking plus a lightweight redaction wrapper before logs persist. In GitHub Actions, mask high-risk env vars early using ::add-mask::. Only write secrets to masked outputs and scrub step outputs that may include provider messages. 

    In GitLab, CircleCI, or Jenkins, enable built-in masking for regex patterns such as AWS_SECRET_ACCESS_KEY and token formats like ^ghp_[A-Za-z0-9]{36}. Then pipe Terraform/Terragrunt output through a filter that replaces matches with “[REDACTED]” before tee or log upload.

    Caveats:

    • Masking hides display but not storage; ensure you redact before saving logs.
    • Regex filters must be version-controlle.

    Canonical Code Snippet: Redactor + Quiet Plan/Apply

    #!/usr/bin/env bash
    # redactor.sh — minimal stdout/stderr redaction for CI logs
    # Usage: your_command 2>&1 | ./redactor.sh | tee sanitized.log
    
    sed -E \
      -e 's/(AWS_ACCESS_KEY_ID|AWS_SECRET_ACCESS_KEY|AWS_SESSION_TOKEN)=([A-Za-z0-9\/+=_-]+)/
                className="blog-contain" =[REDACTED]/g' \
      -e 's/\b(ghp_[A-Za-z0-9]{36,})/[REDACTED]/g' \
      -e 's/\b([A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,})/[REDACTED_EMAIL]/g' \
      -e 's/\b([0-9]{12})\b/[REDACTED_ACCOUNT]/g'
    
    # Example usage with quiet flags:
    # terraform plan -no-color -compact-warnings -input=false -detailed-exitcode 2>&1 | ./redactor.sh
    # terragrunt run-all plan --terragrunt-non-interactive --terragrunt-include-external-dependencies 2>&1 | ./redactor.sh
    

    Terraform Settings to Prevent Printing Secrets at the Source

    Prevent leaks at the IaC layer. Mark all credential-like outputs as sensitive = true so they don’t print in CLI output, and avoid echoing variable values with local-exec or templated debug strings. Don’t stream plan JSON to the console; store it as a restricted artifact and redact where feasible. Prefer data sources and references that don’t expose tokens or keys in state or logs, and review module outputs by policy. See Terraform’s guidance on Sensitive Output Values for the right patterns and trade-offs.

    Evidence for SOC 2: Controls, Retention, and Auditor Expectations

    Map your sanitation controls to policy: masking rules, redaction scripts, and default non-verbose logging configs. Provide evidence with CI configuration, policy-as-code checks, log retention settings, and artifact access controls. Document a rerun-with-debug procedure that uses isolated runners, masked variables, and short-lived retention, and keep incident playbooks for leak handling. Auditors want predictable controls and repeatable evidence trails, not ad hoc exceptions.

    ControlMonkey Fit: Policy Guardrails and Standardized Pipelines

    ControlMonkey helps standardize sanitized, “terragrunt less verbose” defaults across every repo and pipeline. It enforces organization-wide IaC policies (for example, blocking modules that miss sensitive = true where appropriate), runs centralized PR checks for risky outputs, and produces curated, redacted plan summaries for reviewers. It also provides shift-left controls that surface issues early and preserve clean, reviewable evidence for SOC 2. Learn more about Shift Left Compliance & Security.

    Example CI Template (Quiet + Sanitized + Auditable)

    In your pipeline:

    • Pre-step: export TERRAGRUNT_LOG_LEVEL=error and TF_IN_AUTOMATION=1; ensure runner-level secret masking is active.
    • Plan: run terraform plan -no-color -compact-warnings -input=false -detailed-exitcode and pipe stdout/stderr through the redactor snippet above; save sanitized logs; store plan.json as a restricted artifact (no console dump).
    • Apply: only on approved branches after review; pipe apply output through the redactor; upload sanitized logs with defined retention; on failure, allow an isolated rerun with temporary TF_LOG=info and strict masking, then delete debug logs per policy.

    Turn Down the Noise, Turn Up Compliance

    You can make Terragrunt less verbose and still keep enough context to debug, meet SOC 2 expectations, and reduce incident risk. Set safe defaults, mask early, redact before persistence, and block sensitive outputs in code review. ControlMonkey can standardize these practices across repositories, enforce policy guardrails, and generate clean evidence on every run. Request a demo to see how ControlMonkey streamlines “terragrunt less verbose” pipelines and SOC 2 logging. Request a demo

    Bottom CTA Background

    A 30-min meeting will save your team 1000s of hours

    A 30-min meeting will save your team 1000s of hours

    Book Intro Call

    Author

    Daniel Alfasi

    Daniel Alfasi

    Backend Developer and AI Researcher

    Backend Developer at ControlMonkey, passionate about Terraform, Terragrunt, and AI. With a strong computer science background and Dean’s List recognition, Daniel is driven to build smarter, automated cloud infrastructure and explore the future of intelligent DevOps systems.

      Sounds Interesting?

      Request a Demo

      FQA

      Terragrunt less verbose refers to configuring Terragrunt and Terraform to reduce console output in CI while preserving key signals such as exit codes, warning summaries, and plan artifacts.

        Set TF_IN_AUTOMATION=1, TF_LOG=WARN, and TERRAGRUNT_LOG_LEVEL=warn, then run plan with -input=false, -no-color, -compact-warnings, and -detailed-exitcode. Add extra_arguments in terragrunt.hcl so terragrunt less verbose defaults apply org-wide.

        You get quicker triage, fewer leaks, and smaller logs without losing visibility. Exit codes and compact warnings surface change signals, while plan.out and plan.json keep your pipeline audit-ready.

      Cookies banner

      We use cookies to enhance site navigation, analyze usage, and support marketing efforts. For more information, please read our. Privacy Policy