Continuous integration pipeline for Infrastructure as Code

Stages and tasks

For more information about how to customize stages by using the .pipeline-config.yaml file, see Custom scripts and Pipeline parameters lists.

Parameters to configure Terraform context and variables

For Terraform definitions that define infrastructure-as-code source, the context and variables that are related to Terraform and Terraform-related scan and checks can be defined by using the parameters that are described in Table 1.

The same parameters apply for the scripts that are used in an IaC CD deployment process. Because the CD process can process multiple inventory entries, you can scope a parameter for an inventory entry. To specify Terraform context and variables for a scope (inventory entry), prefix the property with the inventory entry name, for example: <inventory_entry>_. This prefix applies for the environment entries tf-dir, TF_VAR_<XXXX>, tfvars-repository, tfvars-branch, and tfvars-files.

Example:

hello-iac-sample_TF_VAR_resource_group : Default

Static code scan

The static code scan stage runs a number of static code analyzer tools on the specified IaC repositories. The repos that are provided by the pipelinectl save_repo command and the default app repo are scanned.

You can use any of the methods that are defined for static code scan configurable for application relate continuous integration pipeline.

The IaC continuous integration pipeline defines more tools that are enabled by using the opt-in-* parameters from Table 2 set to 1.

Scans and checks in compliance checks

Compliance checks defined for application related continuous integration pipeline are also performed for the IaC continuous integration pipeline.

The IaC CI pipeline performs some additional checks that are enabled by using opt-in- features.

The IaC CI pipeline defines more tools that are enabled by using the opt-in- parameters set to1.

These scripts are run on all the repos that the pipeline is aware of. To add repos to these scans, use the pipelinectl interface that is provided in your setup stage. For more information, see pipelinectl.

For more information about the expected output from user script stages, see Custom scripts.

{
    "scc_rules": [
        {
            "scc_rule_id": "rule-8cbd597c-7471-42bd-9c88-36b2696456e9"
        },
        {
            "scc_rule_id": "rule-c97259ee-336d-4c5f-b436-1868107a9558"
        }
    ]
}

Build artifact

In the build artifact stage, you can build your own artifacts. For the IaC CI pipeline, the default build feature creates a Tar file that contains the Terraform configuration.

The default build feature can be configured by using specific parameters from Table 5.

For more information about how to access parameters and secrets in custom script stages, see Custom scripts.

Artifact sign

The sign artifact stage provides a default behavior to use a GPG key to create a detached signature file for one or more artifacts.

To use a different sign process, customize this stage by using the .pipeline-config.yaml configuration in your project.

Deploy to development

The deploy stage deploys configuration artifact into a development environment. You can provide your variables and credentials for this stage from variables in the pipeline UI and the pipeline trigger webhook payload.

The scripts that are provided as part of the common base image can help perform a deployment by using schematics or Terraform CLI. The parameters to configure the scripts for the deployment action are described in Table 8 and Table 9.

hello-iac-sample_schematics-workspace-name : workspace-for-deployment-of-hello-iac-sample

hello-iac-sample_tf-backend-s3-bucket : bucket-to-store-tfstate-of-hello-iac-sample

Release to inventory

Use the release to inventory user script stage to add artifacts to the inventory by using the cocoa inventory add CLI command. For more information about cocoa inventory add, see cocoa inventory add.

You can use the pipelinectl interface to access your repos and artifacts by using the list_repos, load_repo, list_artifacts, and load_artifact commands. For more information, see pipelinectl.

Collecting compliance data on build

When the pipeline runs successfully, you can collect information about the build.

Evidence is collected on all checks, scans, tests, and artifact signings and is placed into the evidence locker. The pipeline log files are also saved to the locker, along with the pipeline data itself, containing the Tekton definitions. Compliance data on peer reviews is also collected in this step. The pipeline uses pipelinectl to search for repos with pull requests that were merged since the last build. The pipeline also checks PR review status, saves it as an artifact, and creates evidence based on the result.

The final script is an evaluator, which marks the pipeline status green or red, based on the evidence statuses. If there are any failures, the continuous integration run is marked as red.