Cloud Security II
Network, Containers & IaC

Phase 1 and Phase 2 together form the complete picture: you can have perfect IAM and still have a publicly accessible EC2 instance because a security group says 0.0.0.0/0 on port 22. Both layers have to be correct at the same time.

1. Install Checkov

   The IaC scanner you'll use in Module 3 — Palo Alto Networks, actively maintained, unaffected by the Trivy supply-chain incident.

2. Install kubectl

   The Kubernetes CLI.

3. Install kind

   Kubernetes-in-Docker — spins up a local cluster instantly with no cloud cost, used for Modules 2 and 3's K8s labs.

4. Install kube-bench

   CIS Kubernetes Benchmark checker — as a direct binary download, not via a GitHub Action (see Lab 0.3).

5. Install kube-hunter

   K8s penetration testing tool — same, binary install only.

6. Verify each tool responds

   Run the version check for each one before moving on.

# Checkov
pip install checkov
checkov --version

# kubectl (Linux)
curl -LO "https://dl.k8s.io/release/$(curl -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x kubectl && sudo mv kubectl /usr/local/bin/
kubectl version --client

# kind (Kubernetes-in-Docker) — binary install
curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.24.0/kind-linux-amd64
chmod +x kind && sudo mv kind /usr/local/bin/
kind version

# kube-bench — binary download, NOT via GitHub Action
wget https://github.com/aquasecurity/kube-bench/releases/latest/download/kube-bench_linux_amd64.tar.gz
tar -xzf kube-bench_linux_amd64.tar.gz && sudo mv kube-bench /usr/local/bin/
kube-bench version

# kube-hunter — pip install
pip install kube-hunter
kube-hunter --help

1. List all VPCs in your account

   Note any that are still using the Default VPC — this should be deleted in production accounts.

2. Examine route tables for each subnet

   A subnet whose route table has a 0.0.0.0/0 → internet gateway route is public, regardless of what it's called.

3. Check NAT gateway vs internet gateway

   Private subnets route outbound traffic through a NAT gateway — they can reach out but can't be reached in.

4. Confirm whether any production instances are in public subnets

   Databases and internal services should never be directly internet-routable, even if a security group restricts port access.

# list all VPCs in your account
aws ec2 describe-vpcs --query 'Vpcs[*].{ID:VpcId,CIDR:CidrBlock,Default:IsDefault}'

# inspect route tables — look for 0.0.0.0/0 with gateway destination
aws ec2 describe-route-tables --query 'RouteTables[*].{ID:RouteTableId,Routes:Routes[*].{Dest:DestinationCidrBlock,GW:GatewayId}}'

1. List all security groups

   And their inbound rules.

2. Filter for 0.0.0.0/0 or ::/0 ingress

   Any rule allowing traffic from the whole internet.

3. Cross-reference sensitive ports

   22 (SSH), 3389 (RDP), 3306 (MySQL), 5432 (Postgres), 27017 (MongoDB), 6379 (Redis) — none should be reachable from 0.0.0.0/0.

4. Identify intent vs reality

   Is the group named "private-db" but has port 3306 open to 0.0.0.0/0? That's your finding.

5. Document for the remediation plan

   Each finding: group ID, port, intended vs actual access, fix recommendation.

# find security groups with inbound 0.0.0.0/0 or ::/0 rules
aws ec2 describe-security-groups \
  --query "SecurityGroups[?IpPermissions[?IpRanges[?CidrIp=='0.0.0.0/0']]].{Name:GroupName,ID:GroupId,Rules:IpPermissions}" \
  --output table

# alternatively, use Prowler's EC2 security group checks from Phase 1
prowler aws --service ec2 --checks ec2_securitygroup_allow_ingress_from_internet_to_any_port

1. Check whether Flow Logs are already enabled

   On Meridian's VPCs.

2. Enable Flow Logs on your lab VPC

   Sending records to an S3 bucket or CloudWatch Logs.

3. Generate some traffic

   Make a few API calls, curl a public endpoint from an EC2 instance — something that produces records.

4. Read the flow log records

   Identify source IP, destination IP, port, action (ACCEPT/REJECT), and bytes transferred.

5. Find a REJECT record

   Something that tried to connect and was blocked — confirm it matches a security group rule.

# check for existing flow logs on your VPC
aws ec2 describe-flow-logs

# enable flow logs to S3 (replace bucket-name with your own)
aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-XXXXXXXX \
  --traffic-type ALL \
  --log-destination-type s3 \
  --log-destination arn:aws:s3:::your-flow-logs-bucket

