Gatekeep CodeCatalyst Workflow using Approval

In some use cases, our CI/CD pipeline or workflow may need to be validated before code can be deployed.

Refer to this announcement "Workflow approvals for Amazon CodeCatalyst", Amazon CodeCatalyst, now has released feature called approval gates which can be utilized so that workflow can be paused until user with privilege can validate the workflow and whether workflow is approved and can be processed or not.

More details regarding Approval in CodeCatalyst can be read on this documentation: Approval Gate.

Table of Contents

1. Scenario
2. Prerequisites
3. Configuration Steps
   • Directory Structure
   • CodeCatalyst Workflow File Configurations
   • Example of Approval Process in CodeCatalyst Workflow
4. Summary

Scenario

This blog is related with my previous blog "CI/CD Pipeline for Terraform Workflow Using Amazon CodeCatalyst". In my previous blog, in workflow/pipeline, when terraform plan has finished and will continue to terraform apply, there is a process in between where pipeline will wait for 1 minute to check the terraform plan output and if the plan is not expected, we need to cancel the workflow manually. The difficulty that faced back then is because there was no out of the box solution provided by CodeCatalyst to restrict whether shifting between one action to other action can be cancelled if there is unexpected result.

In this blog, i will make an update which between terraform plan and terraform apply action, there will be an approval action. The goal if the plan is not expected, we can cancel the workflow and terraform apply will not be processed.

Here is the diagram that used in this blog:

Prerequisites

Here is the prerequisite that needed to follow configurations discussed in this blog:

• CodeCatalyst space and project that has been connected with AWS account and source repository. In this blog, I use GitHub as source repository. For configuration reference, please check my other blog “Build and Release Container Image to Amazon Elastic Container Registry (ECR) via Amazon CodeCatalyst”

Configuration Steps

Directory Structure

Below is directory structure used in this blog:

.
├── .codecatalyst/
│   └── workflows/
│       └── tf-sandbox-sbx0-vpc.yml
└── sandbox/
    └── sbx0/
        └── vpc/
            ├── backend.tf  
            ├── main.tf
            ├── terraform.tfvars
            └── variables.tf

CodeCatalyst Workflow File Configurations

Here is the configuration of CodeCatalyst workflow file that written in file ./codecatalyst/workflows/tf-sandbox-sbx0-vpc.yml

Name: tf-sandbox-sbx0-vpc
SchemaVersion: "1.0"

Triggers:
  - Type: PUSH
    Branches:
      - master
    FilesChanged:
      - sandbox\/sbx0\/vpc\/.*

Actions:
  terraform-plan:
    Identifier: aws/build@v1
    Inputs:
      Sources:
        - WorkflowSource
    Environment:
      Name: sandbox
      Connections:
        - Name: lanandra-sandbox
          Role: codecatalyst-admin
    Configuration:
      Container:
        Registry: DockerHub
        Image: hashicorp/terraform:1.8.2
      Steps:
      - Run: cd sandbox/sbx0/vpc
      - Run: terraform fmt -check -no-color
      - Run: terraform init -no-color
      - Run: terraform validate -no-color
      - Run: terraform plan -no-color -input=false
    Compute:
      Type: EC2
  wait-for-approval:
    Identifier: aws/approval@v1
    DependsOn:
      - terraform-plan
    Configuration:
      ApprovalsRequired: 1
  terraform-apply:
    DependsOn:
      - wait-for-approval
    Identifier: aws/build@v1
    Inputs:
      Sources:
        - WorkflowSource
    Environment:
      Name: sandbox
      Connections:
        - Name: lanandra-sandbox
          Role: codecatalyst-admin
    Configuration:
      Container:
        Registry: DockerHub
        Image: hashicorp/terraform:1.8.2
      Steps:
      - Run: cd sandbox/sbx0/vpc
      - Run: terraform init -no-color
      - Run: terraform apply -auto-approve -no-color -input=false
    Compute:
      Type: EC2

Next, I will explain more detail each sections that defined on workflow file above:

1. Define workflow name. Then define how workflow will be ran. Workflow will be ran automatically if there is a push to repository, specifically to directory sandbox/sbx0/vpc
   

   Name: tf-sandbox-sbx0-vpc
   SchemaVersion: "1.0"
   
   Triggers:
     - Type: PUSH
       Branches:
         - master
       FilesChanged:
         - sandbox\/sbx0\/vpc\/.*
   

