DEV Community

Cover image for DevSecOps with AWS- IaC at scale - Building your own platform - Part 1

DevSecOps with AWS- IaC at scale - Building your own platform - Part 1

level 300

Today, the things change rapidly, the landscape and ecosystem are more complex, according to the infrastructure maturity path the application centric approach is closer and concepts as Infrastructure from code, composition as Code emerging and show a next generation for cloud automation. Tools based on generative IA, code companions, and the construction of custom platform based on custom "code warehouse" are the normal in many organizations, create the self-service capabilities and construct platform engineering teams is a trend for the next mounts and years. Wherever, the energy should be concentrated in supply the business requirements through the developer’s enablement securely, without lose control, flexibility, and scalability.

Infrastructure maturity Path

For other hand, many workloads could be deployed in a sequential way due to the hierarchy resources, typically first each layer of the infrastructure is deployed and after the application, however the modern cloud automation the application and infrastructure are interwoven and serverless deployments, event driven architectures, data analytics architectures, and others translate de responsibility to the builder and convert the infrastructure resources provisioning in the less relevant part.

The following image depicts this situation and a high level model guide where the integration of tools as Amazon Codewhisperer, Amazon Q improve and enablement the practice adoption and productivity.

Image description

According to the Well architected framework- Operational Excellent Pillar and the previous blog the operational approach in this series consists in Separated Application Engineering and Operations (AEO) and Infrastructure Engineering and Operations (IEO) with centralized governance and an internal service provider consulting partner.

In consonance with the first part, it’s time to create the pipeline based on the artifacts and guidelines supplied by the Cloud Operations and Platform Enablement Team (COPE).

There are many approaches for building a custom platform using opensource tools or commercial services like AWS CodeCatalyst, an integrated DevOps service for software development teams adopting continuous integration and deployment practices into their software development process. On the other hand, you can build a complete suite for custom deployments based on services such as CodeBuild, CodeCommit, Codepipeline, CodeDeploy, Service Catalog, AWS Proton, Cloud9 and other tools and services. For this post you will provide a DevSecOps as a Service to the builders’ team based on these tools, to wit, the hard way 👽.

Solution Overview


  • cdk >= 2.133.0
  • AWS CLI >= 2.7.0
  • Python >= 3.10.4

AWS Services

DevSecOpsIaCBluePrint AWS
Here the summary of the main steps.

  • First, create a custom CodeBuild Image for CodePipeline projects and publish into ECR in a shared account. It contains the predefine versions, tools, and requirements for your deployments according to the use case: IaC or any other Application.

  • Second, create a SaaS model to deploy your standard pipelines in other DevSecOps accounts. Using CDK Pipelines for this approach. In the future post you can enable the self-service capabilities for now just focusing on the platform’s bases.
    Here you could be thinking, why should you use CDK to define a terraform pipeline or another kind of pipeline in AWS? Because in this model you can take advantage of scalability, control and delivery model like internal SaaS department, this approach is util because the scenario is a devsecops in a product team with many microservices and builders’ team. In contrast with other approach the pipeline here is define as a product, not just like a central library definition in yaml, o code library.

  • Third, test your pipeline in a sandbox account with an infrastructure pattern or common use case in your organization.

  • Fourth, define the base for storage tfstate, single or many buckets per project, consider the number of microservices or infrastructure components and layers, mono repo, or multiples repos, perhaps, stacks or micro stacks for manage the infrastructure resources.

  • Fifth, Certified and approve your changes for deploy pipelines into production accounts.

  • Sixth, deploy a production workload with many stages and environments.

  • Seventh, the product pipeline runs, and the services are deployed in the specified environment.

Now, hands on with the first step, create a custom CodeBuild image for IaC deployments.

Based on public repository for Codebuild Image, the image base will be the Ubuntu standard 7.0.

Here the Dockerfile is modified removing runtimes unnecessary and installing the custom tools for your deployments. For example, installing terraform specific version, terragrunt, tfswitch, terramate and other tools and package.