1. Review the insecure baseline Dockerfile

   Copy the example below into a file — it deliberately contains the four most common container security mistakes.

2. Identify each issue

   Running as root, no USER instruction, latest tag, no health check, unnecessary packages.

3. Write the hardened version

   Fix each issue: pin a specific image tag, add a non-root USER, pin dependencies, minimize the attack surface.

4. Build both locally with Docker

   And confirm the hardened one runs correctly.

5. Scan with Checkov's Dockerfile support

   Note how many of the issues Checkov catches automatically.

# ── insecure baseline Dockerfile ──────────────────────────
FROM node:latest               # unpinned tag — version drift is a supply-chain risk
RUN apt-get install -y curl    # unnecessary tool increases attack surface
COPY . .
RUN npm install
CMD ["node", "app.js"]         # runs as root — no USER instruction

# ── hardened version ──────────────────────────────────────
FROM node:20.18-alpine3.20    # pinned digest; alpine reduces surface area
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev          # no dev dependencies in production image
COPY --chown=node:node . .
USER node                      # non-root; node user exists in the official image
EXPOSE 3000
CMD ["node", "app.js"]

# scan your Dockerfile with Checkov
checkov -f Dockerfile

1. Create a kind cluster

   Your local, cost-free Kubernetes environment.

2. Run kube-bench

   Against the cluster — note that kind hides some control-plane files, so some checks will WARN rather than FAIL.

3. Read the output sections

   Control Plane, Worker Nodes, Policies — find at least three FAIL items.

4. Pick one FAIL and apply its remediation

   kube-bench prints the exact fix for each finding. Apply one.

5. Re-run and confirm the FAIL became PASS

   Then destroy the cluster.

# create a local cluster with kind
kind create cluster --name meridian-checkout

# run kube-bench as a job inside the cluster
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl wait --for=condition=complete job/kube-bench --timeout=120s
kubectl logs job/kube-bench

# when finished — always destroy immediately
kind delete cluster --name meridian-checkout

1. Create a new kind cluster

   For this lab.

2. List all ClusterRoleBindings

   Flag any that bind the cluster-admin role to a ServiceAccount — that ServiceAccount can do anything in the cluster.

3. Create a minimal ServiceAccount

   With only the permissions the checkout service actually needs — read-only access to ConfigMaps in one namespace.

4. Run kube-hunter in passive mode

   From outside the cluster — it maps the attack surface without attempting exploitation.

5. Review what kube-hunter found

   Note which findings overlap with kube-bench's policy section.

6. Destroy the cluster

   Immediately after.

# list ClusterRoleBindings to find over-privileged ServiceAccounts
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name=="cluster-admin") | .subjects'

# create a minimal ServiceAccount with read-only ConfigMap access
kubectl create serviceaccount checkout-sa -n default
kubectl create role checkout-reader \
  --verb=get,list --resource=configmaps -n default
kubectl create rolebinding checkout-rb \
  --role=checkout-reader --serviceaccount=default:checkout-sa -n default

# run kube-hunter in passive mode (safe — no exploitation attempts)
kube-hunter --remote $(kubectl cluster-info | grep -oP 'https://[^ ]+' | head -1)

# destroy when done
kind delete cluster --name meridian-checkout

1. Create the insecure Terraform example

   Copy the file below — it contains five real misconfigurations Meridian's platform team would plausibly have committed.

2. Run a Checkov scan

   Against the directory.

3. Read the output

   Note which checks pass, which fail, the check IDs, and the file/line references.

4. Fix two findings

   Directly in the Terraform file.

5. Re-run and confirm fewer failures

   Track the delta — this is exactly what a PR security gate would show.

# main.tf — deliberately misconfigured S3 + security group
resource "aws_s3_bucket" "meridian_data" {
  bucket = "meridian-data-2024"
  # ISSUE 1: no server-side encryption block
  # ISSUE 2: no versioning block
}

resource "aws_s3_bucket_public_access_block" "meridian_data" {
  bucket = aws_s3_bucket.meridian_data.id
  block_public_acls   = false   # ISSUE 3: public access not blocked
  block_public_policy = false
}

resource "aws_security_group" "checkout" {
  name = "checkout-sg"
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]  # ISSUE 4: SSH open to internet
  }
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]  # ISSUE 5: unrestricted egress
  }
}

# scan — no plan file needed, Checkov reads HCL directly
checkov -d .

1. Write the insecure checkout deployment manifest

   Copy the example below.

2. Run Checkov against it

   Same command, different file.

3. Compare findings to Module 2's kube-bench output

   Note the overlap — the same misconfiguration shows up in both the cluster audit and the manifest scan.

