In this article, we'll explore five powerful open-source security tools that cover your entire stack: GitHub CodeQL for code analysis, Dependabot for dependency management, Terrascan for Infrastructure as Code, Trivy for container scanning, and OWASP ZAP for dynamic testing.

1. GitHub CodeQL: Static Application Security Testing (SAST)

What It Does

CodeQL is GitHub's powerful semantic code analysis engine that treats code as data. Unlike traditional static analysis tools that rely on pattern matching, CodeQL allows you to write queries that can identify complex security vulnerabilities and coding patterns across your entire codebase.

Key Features

• Multi-language support: Works with JavaScript, TypeScript, Python, Java, C/C++, C#, Go, Ruby, and more

• Deep semantic analysis: Understands code structure and data flow, not just syntax

• Customizable queries: Write your own security queries or use the extensive community library

• CI/CD integration: Seamlessly integrates with GitHub Actions and other CI systems

Setting Up CodeQL

GitHub makes it incredibly easy to enable CodeQL through the UI without writing any workflow files:

1. Navigate to your repository on GitHub

2. Go to the Settings tab

3. Click on Code security and analysis in the left sidebar

4. Under "Code scanning", click Set up next to CodeQL analysis

5. Choose Default setup for automatic configuration

6. Select the languages you want to scan

7. Click Enable CodeQL

GitHub will automatically create scanning workflows and start analyzing your code on every push and pull request.

Enable Secret Scanning

While you're in the Code security settings, enable secret scanning to prevent accidental exposure of credentials:

1. Under "Secret scanning", enable:

   • Secret scanning: Detects secrets that have been committed to your repository

   • Push protection: Blocks commits containing supported secrets before they reach your repository

Push protection is crucial—it prevents developers from accidentally committing API keys, tokens, passwords, and other credentials. When a push containing a secret is blocked, GitHub provides guidance on how to remove it safely.

Reviewing CodeQL Alerts

Once enabled, CodeQL will scan your repository and display any security vulnerabilities it finds:

Each alert provides:

• Detailed vulnerability description

• Affected code location with highlighted lines

• Severity level (Critical, High, Medium, Low)

• Remediation guidance and fix suggestions

• Ability to dismiss false positives with justification

Best Practices

• Enable CodeQL on all repositories, especially those handling sensitive data

• Review alerts regularly and triage them promptly—CodeQL provides detailed remediation guidance

• Use the "Dismissed" feature wisely—document why alerts are false positives

• Monitor the Security Overview dashboard for organization-wide security posture

2. Dependabot: Automated Dependency Management

What It Does

Dependabot automatically monitors your project dependencies for known security vulnerabilities and outdated packages. It creates pull requests to update vulnerable dependencies, complete with changelog information and compatibility assessments.

Key Features

• Vulnerability alerts: Real-time notifications about security issues in your dependencies

• Automated updates: Creates PRs to update vulnerable packages

• Version compatibility: Understands semantic versioning and suggests appropriate updates

• Multi-ecosystem support: Works with npm, pip, Maven, NuGet, Composer, and more

Enabling Dependabot

Like CodeQL, Dependabot can be enabled directly through GitHub's UI:

1. Go to your repository Settings

2. Navigate to Code security and analysis

3. Under "Dependabot", enable the following:

   • Dependabot alerts: Get notified about vulnerable dependencies

   • Dependabot security updates: Automatically create PRs to fix vulnerabilities

   • Dependabot version updates: Keep dependencies up-to-date (optional)

Managing Dependabot Alerts

Once enabled, Dependabot continuously monitors your dependencies:

The Dependabot alerts page shows:

• Vulnerable package name and affected versions

• CVE details and severity scores

• Which files are affected

• Available patched versions

• One-click option to create a security update PR

Security Impact

Third-party dependencies account for a massive portion of modern application code—often 80% or more. A single vulnerable package can compromise your entire application. Dependabot helps you maintain a secure supply chain by ensuring you're always running patched versions of your dependencies.

Best Practices

• Enable Dependabot security updates immediately—they're free on GitHub

• Set up automated testing to validate dependency updates before merging

• Configure grouped updates for related packages to reduce PR noise

