Workflows & Guardrails

The Workflows section of Firefly is all about automation: setting up Infrastructure-as-Code automation tasks and enforcing guardrails in your deployment processes. Workflows help you operationalize Firefly's capabilities by integrating them into your CI/CD pipelines or running them continuously.

A Workflow in Firefly typically consists of one or more steps that can be executed in response to certain triggers (like a code pipeline run or a schedule). Two primary use cases for Workflows are: Automatic Codification (turning any new unmanaged resources into code on an ongoing basis) and Guardrails Enforcement (policy checks that run during IaC deployments to prevent non-compliant changes).

Setting Up IaC Automation

One of Firefly's powerful features is the ability to automatically codify resources into IaC. Rather than manually clicking "Codify" for each new resource, you can create a workflow that does this routinely. For example, you might configure a workflow that runs every night (or on demand) to scan for any unmanaged assets and generate Terraform files for them.

To set this up:

1. Go to Workflows and choose New Workflow

2. Define the trigger (could be time-based or event-based)

3. Then add a Codify step – Firefly will ask which cloud or resource types to target and what IaC format to output (Terraform, Pulumi, etc.)

Once activated, this workflow will ensure your environment gradually reaches full IaC coverage. You'll get merge requests or files for new assets which you can review and commit to your repos. Over time, this automated codification means engineers spend less time writing IaC from scratch – Firefly generates it for them, accelerating IaC adoption.

Another type of IaC automation is Drift remediation. You can create a workflow to handle drift as it's detected. For instance, a workflow might trigger when Firefly detects a drift in an asset: the workflow could automatically generate the Terraform code update (or CLI command) needed to resolve the drift, and even open a pull request to your Git repo with that fix. This closes the loop from detection to resolution.

Firefly's auto-remediation can be configured such that when a drift or policy violation is found, it provides a suggested fix in code. In a workflow, you can include a step to commit that fix to Git (with one-click approval). This greatly shortens the time-to-remediate – going from an issue to a resolved state in minutes. Setting up these automation workflows ensures your cloud stays up-to-date with IaC and consistent with desired configurations without constant human intervention.

Guardrails in CI/CD

Firefly Guardrails are automated policy checks that integrate into your infrastructure deployment process (especially Terraform and other IaC pipelines). The goal of guardrails is to prevent non-compliant infrastructure changes from ever being applied. In Firefly, you manage Guardrails under the Workflows section (often in a "Guardrails" tab or submenu).

Types of Guardrail Rules

Firefly supports several categories of guardrail rules you can configure:

Cost Rules

Set thresholds for cost impacts. For instance, you can create a rule to block any deployment that would increase monthly cost by more than $100. Firefly integrates with cost estimation – when a Terraform plan is generated, Firefly can estimate the cost delta. If it exceeds your defined limit, the guardrail stops the apply. This prevents accidentally deploying something that blows your budget (e.g. spinning up an expensive instance type unintentionally).

Policy Rules

Ensure compliance and best practices, similar to Firefly's governance policies but enforced pre-deployment. For example, a rule could require that all new storage buckets have encryption enabled. If a change in the Terraform plan violates this (like a bucket resource lacks the encryption setting), Firefly will block it. Essentially, it checks the plan against OPA policies.

Resource Rules

Control specific create/modify/delete actions on resources. For instance, you might disallow creating any resources in region "us-west-2" for compliance reasons. A resource guardrail could flag and block any Terraform change that tries to create a resource in that region. Another use: prevent deletion of certain critical resources by mistake.

Tag Rules

Enforce tagging standards. You can require that all new resources have certain tags (like Environment or Owner). If a resource in the deployment is missing required tags, the guardrail fails the deployment. This ensures consistency and helps with cost allocation and governance.

You can mix and match these guardrail types. Each guardrail rule can be configured with an enforcement mode. Typically, Firefly applies them in blocking mode (meaning if a rule is violated, the deployment will not proceed). However, you might set some as advisory (warn but not block) during initial adoption.

