DEV Community: josepraveen

Using cfn-lint to Detect CloudFormation Misconfigurations in AWS CodePipeline

josepraveen — Tue, 26 May 2026 14:16:39 +0000

In this tutorial, you'll learn how to integrate cfn-lint into an AWS CI/CD workflow using Amazon Web Services CodePipeline and CodeBuild. By the end, you'll have a governance stage in your pipeline that automatically validates CloudFormation templates before deployment.

We’ll cover:

Creating a compliant CloudFormation template
Validating templates locally with cfn-lint
Verifying the governance stage inside CodePipeline

Why Use cfn-lint?

cfn-lint is an open-source tool that validates AWS CloudFormation templates against AWS resource specifications and best practices.

It helps detect:

Syntax issues
Invalid resource properties
Misconfigured IAM permissions
Incorrect parameter usage
Security-related template mistakes

Clone the repository used in this lab:

cd && git clone https://github.com/pluralsight-cloud/Path-Proactive-Security-in-Your-AWS-CI-CD-Pipeline.git

Navigate to the lab directory:

cd Path-Proactive-Security-in-Your-AWS-CI-CD-Pipeline/4-lab-using-static-analysis-to-detect-cloudformation-misconfigurations

Objective 1: Introduce a Compliant Template

First, verify the pre-existing AWS resources.

Verify the S3 Bucket

Open Amazon S3 and locate the bucket that starts with:

governance-lab-artifacts-

You should notice:

The bucket is empty
Versioning is enabled

Save the bucket name for later.

Verify the Pipeline

Open AWS CodePipeline and locate:

governance-pipeline

The pipeline should currently be in a failed state.

Verify the stages exist in this order:

Source
GovernanceLint
Deploy

Update the CloudFormation Template

Open the template file:

vim infra/template.yml

Uncomment the IAM role section:

:46,$s/# //g

Alternatively, paste the following IAM role resource:

NewRole:
  Type: AWS::IAM::Role
  Properties:
    RoleName: governance-lab-test-role
    AssumeRolePolicyDocument:
      Version: "2012-10-17"
      Statement:
        - Effect: Allow
          Principal:
            Service: ec2.amazonaws.com
          Action: sts:AssumeRole
    Policies:
      - PolicyName: compliant-s3-limited-access
        PolicyDocument:
          Version: "2012-10-17"
          Statement:
            - Effect: Allow
              Action:
                - s3:GetObject
                - s3:ListBucket
                - s3:PutObject
              Resource:
                - !Sub "arn:aws:s3:::governance-lab-artifacts-${AWS::AccountId}-${AWS::Region}-an/*"
                - !Sub "arn:aws:s3:::governance-lab-artifacts-${AWS::AccountId}-${AWS::Region}-an"

Save and exit:

:wq!

This IAM role allows EC2 instances to assume the role and access specific S3 bucket actions with limited permissions.

Objective 2: Validate Templates Locally

Before integrating linting into the pipeline, validate the template locally.

Install cfn-lint

Run:

pip install cfn-lint pyyaml boto3

Verify installation:

cfn-lint --version

Example output:

Lint the Template

Run:

cfn-lint -f pretty infra/template.yml

If the template is valid, you'll see output indicating:

0 errors

Objective 3: Update the CodeBuild Configuration

Next, integrate cfn-lint into the pipeline’s governance stage.

Open the buildspec file:

vim configuration/buildspec.yml

Delete the existing content:

:1,20d

Uncomment the remaining lines:

:1,$s/# //g

What This BuildSpec Does

The updated buildspec introduces two phases:

Install Phase

Installs:

cfn-lint
PyYAML
boto3

Build Phase

Runs lint validation against every YAML template inside the infra directory.

If linting fails, the pipeline stops immediately before deployment.

This creates an automated governance gate inside the CI/CD process.

Objective 4: Verify the Governance Stage

Now upload the updated artifacts to trigger the pipeline.

Zip the Project Files

cd ~/Path-Proactive-Security-in-Your-AWS-CI-CD-Pipeline/4-lab-using-static-analysis-to-detect-cloudformation-misconfigurations

zip -r artifacts.zip infra configuration

Upload to Amazon S3

aws s3 cp artifacts.zip s3://<YOUR_BUCKET_NAME_GOES_HERE>/

Verify Pipeline Execution

Navigate back to AWS CodePipeline and monitor:

governance-pipeline

You should observe:

GovernanceLint stage executes successfully
Deploy stage completes successfully
CloudFormation stack deployment succeeds

Inside the GovernanceLint logs, you'll see:

cfn-lint --version
cfn-lint -f pretty infra/**/*.yml

with no validation errors.

Verify CloudFormation Resources

Open the deployed CloudFormation stack:

governance-lab-deploy

Under the Resources tab, you should see:

AppSecurityGroup
NewRole

This confirms the compliant template passed validation and deployed successfully.

Testing a Failure Scenario (Optional)

To test the governance controls, intentionally introduce a template error.

Update:

FromPort: 443

to:

FromPort: HTTPS

Rebuild and upload the artifacts again:

zip -r artifacts.zip infra configuration
aws s3 cp artifacts.zip s3://<YOUR_BUCKET_NAME_GOES_HERE>/

This time, the GovernanceLint stage should fail, and CodeBuild logs will display the cfn-lint validation error.

This proves the governance stage is actively blocking malformed infrastructure templates from deployment.

Benefits of Adding cfn-lint to AWS CodePipeline

Integrating cfn-lint into your CI/CD pipeline provides several advantages:

Early detection of template errors
Improved infrastructure security
Faster deployment troubleshooting
Consistent infrastructure governance
Reduced production deployment failures

Most importantly, it shifts validation left — catching issues before they ever reach AWS CloudFormation deployment stages.