• Review dependency changes carefully, especially major version bumps

3. Terrascan: Infrastructure as Code Security

What It Does

Terrascan is a static code analyzer for Infrastructure as Code that detects compliance and security violations before your cloud infrastructure is provisioned. It supports Terraform, Kubernetes, Helm, Dockerfiles, and more.

Key Features

• 500+ built-in policies: Covers CIS Benchmarks, NIST, PCI-DSS, GDPR, and more

• Multi-cloud support: Works with AWS, Azure, GCP, and Kubernetes

• Custom policies: Write your own rules using Rego (Open Policy Agent)

• CI/CD integration: Easy integration with popular CI platforms

Installation and Usage

# Install Terrascan
curl -L "$(curl -s https://api.github.com/repos/tenable/terrascan/releases/latest | grep -o -E "https://.+?_Linux_x86_64.tar.gz")" > terrascan.tar.gz
tar -xf terrascan.tar.gz terrascan && rm terrascan.tar.gz
sudo mv terrascan /usr/local/bin

# Scan Terraform code
terrascan scan -t terraform -d /path/to/terraform

# Scan with specific compliance framework
terrascan scan -t terraform -d . -p aws -i cis

# Generate SARIF output for GitHub
terrascan scan -t terraform -d . -o sarif > results.sarif

Integration Example

Add Terrascan to your CI pipeline:

# GitHub Actions
- name: Terrascan IaC Scanner
  uses: tenable/terrascan-action@main
  with:
    iac_type: 'terraform'
    iac_dir: 'infrastructure/'
    policy_type: 'aws'
    only_warn: false
    sarif_upload: true

Why IaC Security Matters

Misconfigured cloud resources are among the most common causes of data breaches. Public S3 buckets, overly permissive IAM roles, and exposed databases have led to countless security incidents. Terrascan catches these issues before infrastructure is deployed, preventing costly mistakes.

4. Trivy: Comprehensive Container Security

What It Does

Trivy is an all-in-one vulnerability scanner for containers, filesystems, and Git repositories. It detects vulnerabilities in OS packages, application dependencies, IaC misconfigurations, and even secrets accidentally committed to code.

Key Features

• Multiple scan targets: Container images, filesystems, repositories, Kubernetes clusters

• Comprehensive vulnerability database: Covers OS packages and language-specific dependencies

• Fast and accurate: Uses multiple data sources for high-quality results

• Secret detection: Finds API keys, passwords, and tokens in your code

• Kubernetes integration: Scan running workloads for vulnerabilities and misconfigurations

Basic Usage

# Install Trivy
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -
echo "deb https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main" | sudo tee -a /etc/apt/sources.list.d/trivy.list
sudo apt-get update
sudo apt-get install trivy

# Scan a container image
trivy image nginx:latest

# Scan with severity filtering
trivy image --severity HIGH,CRITICAL myapp:1.0.0

# Scan a filesystem
trivy fs /path/to/project

# Scan for secrets
trivy fs --scanners secret /path/to/repo

# Generate reports
trivy image --format json --output results.json myapp:latest

CI/CD Integration

# GitHub Actions example
- name: Run Trivy vulnerability scanner
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'myregistry/myapp:${{ github.sha }}'
    format: 'sarif'
    output: 'trivy-results.sarif'
    severity: 'CRITICAL,HIGH'

- name: Upload Trivy results to GitHub Security
  uses: github/codeql-action/upload-sarif@v2
  with:
    sarif_file: 'trivy-results.sarif'

Advanced Features

Trivy's versatility makes it invaluable for container security:

• SBOM generation: Create Software Bill of Materials for compliance

• Kubernetes operator: Continuously scan running containers in your cluster

• Policy enforcement: Fail builds based on custom vulnerability thresholds

• Air-gapped environments: Can run offline with downloaded vulnerability databases

5. OWASP ZAP: Dynamic Application Security Testing

What It Does

While the previous tools focus on static analysis, OWASP ZAP (Zed Attack Proxy) performs dynamic application security testing by actively probing your running application for vulnerabilities. It's the world's most popular web application security scanner.

Key Features