#************************** Terraform *************************************
RUN set -ex \
    && curl -O${TERRAFORM_VERSION}/terraform_${TERRAFORM_VERSION} && unzip terraform_${TERRAFORM_VERSION}  -d /usr/local/bin/
RUN set -ex \
    && mkdir -p $HOME/.terraform.d/plugin-cache && echo 'plugin_cache_dir   = "$HOME/.terraform.d/plugin-cache"' > ~/.terraformrc

#************************* Terragrunt *************************************
RUN set -ex \
     && wget${TERRAGRUNT_VERSION}/terragrunt_linux_amd64 -q \
     && mv terragrunt_linux_amd64 /usr/local/bin/terragrunt \
     && chmod +x /usr/local/bin/terragrunt

#*********************** Terramate ****************************************
RUN set -ex \
     && wget${TERRAMATE_VERSION}/terramate_${TERRAMATE_VERSION}_linux_x86_64.tar.gz \
      && tar -xzf terramate_${TERRAMATE_VERSION}_linux_x86_64.tar.gz \
      && mv terramate /usr/local/bin/terramate \
      && chmod +x /usr/local/bin/terramate

#*********************** tfsec ********************************************
RUN set -ex \
      && wget${TFSEC_VERSION}/tfsec-linux-amd64 \
      && mv tfsec-linux-amd64 /usr/local/bin/tfsec \
      && chmod +x /usr/local/bin/tfsec \
      && terragrunt --version

#**********************Terraform docs ************************************
RUN set -ex \
    && curl -sSLo ./terraform-docs.tar.gz${TERRRAFORM_DOCS_VERSION}/terraform-docs-v${TERRRAFORM_DOCS_VERSION}-$(uname)-amd64.tar.gz \
    && tar -xzf terraform-docs.tar.gz \
    && chmod +x terraform-docs \
    && mv terraform-docs /usr/local/bin/terraform-docs

#********************* ShellCheck *****************************************
RUN set -ex \
      && wget -qO- "${SHELLCHECK_VERSION?}/shellcheck-${SHELLCHECK_VERSION?}.linux.x86_64.tar.xz"  | tar -xJv \
      && cp "shellcheck-${SHELLCHECK_VERSION}/shellcheck" /usr/bin/ \
      && shellcheck --version

Enter fullscreen mode Exit fullscreen mode

ℹ️ For this case the image could be robust and with biggest size in comparison to the application image due the specific use case.

ℹ️ Also can take long time for building.

Finally, according to the previous posts you can use the same approach to deploy in multienvironment as is depicted in the following image.

CodeBuild Image Deployment

Also, it shows a cross account pipeline using AWS CodePipeline, AWS CodeCommit, AWS Codebuild and AWS CloudFormation. This pipeline is created with CDK Pipelines.

1- The changes are detected and activate the pipeline. For this demo the branch main is the default branch.

2-The CDK project is synthesized if is aligned with AWS Security Best practices.

3-The pipeline run self-update action.

4-The unit test runs, and its report is published in codebuild reports group.

5-The SAST runs, and its report is published in codebuild reports group.

6-The Cloudformation stack is prepared for shared environment.

7-The Cloudformation stack is deployed for shared environment after success result from Cloudformation hooks, this create ECR repository and put the custom resources policies for different scenarios (Codebuild projects, organization units and individual accounts).

8-To move to other step a manual approval step is added, the notification is sent to slack channel.

9-The image is created and publish to ECR Repository and shared according to parameters in environment_options.yaml.

A shared parameter store publishes the stable version of the base image for other accounts or organizational units. This invitation could be accepted with AWS CLI o with another IaC stack in destination account.

Resource shared invitation accept

Get the code here - ⬇️⬇️

GitHub logo velez94 / cdkv2_devsecops_iac_codebuild_image

Codebuild image for devsecops IaC deployments using tools like terraform, terragrunt, terramate and more

Table of Contents

CodeBuild DevSecOps Container Image for IaC Deployments

AWS Services

Thanks for reading and sharing! 😃

Top comments (0)