Lifecycle Custom Steps
StackGuardian allows users to create customized runtime environments on the SG Workflow Engine, integrating bespoke logic directly into their workflows. These runtimes enable efficient automation tailored to specific needs, leveraging Infrastructure as Code (IAC) capabilities.
Leveraging Flexibility with Custom Workflowsβ
When using custom workflow templates in StackGuardian:
- Tool-Specific Syntax: Each IAC tool has its own syntax. For example, using an Ansible playbook involves Ansibleβs configuration features, distinct from Terraform's HCL.
- Smooth Integration: Custom templates simplify the integration of existing infrastructure code, regardless of the IAC tool.
- Specialized Capabilities: Different tools provide specialized features, such as AWS CloudFormation for AWS services and Azure Resource Manager for Azure services. -->
Terraform-Specific Lifecycle Custom Stepsβ
Allows users to create customized runtime environments on the SG Workflow Engine, integrating bespoke logic directly into their workflows. These runtimes enable efficient automation tailored to specific needs, leveraging Infrastructure as Code (IAC) capabilities.
StackGuardian provides several predefined steps to enhance Terraform configurations. These steps allow users to define specific actions at various stages of the workflow.
Mount Pointβ
When using private runner groups for deploying workflows, one or more Mount Points can be added under the lifecycle custom steps. These are essential for mounting paths from the private runner to the runtime container, such as files or certificates needed during the execution of the workflow.
Mount Points Setupβ
To add a Mount Point to a workflow:
-
Source Path: Absolute path on the private runner where the directory or file exists that you want to mount inside the workflow step container. For instance:
/usr/bin/terraform1_9_5
-
Target Path: Path inside the workflow container where the source directory or file will be mounted. For example:
/usr/bin/terraform1_9_5
-
Is Read Only: Ensures that the mounted path is read-only, preventing any modifications inside the container.
Pre Init does not support Mount Points, as terraform init
involves setting up the backend and modules, and adding mounts at this stage could interfere with the process. Mount Points are supported during Pre Plan and later steps, where source files are available and accessible.
Pre Initβ
Execute commands or steps before running terraform init
. This step is useful for setting up the environment or pre-configuration checks that need to be completed before initialization.
Pre Planβ
Commands or workflow steps executed before terraform plan
. This is where any required checks or preparations are made before generating a plan.
Post Planβ
Steps that are executed after the terraform plan
has been created. These actions could involve analyzing the plan or performing security scans.
Pre Applyβ
Commands executed before running terraform apply
. This step ensures everything is in place and that any final checks are performed before making actual infrastructure changes.
Post Applyβ
Actions taken after running terraform apply
, such as post-deployment validations, reporting, or triggering additional workflows.
These lifecycle hooks provide users with control over the different stages of the Terraform lifecycle, ensuring each phase is managed efficiently.
Example: Integrating Wiz.io with Terraform Workflowβ
In this example, we demonstrate running a Terraform workflow that integrates with Wiz.io for vulnerability scanning before deploying resources.
Prerequisitesβ
- A private runner configured for executing the workflow. Set the Runner Type to private and select the appropriate runner name in the Execution Environment.
- The Wiz.io custom workflow step from the StackGuardian marketplace. See StackGuardian Documentation for more details.
Step 1: Pre-Apply Authentication with Wiz.ioβ
To authenticate with Wiz.io, an id
and secret
are used to generate a token, which is stored in the workspace mount point for later use during the wiz_scan step.
Configuration Steps
-
Under Lifecycle Custom Steps, disable "Run commands in the same environment" for the pre-apply step and click "Add New Step".
-
In Mount Points, configure:
2.1. Source Path: Specify the path where the Terraform plan is located (e.g.,/var/tmp/workspace/orgs/ORG_NAME/wfgrps/WFGRP_NAME/wfs/WF_NAME/shared-workspace/user
).
2.2 Target Path: Preset path corresponding to Terraform settings (e.g.,/cli
).
Step 2: Post-Apply Vulnerability Scanβ
In this step, the generated Terraform plan is scanned for security vulnerabilities using Wiz.io. The plan path is defined as follows:
Configuration Steps
-
Under Lifecycle Custom Steps, disable "Run commands in the same environment" for the post-apply step and click "Add New Step".
-
In Mount Points, configure:
2.1. Source Path: Specify the path where the Terraform plan is located (e.g.,/var/tmp/workspace/orgs/ORG_NAME/wfgrps/WFGRP_NAME/wfs/WF_NAME/shared-workspace/user
).
2.2 Target Path: Preset path corresponding to Terraform settings (e.g.,/cli
). -
In Command Override, add the path as follows (e.g.,
REPOSITORY_NAME/tf_plan.json
).
The scan analyzes the Terraform plan for risks before proceeding with deployment.
Step 3: Analysis and Deploymentβ
After a successful vulnerability analysis, the Terraform plan is applied, deploying the necessary resources. Workflow results can be viewed in the βRunsβ tab in StackGuardian and also in the Wiz.io portal for further analysis.
StackGuardianβs Lifecycle Custom Steps provide flexibility for customizing Terraform workflows by integrating additional tools like Wiz.io for risk scanning or using pre- and post-deployment hooks. These steps enhance control, security, and customization, ensuring workflows meet specific needs, whether for configuration management or vulnerability analysis across cloud environments.