• Active and passive scanning: Detects vulnerabilities through both traffic analysis and active testing

• OWASP Top 10 coverage: Identifies injection flaws, XSS, authentication issues, and more

• API testing: Supports REST, SOAP, GraphQL, and WebSocket testing

• Extensible: Hundreds of add-ons available for specialized testing

• Automation-friendly: Excellent CLI and API support for CI/CD

Getting Started

# Run ZAP in Docker
docker pull zaproxy/zap-stable

# Baseline scan (passive)
docker run -t zaproxy/zap-stable zap-baseline.py -t https://yourapp.com

# Full scan (active)
docker run -t zaproxy/zap-stable zap-full-scan.py -t https://yourapp.com

# API scan
docker run -t zaproxy/zap-stable zap-api-scan.py -t https://api.yourapp.com/openapi.json -f openapi

CI/CD Integration

on: [push]

jobs:
  zap_scan:
    runs-on: ubuntu-latest
    name: Scan the webapplication
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          ref: master
      - name: ZAP Scan
        uses: zaproxy/action-full-scan@v0.12.0
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          docker_name: 'ghcr.io/zaproxy/zaproxy:stable'
          target: 'https://www.zaproxy.org/'
          rules_file_name: '.zap/rules.tsv'
          cmd_options: '-a'

Best Practices

• Start with baseline scans in staging environments

• Integrate ZAP early but configure it to not block deployments initially

• Use authenticated scans to test protected functionality

• Create custom scan policies that match your application's risk profile

• Review false positives and tune configurations over time

Building Your DevSecOps Pipeline

Now that we've covered individual tools, let's look at how they work together in a complete DevSecOps pipeline:

Development Phase

1. CodeQL scans code on every commit and pull request

2. Dependabot monitors dependencies and creates update PRs

3. Developers receive immediate feedback on security issues

Build Phase

1. Terrascan validates Infrastructure as Code before deployment

2. Trivy scans container images for vulnerabilities

3. Builds fail if critical vulnerabilities are detected

Testing Phase

1. OWASP ZAP performs dynamic security testing against staging environments

2. API security tests validate authentication and authorization

3. Security reports are generated and reviewed

Deployment Phase

1. Only passing builds with acceptable security posture are deployed

2. Runtime security monitoring begins (using tools like Falco or Sysdig)

3. Continuous scanning detects newly discovered vulnerabilities

Implementation Strategy

Don't try to implement everything at once. Here's a pragmatic rollout approach:

Week 1-2: Enable CodeQL and Dependabot on your most critical repositories. These have minimal overhead and provide immediate value.

Week 3-4: Integrate Trivy into your container build process. Start with warnings only, then gradually enforce policies.

Week 5-6: Add Terrascan to your IaC repositories. Begin with audit mode to understand your current security posture.

Week 7-8: Introduce OWASP ZAP for dynamic testing in staging environments. Initially run scans manually, then automate.

Ongoing: Tune configurations, reduce false positives, train team members, and expand coverage.

Measuring Success

Track these metrics to demonstrate the value of your DevSecOps implementation:

• Mean Time to Remediation (MTTR): How quickly vulnerabilities are fixed after discovery

• Vulnerability density: Number of vulnerabilities per thousand lines of code

• Security debt: Accumulation of known but unresolved security issues

• Shift-left effectiveness: Percentage of vulnerabilities caught before production

• False positive rate: Accuracy of security tools (aim for <10%)

Conclusion

Building a secure software delivery pipeline doesn't require expensive enterprise tools. The open-source ecosystem provides powerful, production-ready solutions that cover every layer of your stack—from source code to running containers.

By integrating CodeQL, Dependabot, Terrascan, Trivy, and OWASP ZAP into your development workflow, you create multiple defensive layers that catch security issues early and often. The key is starting small, measuring results, and continuously improving your security posture.

Remember: DevSecOps is a journey, not a destination. Begin with one or two tools, demonstrate value to your organization, and gradually expand your security automation. Your future self—and your security team—will thank you.

Additional Resources

• GitHub Security Lab

• Trivy Documentation

• Terrascan Policies

• OWASP ZAP User Guide

• DevSecOps Manifesto