2. Define action. First action will run workflow terraform plan. In this section, action uses identifier aws/build@v1. Then action will be ran on sandbox environment that has been connected with AWS account and also has IAM role associated with that account. In Configuration section, has been defined that action will be ran on top of container using specific version of terraform public image that pulled from DockerHub. Also has defined working directory and several terraform commands which include terraform plan. Lastly, define compute type which is EC2
   

   Actions:
     terraform-plan:
       Identifier: aws/build@v1
       Inputs:
         Sources:
           - WorkflowSource
       Environment:
         Name: sandbox
         Connections:
           - Name: lanandra-sandbox
             Role: codecatalyst-admin
       Configuration:
         Container:
           Registry: DockerHub
           Image: hashicorp/terraform:1.8.2
         Steps:
         - Run: cd sandbox/sbx0/vpc
         - Run: terraform fmt -check -no-color
         - Run: terraform init -no-color
         - Run: terraform validate -no-color
         - Run: terraform plan -no-color -input=false
       Compute:
         Type: EC2
   

3. Next action is wait-for-approval. Goal of this action is to verify workflow can be ran to next action if there is an approval from privileged user(s). This action is using identifier aws/approval@v1 and depends on previous action which is terraform-plan. This action need at least 1 privileged user approval so that next action can be ran.
   

   wait-for-approval:
       Identifier: aws/approval@v1
       DependsOn:
         - terraform-plan
       Configuration:
         ApprovalsRequired: 1
   

4. Next action that defined is action to run terraform apply. This action more or less similar with action terraform-plan, the difference is just terraform command that declared on configuration. In this section, action will run commands that needed for terraform apply. This action is depends on previous action which is wait-for-approval
   

   terraform-apply:
       DependsOn:
         - wait-for-approval
       Identifier: aws/build@v1
       Inputs:
         Sources:
           - WorkflowSource
       Environment:
         Name: sandbox
         Connections:
           - Name: lanandra-sandbox
             Role: codecatalyst-admin
       Configuration:
         Container:
           Registry: DockerHub
           Image: hashicorp/terraform:1.8.2
         Steps:
         - Run: cd sandbox/sbx0/vpc
         - Run: terraform init -no-color
         - Run: terraform apply -auto-approve -no-color -input=false
       Compute:
         Type: EC2
   

Example of Approval Process in CodeCatalyst Workflow

I have defined Terraform codes that will be used as example in this blog. Files can be found in this GitHub path: https://github.com/lanandra/mock-aws-infrastructure/tree/master/sandbox/sbx0/vpc

Existing main.tf configuration:

#######
# VPC #
#######


data "aws_availability_zones" "available" {}

locals {
  azs = slice(data.aws_availability_zones.available.names, 0, 3)

  tags = {
    "environment" = "${var.env_name}"
    "managedBy"   = "terraform"
  }
}

module "sbx0_apse1" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.8.1"

  name = var.env_name
  cidr = var.vpc_cidr

  azs             = local.azs
  private_subnets = [for k, v in local.azs : cidrsubnet(var.vpc_cidr, 8, k)]
  public_subnets  = [for k, v in local.azs : cidrsubnet(var.vpc_cidr, 8, k + 3)]

  enable_nat_gateway = false
  single_nat_gateway = true

  tags = local.tags
}

Here are the configuration steps:

1. Change Terraform configuration. Enable NAT gateway in VPC
   

   enable_nat_gateway = true
   

2. As defined in workflow file, all changes inside directory sandbox/sbx0/vpc will trigger workflow run. Go to CodeCatalyst web console to verify. Go to space and project where workflow ran. Go to CI/CD menu, then choose Workflows. Verify there is new runs. Go to that runs

   

3. Go to run details by clicking name or run. Next, we will be redirected to overview page of that run. Click action terraform-plan, on the right side will appear tray box that display all steps that configured on that action. If we want to see details of terraform plan, go to tab log, then click step terraform plan -no-color -input-false. Verify action is succeeded

   

4. Next, action wait-for-approval will be ran and waiting input from privileged user, whether workflow run can be approved or not

   

5. Choose approve then click submit

   

6. If pop-up approval appeared, click Confirm to continue workflow

   

7. We also can see the status of approval, whether it has been approved or rejected

   

8. After approval has been approved, next action will be ran where in this blog example is terraform apply. Verify terraform apply is succeeded

   

Summary

We have reached the last section of this blog. Here are some key takeaways that can be summarized:

• In some use cases, maybe we will find condition where we will need approval before deployment in CI/CD pipeline can be done
• CodeCatalyst have approval feature that can gatekeep deployment in CI/CD

Please comment if you have any suggestions, critiques, or thoughts.

Hope this article will benefit you. Thank you!