https://www.pluralsight.com/labs/aws/using-static-analysis-to-detect-cloudformation-misconfigurations

Deploy a Secure Containerized App on Amazon ECS Fargate Using ECR and Secrets Manager

josepraveen — Tue, 26 May 2026 07:36:33 +0000

Deploy a Secure Containerized App on Amazon ECS Fargate Using ECR and Secrets Manager

In this hands-on guide, you'll learn how to:

✅ Build and containerize a Python application
✅ Push Docker images to Amazon ECR
✅ Deploy containers on ECS Fargate
✅ Configure least-privilege IAM roles
✅ Inject secrets securely using AWS Secrets Manager
✅ Verify logs using CloudWatch

By the end, you'll have a production-style ECS deployment pipeline running entirely on AWS.

🚀 Architecture Overview

We'll use the following AWS services:

Amazon ECR → Store container images
Amazon ECS Fargate → Run serverless containers
AWS IAM → Secure task permissions
AWS Secrets Manager → Store secrets securely
Amazon CloudWatch Logs → Monitor container logs

Step 1 — Clone the Application Repository

Open AWS CloudShell from the AWS Console and clone the repository:

git clone https://github.com/pluralsight-cloud/Lab-Secure-Container-Deployment-on-ECS-Fargate.git

cd Lab-Secure-Container-Deployment-on-ECS-Fargate

Inspect the application files:

cat app.py
cat Dockerfile

Step 2 — Authenticate Docker to Amazon ECR

Set your AWS account variables:

ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

REGION=us-east-1

Authenticate Docker with ECR:

aws ecr get-login-password --region $REGION | docker login \
--username AWS \
--password-stdin \
$ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com

You should see:

Login Succeeded

Step 3 — Build and Push the Docker Image

Build the image:

docker build -t secure-fargate-app .

If you're using Apple Silicon (M1/M2/M3), use:

docker build --platform linux/amd64 -t secure-fargate-app .

Tag the image:

docker tag secure-fargate-app:latest \
$ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/secure-fargate-app:latest

Push the image:

docker push \
$ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/secure-fargate-app:latest

Step 4 — Verify the Image in Amazon ECR

Navigate to:

Amazon ECR → Repositories → secure-fargate-app

Step 5 — Create the ECS Task Execution Role

Go to:

IAM → Roles → Create Role

Choose:

Trusted entity: AWS Service
Use case: Elastic Container Service Task

Attach the policy:

AmazonECSTaskExecutionRolePolicy

Role name:

ecsTaskExecutionRole

Step 6 — Allow ECS to Read Secrets Manager

Add an inline policy to the execution role:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "*"
    }
  ]
}

Policy name:

SecretsManagerReadAccess

In production, always scope permissions to specific secret ARNs.

Step 7 — Create the ECS Task Role

Create another IAM role:

ecsTaskRole

This role intentionally has no permissions because the application does not call AWS services directly.

This is a great example of the principle of least privilege.

Step 8 — Create the ECS Task Definition

Go to:

Amazon ECS → Task Definitions → Create with JSON

Paste the following JSON:

{
  "family": "secure-fargate-app",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "executionRoleArn": "arn:aws:iam::ACCOUNT_ID:role/ecsTaskExecutionRole",
  "taskRoleArn": "arn:aws:iam::ACCOUNT_ID:role/ecsTaskRole",
  "containerDefinitions": [
    {
      "name": "secure-fargate-app",
      "image": "ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/secure-fargate-app:latest",
      "essential": true,
      "secrets": [
        {
          "name": "DB_CREDENTIALS",
          "valueFrom": "arn:aws:secretsmanager:us-east-1:ACCOUNT_ID:secret:prod/db-credentials"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/secure-fargate-app",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ]
}

Replace:

ACCOUNT_ID

with your actual AWS account ID.

🔐 Why Secrets Manager Matters

Instead of hardcoding secrets inside:

Docker images
Environment files
Git repositories

ECS securely injects secrets at runtime using:

"valueFrom": "arn:aws:secretsmanager:..."

This keeps credentials out of source control and container layers.

Step 9 — Deploy the ECS Fargate Service

Go to:

Amazon ECS → Clusters → lab-cluster → Services → Create

Use the following settings:

Setting	Value
Launch Type	Fargate
Task Definition	secure-fargate-app
Service Name	secure-fargate-svc
Platform Version	LATEST

Networking

Setting	Value
VPC	lab-vpc
Subnets	lab-public-subnet-1, lab-public-subnet-2
Public IP	Enabled

Create a security group:

fargate-sg

Inbound rule:

HTTP → Anywhere

For demo purposes only. Restrict inbound traffic properly in production environments.

Step 10 — Verify the Running Task

Open:

ECS → Clusters → lab-cluster → Services

If the task stops unexpectedly:

Verify IAM role ARNs
Check the ECR image URI
Ensure Secrets Manager permissions exist

Step 11 — Validate Secret Injection in CloudWatch

Navigate to:

CloudWatch → Logs → Log Groups → /ecs/secure-fargate-app

Open the latest log stream.

You should see:

[OK] Secret successfully injected via Secrets Manager!

This confirms:

✅ ECS resolved the secret
✅ Secrets Manager integration works
✅ The container received the environment variable securely

🎯 What You Learned

In this project, you successfully:

Built a Docker image
Stored it in Amazon ECR
Deployed it to ECS Fargate
Applied least-privilege IAM roles
Injected secrets securely
Verified runtime logs in CloudWatch

This workflow reflects real-world AWS container deployment patterns used in production environments.

https://www.pluralsight.com/labs/aws/secure-container-deployment-on-ecs-fargate
https://github.com/pluralsight-cloud/Lab-Secure-Container-Deployment-on-ECS-Fargate