Start securing your pipeline today—your code, your users, and your organization deserve it.

A Helm chart is a ZIP file containing:

1. Kubernetes YAML templates (Deployment, Service, etc.)

2. A values.yaml file with default configuration

3. A way to customize those templates

Think of it like:

• Template = A form with blank fields

• values.yaml = The default values to fill in those blanks

• Your custom values = Overriding those defaults

The Confusion: Templates vs Values

What Confuses People:

❓ "There's a Deployment template in the chart..."
❓ "There's a values.yaml with settings..."
❓ "How do these connect?"
❓ "What can I actually change?"
❓ "Where do I put MY configuration?"

The Answer (Visual):

HELM CHART (what the chart maintainers created)
│
├── templates/
│   ├── deployment.yaml          ← Template with {{ .Values.* }} placeholders
│   ├── service.yaml             ← Template with {{ .Values.* }} placeholders
│   └── configmap.yaml           ← Template with {{ .Values.* }} placeholders
│
└── values.yaml                  ← DEFAULT values that fill those placeholders
    image:
      repository: postgres
      tag: "15"
    persistence:
      enabled: true
      size: 8Gi

YOUR CUSTOM VALUES (what you provide)
│
└── my-values.yaml               ← YOUR values that OVERRIDE defaults
    image:
      tag: "16"                  ← Override: Use version 16 instead
    persistence:
      size: 20Gi                 ← Override: Use 20Gi instead of 8Gi

RESULT (what actually gets deployed)
│
└── Kubernetes YAML              ← Template filled with YOUR values
    apiVersion: apps/v1
    kind: Deployment
    spec:
      template:
        spec:
          containers:
          - image: postgres:16    ← From your my-values.yaml
            volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: postgres-pvc
    ---
    apiVersion: v1
    kind: PersistentVolumeClaim
    spec:
      resources:
        requests:
          storage: 20Gi           ← From your my-values.yaml

How to Actually Use a Helm Chart (Step by Step)

Step 1: Find the Chart

# Search for a chart
helm search hub postgresql

# Add the repository
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

Step 2: Look at What You Can Configure

# See ALL available options
helm show values bitnami/postgresql

# This outputs the ENTIRE values.yaml - save it!
helm show values bitnami/postgresql > default-values.yaml

What you see (example):

## @section Global parameters
global:
  imageRegistry: ""
  storageClass: ""

## @section Common parameters
architecture: standalone

## @section PostgreSQL Authentication parameters
auth:
  enablePostgresUser: true
  postgresPassword: ""
  username: ""
  password: ""
  database: ""

## @section PostgreSQL Primary parameters
primary:
  persistence:
    enabled: true
    storageClass: ""
    size: 8Gi

  resources:
    limits: {}
    requests:
      memory: 256Mi
      cpu: 250m

Step 3: Understand the Structure

The values.yaml has a HIERARCHY:

# Top level
auth:                    ← Top-level key
  username: "myapp"      ← Nested under 'auth'
  password: "secret"     ← Nested under 'auth'
  database: "mydb"       ← Nested under 'auth'

primary:                 ← Different top-level key
  persistence:           ← Nested under 'primary'
    enabled: true        ← Nested under 'persistence'
    size: 20Gi          ← Nested under 'persistence'
  resources:             ← Different nested key under 'primary'
    limits:              ← Nested under 'resources'
      cpu: 2000m         ← Nested under 'limits'

This maps to template placeholders:

# In the chart's templates/deployment.yaml (you don't edit this):
spec:
  containers:
  - name: postgresql
    image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
    env:
    - name: POSTGRES_USER
      value: {{ .Values.auth.username }}
    - name: POSTGRES_PASSWORD
      value: {{ .Values.auth.password }}
    - name: POSTGRES_DB
      value: {{ .Values.auth.database }}

When you provide:

# your-values.yaml
auth:
  username: "myapp"
  password: "secret123"
  database: "myappdb"

Helm renders it as:

spec:
  containers:
  - name: postgresql
    image: postgres:15
    env:
    - name: POSTGRES_USER
      value: myapp          ← YOUR value inserted here
    - name: POSTGRES_PASSWORD
      value: secret123      ← YOUR value inserted here
    - name: POSTGRES_DB
      value: myappdb        ← YOUR value inserted here

