Infrastructure as Code with OpenTofu
Use Pipekit and Argo Workflows to validate, plan, and apply infrastructure-as-code changes through your existing review pipeline.
The problem
OpenTofu and Terraform changes are high-blast-radius. A misconfigured security group or an unintended tofu destroy can take down production faster than almost any other class of change in a typical platform. The standard mitigations (security scanning, linting, tofu plan review, drift detection) are well understood, but stitching them together is not.
Most teams end up running tofu plan inside a generic CI runner (GitHub Actions, Jenkins, GitLab CI) and pasting the output into pull-request comments. That works for a single team and a single environment. It breaks down quickly: the plan output is hard to review at scale, the runner doesn't enforce mutual exclusion so two engineers can race each other into a locked state, nightly drift detection has nowhere natural to live, and the apply step turns into "whoever has the credentials on their laptop."
The teams that get this right tend to converge on the same shape: a real DAG, a real workflow engine, secrets the runner doesn't touch, mutual exclusion enforced at the engine level, and a separate path for plan vs apply. That shape is exactly what Argo Workflows gives you.
How Pipekit helps
Argo Workflows runs the DAG. Pipekit adds the surfaces an Argo deployment by itself doesn't have: a unified UI across Clusters, persisted Run history with searchable logs, per-environment secrets scoped to workspaces, Templates that let you share the apply step safely across teams, and alerting when drift detection fires.
The two worked examples below come from a real Pipekit customer's setup. The first is a pull-request validation Workflow that runs checkov, tflint, and tofu plan against three Terraform paths in parallel and posts the plan output as a PR comment. The second is a CronWorkflow that runs tofu plan -detailed-exitcode nightly to detect drift. Both are designed so the apply step is intentionally separate. See the Best practices section.
Worked example: Pull-request validation
When a pull request modifies infrastructure code, an automated Workflow validates the changes before merge.
The Workflow performs several validation steps:
Clone the infrastructure repository.
Run security scans to detect misconfigurations (
checkov).Run linting to enforce best practices (
tflint).Generate Terraform/OpenTofu plans showing what will change.
Post plan summaries as PR comments for review.
Workflow Structure
The PR validation Workflow consists of multiple tasks organized as a DAG (directed acyclic graph):
Security scanning
The Workflow uses Checkov to scan infrastructure code for security and compliance issues:
Terraform planning
The Workflow generates a plan showing what infrastructure changes would occur:
The plan output is captured and posted as a comment on the pull request, giving reviewers clear visibility into the proposed changes.
Worked example: Nightly drift detection
Infrastructure drift occurs when the actual state of your infrastructure diverges from what is defined in your code. A scheduled CronWorkflow can detect this drift by running tofu plan regularly and alerting when changes are detected.
CronWorkflow structure
The nightly drift detection Workflow runs on a schedule and checks for infrastructure changes:
Drift detection logic
The Workflow runs tofu plan with the -detailed-exitcode flag, which returns exit code 2 when changes are detected:
When drift is detected, the Workflow sends a notification to alert the team.
Best practices
Use mutual exclusion
Infrastructure operations should not run concurrently on the same resources. Use Argo's synchronization.mutexes to ensure only one Workflow modifies infrastructure at a time:
Secure credentials management
Store sensitive credentials in Kubernetes Secrets and inject them into Workflow pods as environment variables:
For tighter integration, use external secrets management solutions like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault with the appropriate Kubernetes integrations.
Separate plan from apply
Never automatically run terraform apply or tofu apply in automated Workflows. Always generate plans for review, then apply changes manually or with explicit human approval.
A common pattern is to create a Workflow Template for the apply step. This lets authorized users submit the template to apply infrastructure changes without configuring their local environment with the correct credentials and tooling. The template carries the necessary credentials, container image, and configuration, giving you consistent and secure infrastructure deployments.
For example, create a template that takes the plan output as input and applies it:
Users submit this template from Pipekit when they're ready to apply reviewed changes.
Monitor for drift
Run drift detection Workflows on a regular schedule (e.g. nightly) to catch unexpected infrastructure changes early. Alert your team when drift is detected so they can investigate and remediate.
Use node selectors
For resource-intensive operations like security scanning, specify node selectors so Workflows run on appropriate hardware:
Related
Pipes: how to create and run the Pipes that wrap these Workflows.
Templates and the Templates how-to: share the
applystep safely across teams.Secrets: per-environment secrets for cloud credentials.
Alerting: fire alerts when drift detection triggers.
Why Pipekit > Governance and Why Pipekit > Scale: the value-prop framing that maps onto this use case.
Pipekit CLI: submit and manage these Workflows from your terminal.
Last updated