4. Fix the Pod Security Context

   Add runAsNonRoot: true, readOnlyRootFilesystem: true, and drop all capabilities.

5. Re-scan and confirm the Pod-level findings clear

# checkout-deployment.yaml — deliberately insecure manifest
apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout
spec:
  replicas: 1
  selector:
    matchLabels:
      app: checkout
  template:
    metadata:
      labels:
        app: checkout
    spec:
      containers:
      - name: checkout
        image: meridian/checkout:latest   # unpinned tag
        # MISSING: securityContext block entirely
        # MISSING: resources.limits (no CPU/memory caps)
        # MISSING: readinessProbe

# scan the manifest
checkov -f checkout-deployment.yaml --framework kubernetes

1. Scan the entire working directory

   All Terraform and Kubernetes files together — Checkov auto-detects framework per file.

2. Export to JSON

   For structured processing.

3. Triage to the top 5 critical/high findings

   Using the same severity-first approach as Phase 1's Module 4.3 remediation plan.

4. Write one-line fixes for each

   Exact HCL or YAML additions, not vague recommendations.

5. Produce a two-page audit summary

   Findings, business risk, exact fix, owner, target date — the deliverable Meridian's engineering team can act on.

# scan everything at once — Checkov detects Terraform + Kubernetes + Dockerfiles
checkov -d . --output json --output-file-path ./checkov-results

# filter for critical and high findings only
cat ./checkov-results/results_json.json | \
  jq '[.results.failed_checks[] | select(.severity=="HIGH" or .severity=="CRITICAL")]'

1. Review the insecure workflow below

   Identify the three issues the Trivy incident exploited or enabled.

2. Pin every Action to a commit SHA

   Not a version tag. A SHA cannot be rewritten; a tag can. This is the single most impactful change.

3. Restrict GITHUB_TOKEN permissions

   Declare only the permissions the workflow actually needs.

4. Audit any pull_request_target usage

   If it checks out PR code and has token permissions, it's a critical vulnerability waiting to be exploited.

5. Run Checkov against the workflow file

   Checkov covers GitHub Actions YAML — same tool, different framework.

# ── INSECURE workflow ─────────────────────────────────────
on: [push, pull_request_target]     # RISK: pull_request_target + checkout = credential theft
jobs:
  scan:
    runs-on: ubuntu-latest
    # RISK: no permissions block = default wide-open GITHUB_TOKEN
    steps:
      - uses: actions/checkout@v4   # RISK: mutable version tag
      - uses: aquasecurity/trivy-action@v0.24.0  # RISK: tag was rewritten in March 2026

# ── HARDENED workflow ─────────────────────────────────────
on: [push]                          # pull_request_target removed
permissions:
  contents: read                    # explicit least-privilege
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # SHA pinned
      - name: Run Checkov IaC scan
        run: pip install checkov && checkov -d .  # Checkov via pip — no GitHub Action needed

# scan your own workflow file with Checkov
checkov -f .github/workflows/scan.yml --framework github_actions

1. Scan your repo for leaked secrets with gitleaks

   From Module 7 of the Bug Bounty workbook — secrets accidentally committed to Terraform or workflow files are extremely common.

2. Configure AWS OIDC in your lab account

   Create an IAM OIDC provider for GitHub Actions and an IAM Role it can assume — no stored key required.

3. Update the hardened workflow to use OIDC

   Replace aws-actions/configure-aws-credentials using stored keys with the OIDC token approach.

4. Verify the pipeline can access AWS

   Without any long-lived key stored in GitHub Secrets.

# scan for accidentally committed secrets
gitleaks detect --source . --log-opts="--all"

# hardened workflow using OIDC (no stored AWS keys)
permissions:
  id-token: write   # required for OIDC
  contents: read

steps:
  - name: Configure AWS Credentials via OIDC
    uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502  # SHA pinned
    with:
      role-to-assume: arn:aws:iam::ACCOUNT_ID:role/GitHubActionsRole
      aws-region: us-east-1
      # no access-key-id or secret-access-key — OIDC exchanges the GitHub token for temporary AWS creds

1. Write the full hardened workflow

   Combining Labs 4.1 (SHA pinning, OIDC, least-privilege) and 4.2 (OIDC), with a Checkov scan gate on every PR.

2. Write the closing audit summary

   Both phases together: what Meridian's posture was on day one, what changed in Phase 1, and what Phase 2 adds.

3. Identify the one remaining gap

   What does the pipeline above still not catch? (Runtime threats inside a running container — the answer is a runtime security tool like Falco, which is out of scope here but the honest next step.)