Step 4: Create Your Custom Values File

DON'T copy the entire default values.yaml!

DO only specify what you want to CHANGE:

# my-postgres-values.yaml

# Only include what you're changing!
auth:
  username: myapp
  password: mySecurePassword123
  database: myappdb

primary:
  persistence:
    size: 20Gi

  resources:
    limits:
      cpu: 2000m
      memory: 4Gi
    requests:
      cpu: 500m
      memory: 1Gi

Everything else uses the chart's defaults!

Step 5: Install the Chart

# Install with your custom values
helm install my-postgres bitnami/postgresql -f my-postgres-values.yaml

# Or install to specific namespace
helm install my-postgres bitnami/postgresql \
  --namespace database \
  --create-namespace \
  -f my-postgres-values.yaml

What happens:

1. Helm downloads the chart

2. Helm reads the chart's values.yaml (defaults)

3. Helm reads YOUR my-postgres-values.yaml (overrides)

4. Helm merges them (your values override defaults)

5. Helm fills the templates with the merged values

6. Helm applies the rendered YAML to Kubernetes

The Three Ways to Provide Values

Method 1: Values File (Recommended)

# Create my-values.yaml
cat > my-values.yaml <<EOF
auth:
  username: myapp
  database: myappdb
EOF

# Install with file
helm install postgres bitnami/postgresql -f my-values.yaml

Method 2: Command Line (Quick Testing)

# Set individual values via --set
helm install postgres bitnami/postgresql \
  --set auth.username=myapp \
  --set auth.database=myappdb \
  --set primary.persistence.size=20Gi

Method 3: Multiple Values Files (Advanced)

# Combine multiple files
helm install postgres bitnami/postgresql \
  -f base-values.yaml \
  -f production-overrides.yaml

# Later values override earlier ones

Common Confusion Points - SOLVED

Confusion 1: "What can I actually configure?"

Answer: Look at the default values.yaml

helm show values bitnami/postgresql > values.yaml
less values.yaml

# Search for what you need
grep -i "persistence" values.yaml
grep -i "resources" values.yaml
grep -i "password" values.yaml

If it's in values.yaml, you can configure it!

Confusion 2: "How do I know the correct structure?"

Answer: Copy the structure EXACTLY from values.yaml

# ❌ WRONG - flat structure
persistence.size: 20Gi

# ✅ CORRECT - nested structure (same as in values.yaml)
primary:
  persistence:
    size: 20Gi

Rule: Match the indentation/nesting from the default values.yaml

Confusion 3: "Do I need to specify everything?"

NO! Only specify what you want to change.

# ❌ Don't do this (500 lines)
# Copy entire values.yaml and modify a few lines

# ✅ Do this (10 lines)
# Only what you're changing
auth:
  username: myapp
  database: myappdb

Confusion 4: "What if I want to see the final YAML?"

# Dry-run: See what will be created WITHOUT installing
helm install postgres bitnami/postgresql \
  -f my-values.yaml \
  --dry-run \
  --debug

# This shows you the FINAL rendered Kubernetes YAML

Confusion 5: "How do I know if my values are valid?"

# Template: Render locally without installing
helm template postgres bitnami/postgresql -f my-values.yaml

# If it works, your values are valid
# If it fails, you'll see the error

Real Example: From Confusion to Clarity

Scenario: Deploy PostgreSQL

Step 1: Get Default Values

helm repo add bitnami https://charts.bitnami.com/bitnami
helm show values bitnami/postgresql > postgres-defaults.yaml

Step 2: Open and Search

# Open in your editor
code postgres-defaults.yaml

# Search for key sections (Ctrl+F):
# - "auth"          ← Authentication
# - "persistence"   ← Storage
# - "resources"     ← CPU/Memory
# - "initdb"        ← Initial scripts

Step 3: Find What You Need

In postgres-defaults.yaml you find:

