member badge
Andreas Grub
Problem / Use Case
Every
terraform apply
in a Building Block (BB) run is blind: there's no way to preview what Terraform intends to do before it executes. A version upgrade, input change, or configuration drift can silently trigger destructive operations — deleting an S3 bucket, removing a VPC, wiping a database — with no warning and no chance to intervene.
Three concrete pain points:
  • Blind applies during BB upgrades.
    When rolling out a new BBD version, there's no way to see the plan before apply kicks off. Destructive changes are only discovered from logs after the fact.
  • No abort-safe workflow.
    If you spot dangerous output mid-run and abort, all logs disappear — along with the evidence needed to understand what happened.
  • No per-BBD guardrails.
    Platform teams managing critical infrastructure cannot declare "this BBD must never delete an
    aws_s3_bucket
    without approval" — there's no such hook today.
Value / Impact
  • Prevents accidental destruction of production infrastructure by surfacing dangerous operations
    before
    tf apply
    runs.
  • Lets platform engineers define per-BBD safety rules — not one-size-fits-all global settings.
  • Reduces support incidents from runaway deletions or unexpected replacements during upgrades.
  • Provides natural approval gates for regulated environments (SOC 2, ISO 27001, change management).
  • Foundation for drift detection: once meshStack evaluates a plan, periodic dry runs become straightforward.
Proposed Roadmap
## Phase 1 — Plan safety checks (opt-in)
Run
terraform plan
as part of every BB run and surface the JSON plan output in the run view. Automatically scan for dangerous operations (deletions, forced replacements).
Introduced as an
opt-in BBD flag: "enable plan safety checks"
(default:
false
). When enabled and dangerous operations are detected:
  • The BB run is
    paused
    — this is a hard gate, not a warning.
  • The platform engineer sees the detected actions in meshPanel and must
    explicitly approve
    before
    terraform apply
    proceeds.
## Phase 2 — Configurable policies with OPA/Rego (conftest)
Attach OPA/Rego policies to a BBD version. meshStack evaluates them against the plan JSON before
terraform apply
using conftest. Policies declare one of three outcomes:
  • deny
    — abort the run, surface the violation to the operator.
  • warn
    — continue the apply, surface the warning in the run log.
  • require_approval
    — pause the BB run; platform engineer approves in meshPanel before apply proceeds.
Policy libraries can be fetched from a Git repository or OCI registry, enabling shared org-wide rule sets.
## Phase 3 — Policy management in meshPanel and Terraform provider
Expose policy management as a first-class feature in meshPanel and the meshStack Terraform provider. Platform engineers manage, version, and assign Rego policies to BBD versions as code (GitOps-style).
As-Code Story — meshStack Terraform Provider
When managing BB instances via
meshstack_building_block
, policy outcomes surface as
warnings and status attributes
, never as errors that taint or recreate the resource — BB instances hold Terraform state that would be permanently lost on recreation.
  • **
    require_approval
    :** Apply completes. Provider emits a warning and exposes
    last_run_status = "awaiting_approval"
    . Downstream automation can detect and react.
  • **
    deny
    :
    Apply completes with a
    warning
    (not an error). Resource is
    not tainted and not recreated**.
Related Requests
If you are hitting this today, reach out to support@meshcloud.io.