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.

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.

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

Requirements

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

AWS Services

• AWS Cloud Development Kit (CDK): is an open-source software development framework to define your cloud application resources using familiar programming languages.
• AWS Identity and Access Management (IAM): Securely manage identities and access to AWS services and resources.
• AWS IAM Identity Center (Successor to AWS Single Sign-On): helps you securely create or connect your workforce identities and manage their access centrally across AWS accounts and applications.
• AWS CodeBuild: fully managed continuous integration service that compiles source code, runs tests, and produces software packages that are ready to deploy.
• AWS CodePipeline: fully managed continuous delivery service that helps you automate your release pipelines for fast and reliable application and infrastructure updates.
• AWS Key Management Service (AWS KMS): lets you create, manage, and control cryptographic keys across your applications and more than 100 AWS services.
• AWS CloudFormation: Speed up cloud provisioning with infrastructure as code.
• AWS Resource Access Manager: Simply and securely share your AWS resources across multiple accounts.

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 *************************************
ARG TERRAFORM_VERSION=1.7.3
RUN set -ex \
    && curl -O https://releases.hashicorp.com/terraform/${TERRAFORM_VERSION}/terraform_${TERRAFORM_VERSION}_linux_amd64.zip && unzip terraform_${TERRAFORM_VERSION}_linux_amd64.zip  -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 *************************************
ARG TERRAGRUNT_VERSION=0.55.1
RUN set -ex \
     && wget https://github.com/gruntwork-io/terragrunt/releases/download/v${TERRAGRUNT_VERSION}/terragrunt_linux_amd64 -q \
     && mv terragrunt_linux_amd64 /usr/local/bin/terragrunt \
     && chmod +x /usr/local/bin/terragrunt

#*********************** Terramate ****************************************
ARG TERRAMATE_VERSION=0.4.5
RUN set -ex \
     && wget https://github.com/mineiros-io/terramate/releases/download/v${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 ********************************************
ARG TFSEC_VERSION=1.28.5
RUN set -ex \
      && wget https://github.com/aquasecurity/tfsec/releases/download/v${TFSEC_VERSION}/tfsec-linux-amd64 \
      && mv tfsec-linux-amd64 /usr/local/bin/tfsec \
      && chmod +x /usr/local/bin/tfsec \
      && terragrunt --version

#**********************Terraform docs ************************************
ARG TERRRAFORM_DOCS_VERSION=0.17.0
RUN set -ex \
    && curl -sSLo ./terraform-docs.tar.gz https://terraform-docs.io/dl/v${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 *****************************************
ARG SHELLCHECK_VERSION="stable"
RUN set -ex \
      && wget -qO- "https://github.com/koalaman/shellcheck/releases/download/${SHELLCHECK_VERSION?}/shellcheck-${SHELLCHECK_VERSION?}.linux.x86_64.tar.xz"  | tar -xJv \
      && cp "shellcheck-${SHELLCHECK_VERSION}/shellcheck" /usr/bin/ \
      && shellcheck --version
...

ℹ️ 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.

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.

Get the code here - ⬇️⬇️

Thanks for reading and sharing! 😃