## Authentication parameters
auth:
  ## @param auth.enablePostgresUser Assign a password to the "postgres" admin user
  enablePostgresUser: true
  ## @param auth.postgresPassword Password for the "postgres" admin user
  postgresPassword: ""
  ## @param auth.username Name for a custom user to create
  username: ""
  ## @param auth.password Password for the custom user to create
  password: ""
  ## @param auth.database Name for a custom database to create
  database: ""

And:

primary:
  ## PostgreSQL Primary persistence configuration
  persistence:
    ## @param primary.persistence.enabled Enable PostgreSQL Primary data persistence
    enabled: true
    ## @param primary.persistence.storageClass PVC Storage Class
    storageClass: ""
    ## @param primary.persistence.size PVC Storage Request
    size: 8Gi

Step 4: Create YOUR Values (Only What You Need)

# my-postgres-values.yaml

# Authentication (copied structure from defaults)
auth:
  username: myapp
  password: MySecurePass123
  database: myappdb

# Storage (copied structure from defaults)
primary:
  persistence:
    enabled: true
    storageClass: local-path  # K3s storage class
    size: 20Gi                # Changed from default 8Gi

# Resources (copied structure from defaults)
  resources:
    limits:
      cpu: 2000m
      memory: 4Gi
    requests:
      cpu: 500m
      memory: 1Gi

Step 5: Verify Before Installing

# See what will be created
helm template test-postgres bitnami/postgresql \
  -f my-postgres-values.yaml \
  --namespace database

# Look through the output - verify:
# - POSTGRES_USER = myapp ✓
# - POSTGRES_DB = myappdb ✓
# - PVC size = 20Gi ✓
# - CPU limits = 2000m ✓

Step 6: Install

helm install postgres bitnami/postgresql \
  -f my-postgres-values.yaml \
  --namespace database \
  --create-namespace

The Mental Model

┌─────────────────────────────────────────┐
│         HELM CHART (Package)            │
│  ┌────────────────────────────────┐    │
│  │  templates/                     │    │
│  │    deployment.yaml              │    │
│  │    service.yaml                 │    │
│  │    configmap.yaml               │    │
│  │                                 │    │
│  │  These have placeholders:       │    │
│  │    {{ .Values.auth.username }}  │    │
│  │    {{ .Values.persistence.size }}│   │
│  └────────────────────────────────┘    │
│                                         │
│  ┌────────────────────────────────┐    │
│  │  values.yaml (DEFAULTS)         │    │
│  │    auth:                        │    │
│  │      username: ""               │    │
│  │    persistence:                 │    │
│  │      size: 8Gi                  │    │
│  └────────────────────────────────┘    │
└─────────────────────────────────────────┘
                    │
                    │ You provide
                    ↓
┌─────────────────────────────────────────┐
│   YOUR VALUES (my-values.yaml)          │
│     auth:                               │
│       username: myapp  ← Override       │
│     persistence:                        │
│       size: 20Gi       ← Override       │
└─────────────────────────────────────────┘
                    │
                    │ Helm merges
                    ↓
┌─────────────────────────────────────────┐
│       FINAL RENDERED YAML               │
│   (Actually deployed to Kubernetes)     │
│                                         │
│   Deployment with:                      │
│     - username: myapp                   │
│     - PVC size: 20Gi                    │
└─────────────────────────────────────────┘

Quick Reference Commands

# Search for charts
helm search hub <chart-name>

# Add repository
helm repo add <name> <url>
helm repo update

# View chart info
helm show chart <repo>/<chart>

# View README
helm show readme <repo>/<chart>

# View default values (IMPORTANT!)
helm show values <repo>/<chart>
helm show values <repo>/<chart> > values.yaml

# Test your values without installing
helm template <name> <repo>/<chart> -f my-values.yaml
helm install <name> <repo>/<chart> -f my-values.yaml --dry-run --debug

# Install chart
helm install <name> <repo>/<chart> -f my-values.yaml
helm install <name> <repo>/<chart> -f my-values.yaml -n <namespace> --create-namespace

# Upgrade chart
helm upgrade <name> <repo>/<chart> -f my-values.yaml

# Check what's installed
helm list
helm list -n <namespace>

# Get values of installed release
helm get values <name>
helm get values <name> -n <namespace>