Creating a Guardrail

In the Guardrails interface, click "New Guardrail". You will define the scope (which workspace or environment it applies to – e.g. a specific Terraform Cloud workspace, or perhaps all changes in an AWS account) and then add rule conditions. For example, to add a cost guardrail, you choose "Cost" type, set a limit (say $50 cost increase), and save. You might name it "CostGuardrail-$50-cap". For a policy guardrail, you could select from existing policy checks (Firefly can leverage the same Rego policies from governance here) or define a new check specifically for deployments. Once guardrails are set up, any time an IaC plan is run through Firefly's integration, these rules will be evaluated.

Integrating with CI/CD

To enforce guardrails, you need to integrate Firefly into your CI/CD pipeline. Firefly provides integrations like a Terraform Cloud Run Task (if you use Terraform Cloud/Enterprise) and API endpoints or CLI for other CI tools.

For Terraform Cloud, you would register Firefly as a run task that executes after the plan phase. This way, whenever you run "terraform plan" in that environment, Terraform Cloud sends the plan to Firefly, which checks for any guardrail violations before allowing "terraform apply". If violations are found, Firefly returns a status that causes the run to fail (or be advisory). Firefly's run task can even show how many assets would be affected by the plan outside of Terraform management (catching things Terraform alone wouldn't).

In Jenkins or other CI systems, you can use Firefly's API: for example, Jenkins can call Firefly's guardrail check endpoint with the plan file, or use a Firefly CLI tool, to similarly get a pass/fail result. Firefly will post a detailed report of any violations (and even add a PR comment on GitHub if the change came from a pull request). The guardrails report shows which rules were violated and why, so developers can quickly fix the issues before re-running.

Managing Guardrail Results and Overrides

In the Firefly UI, the Guardrails page will list recent deployment runs and whether they passed or had violations. If a deployment is blocked, you have options to override in some cases. Firefly allows authorized users to override guardrail violations if absolutely necessary (for example, if there's an exceptional case, an admin can force the deployment through). Overrides are tracked and can be limited by number or time window.

Each violation can also have an AI-generated remediation suggestion – Firefly might suggest how to modify your IaC to comply with the rule (for instance, "Enable encryption on resource X") so the developer can easily fix it. These suggestions appear in the UI at the guardrail step, and can even be posted as comments on the pull request if the pipeline is linked to VCS.

Best Practices for Workflows and Guardrails

Using Workflows and Guardrails, you essentially integrate Firefly into your DevOps workflow. Developers will get immediate feedback if they try to introduce something against policy or that would cause drift issues, and automation can handle the heavy lifting of generating and updating IaC. Some best practices for this section of Firefly:

• Start with a non-blocking mode in initial trials – let guardrails run in advisory mode on your pipeline to see what it would flag, without stopping deployments. Once you fine-tune rules and trust the process, switch to enforcing block mode.

• Leverage the cost guardrails to avoid surprise bills. For example, set monthly budget limits on dev environments. Firefly's cost monitoring integration will catch anomalies or large increases.

• Use tagging guardrails to ensure every resource is accounted for (team, env, purpose), which pays dividends in governance and cost tracking.

• Regularly review the Workflows page for any failed runs or overrides. If you see frequent overrides for a particular rule, discuss if the rule is too strict or if engineers need guidance to comply.

• Integrate notifications for guardrails as well – e.g. have Firefly post in Slack when a guardrail blocks a deployment, so everyone is aware and can address it promptly.

In summary, the Workflows and Guardrails functionality in Firefly moves you from just monitoring to actively controlling your infrastructure as code pipeline. By automating codification and embedding policy checks into deployments, Firefly helps you achieve continuous compliance and automation. Over time, this reduces manual toil (fewer hours fixing drift or writing boilerplate IaC) and prevents misconfigurations from ever reaching production. Your cloud stays "as-code" and under guardrails at all times, which dramatically improves reliability and security.