# Uninstall
helm uninstall <name>
helm uninstall <name> -n <namespace>

Key Takeaways

1. Chart = Templates + Default Values

2. You only configure values, NOT templates

3. Your values OVERRIDE defaults (you don't need to copy everything)

4. Match the EXACT structure from default values.yaml

5. Use helm show values to see what you can configure

6. Use helm template or --dry-run to verify before installing

7. Values hierarchy must match (indentation matters!)

Practice Exercise

Try this right now:

# 1. Get the default values
helm repo add bitnami https://charts.bitnami.com/bitnami
helm show values bitnami/nginx > nginx-defaults.yaml

# 2. Open and find these sections:
# - replicaCount
# - service.type
# - ingress.enabled

# 3. Create your own values file:
cat > my-nginx-values.yaml <<EOF
replicaCount: 3
service:
  type: NodePort
EOF

# 4. See what it will create:
helm template test bitnami/nginx -f my-nginx-values.yaml

# 5. If it looks good, install:
helm install mynginx bitnami/nginx -f my-nginx-values.yaml

Today we will look beyond terraform validate, plan and apply. While writing IaC, it is important to treat it like a code rather than just a bunch of tf files for spinning up the infrastructure.

Today in this article, I will focus on how to ensure clean IaC coding with required security measures by enforcing checks in the terraform pipeline.

Scenarios:

Now, there will be 3 actions we need to perform:

1. Terraform Plan (Triggers at: PR level)

2. Terraform Apply (Triggers at: Code merge in default branch)

3. Terraform Destroy (Trigger: Manual trigger)

In this article, we will focus on the Terraform plan part, which means checking the IaC at PR level (before applying the changes), because all the creativity will take place at this stage only. Rest both the stages (apply & destroy) will be plan and simple.

CICD Tool used:

For this lab, I will be using Github actions as the CICD tool. If you are using any other tool like Azure DevOps or Jenkins, you can use the same steps there as well.

Steps:

1. So the first thing in pipeline is specifying the trigger for the pipeline. Since this pipeline is for checking the code at PR level, the trigger will be set for PRs targeting the default branch.

    name: Terraform Plan
   
    on:
      pull_request:
        types:
          - opened
          - synchronize
          - reopened
        branches:
          - 'main'
   

2. Now starts the jobs, the first job will be for checking the code quality, possible errors, deprecated syntax, naming convention etc. For this, we will be using the open source tool TFlint.

    jobs:
      terraform-lint:
        name: TFLint
        runs-on: ubuntu-latest
        steps:
          - name: Checkout code
            uses: actions/checkout@v4
   
          - uses: terraform-linters/setup-tflint@v4
            name: Setup TFLint
            with:
              tflint_version: v0.53.0
   
          - name: Run TFLint
            run: tflint
            working-directory: infra
   

   Lets understand each step:

   • First, we are checking out the code.

   • Then, we are using the Github action to setup/install the Tflint tool. You can also do this by using simple bash command.

   • Finally, we are running the tflint command in the directory that contains the IaC.

3. Second job is for checking the code for security vulnerabilities, for this we will be using popular open source tool Trivy.

      tf-security-scan:
        name: trivy
        runs-on: ubuntu-latest
        steps:
          - name: Checkout code
            uses: actions/checkout@v4
   
          - name: Install trivy
            run: |
              sudo apt-get install wget apt-transport-https gnupg
              wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | gpg --dearmor | sudo tee /usr/share/keyrings/trivy.gpg > /dev/null
              echo "deb [signed-by=/usr/share/keyrings/trivy.gpg] https://aquasecurity.github.io/trivy-repo/deb generic main" | sudo tee -a /etc/apt/sources.list.d/trivy.list
              sudo apt-get update
              sudo apt-get install trivy
   
          - name: Run trivy
            run: trivy config .
            working-directory: infra
   

   Lets understand each step:

   • Checkout code.

   • Install Trivy.

   • Run Trivy in the source directory.

4. Once the security scan is successfully succeeded we will create a terraform plan, and post the plan in github PR comment. Commenting the terraform plan in PR will help the reviewer to overview the PR request quickly.

    terraform-plan:
      name: Terraform plan
      runs-on: ubuntu-latest
      needs: tf-security-scan
      permissions:
        contents: read
        pull-requests: write # Required to post comments
   
      env:
        ARM_CLIENT_ID: ${{ secrets.ARM_CLIENT_ID }}
        ARM_CLIENT_SECRET: ${{ secrets.ARM_CLIENT_SECRET }}
        ARM_SUBSCRIPTION_ID: ${{ secrets.ARM_SUBSCRIPTION_ID }}
        ARM_TENANT_ID: ${{ secrets.ARM_TENANT_ID }}
        TF_VAR_registry_password: ${{ secrets.TF_VAR_registry_password }}
   
      steps:
        - name: Checkout code
          uses: actions/checkout@v4
   
        - name: Setup Terraform
          uses: hashicorp/setup-terraform@v3
          with:
            terraform_version: 1.9.4
   
        - name: Terraform Init
          run: terraform init
          working-directory: infra
   
        - name: Terraform validate
          run: terraform validate
          working-directory: infra
   
        - name: Terraform Plan
          run: terraform plan -var-file=dev.tfvars -out=.planfile
          working-directory: infra
   
        - name: Post terraform plan comment
          uses: borchero/terraform-plan-comment@v2
          with:
            token: ${{ github.token }}
            working-directory: infra
            planfile: .planfile
   

   Lets understand the steps:

   • In Github actions, we get a github.token which has a lifecycle of that pipeline run. That means, we don't have to provide any PAT token to the pipeline for authentication. To read more about github.token visit here.

   • So first, we will provide a permission block, this block is for providing permissions to our github token which will be used for commenting on the PR.

   • Next, we will define all the env variables for terraform plan, basically authenticating to our cloud provider.

   • Next, checkout the code.

   • Terraform install using github action (can be done by using bash commands).

   • Terraform initialise for downloading the modules.

   • Terraform validate to check the syntax.

   • Terraform plan by mentioning the var file and outputting the output in .planfile

   • Now, we will use the github action borchero/terraform-plan-comment@v2 for commenting terraform plan output, it will take .planfile as an input and will post a well formatted comment on the PR.

     

5. At last, we will compare the change in infra between default branch and PR and will comment the change in cost on PR using open source tool Infracost. This tool is for cost estimation of our infra change.

    Infracost:
      runs-on: ubuntu-latest
      needs: terraform-plan
      permissions:
        contents: read
        pull-requests: write
   
      steps:
        - name: Setup Infracost
          uses: infracost/actions/setup@v3
          with:
            api-key: ${{ secrets.INFRACOST_API_KEY }}
   
        # Checkout the base branch of the pull request (e.g. main/master).
        - name: Checkout base branch
          uses: actions/checkout@v4
          with:
            ref: '${{ github.event.pull_request.base.ref }}'
   
        # Generate Infracost JSON file as the baseline.
        - name: Generate Infracost cost estimate baseline
          run: |
            infracost breakdown --path=infra \
              --format=json \
              --out-file=/tmp/infracost-base.json \
              --terraform-var-file dev.tfvars
   
        # Checkout the current PR branch so we can create a diff.
        - name: Checkout PR branch
          uses: actions/checkout@v4
   
        # Generate an Infracost diff and save it to a JSON file.
        - name: Generate Infracost diff
          run: |
            infracost diff --path=infra \
              --format=json \
              --compare-to=/tmp/infracost-base.json \
              --out-file=/tmp/infracost.json \
              --terraform-var-file dev.tfvars
   
        - name: Post Infracost comment
          run: |
            infracost comment github --path=/tmp/infracost.json \
              --repo=$GITHUB_REPOSITORY \
              --github-token=${{ github.token }} \
              --pull-request=${{ github.event.pull_request.number }} \
              --behavior=update
   

   Lets understand each step in detail:

   • Setup the infracost using the Infracost API key, you can get this by running the command infracost auth login && infracost configure get api_key.

   • Checkout base branch, which is target branch for the pull request.

   • Generate a cost estimate report for the default branch.

   • Now checkout to the PR branch.

   • Now generate a cost difference by comparing current branch with default branch.

   • Post the report in the comment of the PR.