Week 14: Security & DevSecOps

1. Secrets Management

The single most common real-world security incident in this entire course's toolchain isn't a zero-day exploit — it's a credential committed to Git. Once a secret lands in a commit, it's in the repository's history permanently, even after you delete the file in a later commit; anyone who ever cloned the repo, and anyone who can read a public fork, has it.

.env
.env.*
*.pem
*.key
kubeconfig
secrets/

.gitignore only stops new accidental commits; it does nothing once a secret is already in history, and it does nothing to prevent an app from simply reading a static credential out of a config file forever. A real secrets manager — HashiCorp Vault, AWS Secrets Manager, or a Kubernetes-native option like External Secrets Operator — solves both problems: secrets live in one encrypted, access-controlled, audited store, and are fetched at runtime instead of baked into config.

aws secretsmanager create-secret \
  --name prod/web-app/db-password \
  --secret-string '{"username":"app_svc","password":"S7!kq2vLpR"}'

aws secretsmanager get-secret-value \
  --secret-id prod/web-app/db-password \
  --query SecretString --output text

Inside Kubernetes, the External Secrets Operator pattern is the cleanest fit for what you built in Week 11: it syncs a secret from AWS Secrets Manager (or Vault) into a native Kubernetes Secret automatically, so your Deployment still consumes a normal secretKeyRef while the actual plaintext credential lives in a properly access-controlled, auditable system, and rotates without you touching a manifest.

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: web-app-db
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: web-app-db   # the native k8s Secret this creates
  data:
    - secretKey: DB_PASSWORD
      remoteRef:
        key: prod/web-app/db-password
        property: password

2. Dependency & Container Image Scanning in CI

Every third-party package your app depends on, and every layer in your Docker base image, is code you didn't write and are trusting anyway. Week 5 covered scanning images manually with Trivy; the real value comes from running that scan automatically on every pull request in the GitHub Actions pipeline from Week 6, so a vulnerable dependency is caught before it merges, not discovered in production.

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Scan dependencies (npm audit)
        run: npm audit --audit-level=high

      - name: Build image
        run: docker build -t web-app:${{ github.sha }} .

      - name: Scan image with Trivy
        uses: aquasecurity/trivy-action@0.24.0
        with:
          image-ref: web-app:${{ github.sha }}
          severity: CRITICAL,HIGH
          exit-code: "1"          # fail the job if matches are found
          ignore-unfixed: true    # skip CVEs with no available patch yet

exit-code: "1" is what actually gives this teeth — without it, Trivy prints a report and the job passes anyway, which is a scan nobody will ever read. The tradeoff is that a hard fail on every CRITICAL/HIGH finding can block a merge over a vulnerability with no available fix yet, which is why ignore-unfixed matters: there's no useful action a team can take on an unpatched CVE except accept the risk, so failing the build on it just trains people to ignore the scan.

trivy image --severity CRITICAL,HIGH web-app:local
trivy fs --severity CRITICAL,HIGH .   # scan source + lockfiles for known-vulnerable deps

3. Least-Privilege IAM Policies

Week 8 introduced IAM users, roles and policies and told you to prefer roles over long-lived access keys; this week is about tightening what those roles are actually allowed to do. Least privilege means a policy grants exactly the permissions a workload needs to do its job, nothing more — not because a wildcard policy is guaranteed to be exploited, but because it makes the blast radius of any single compromised credential as small as possible.

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

That single statement lets the role read, overwrite, or delete every object in every S3 bucket in the account — including buckets that have nothing to do with the app it was written for. A least-privilege version names the exact actions and scopes the resource down to the specific bucket and prefix the app actually touches:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::acme-web-app-uploads/user-content/*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::acme-web-app-uploads",
      "Condition": {
        "StringLike": { "s3:prefix": "user-content/*" }
      }
    }
  ]
}

Inside a Kubernetes cluster on EKS, this same idea is called IRSA (IAM Roles for Service Accounts): a specific Kubernetes ServiceAccount, not the whole cluster's worker nodes, gets bound to a specific IAM role, so a Pod compromise doesn't automatically hand over broad AWS credentials shared by everything running on that node.

4. Kubernetes NetworkPolicies

By default, every Pod in a Kubernetes cluster can send traffic to every other Pod, across every namespace — there's no network isolation unless you add it yourself. That's the Kubernetes equivalent of every EC2 instance sharing one security group that allows all traffic. A NetworkPolicy restricts which Pods can talk to a given Pod, and it requires a CNI plugin that enforces them (Calico, Cilium; the default kindnet in a plain kind cluster does not).

NetworkPolicies are additive and default-deny once applied: the moment any policy selects a Pod, all traffic not explicitly allowed by some policy is blocked for that Pod. A common first step is a deny-all baseline, then explicit allow rules layered on top:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}       # selects every Pod in the namespace
  policyTypes:
    - Ingress
    - Egress

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-db
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: web
      ports:
        - protocol: TCP
          port: 5432

This pair means: nothing can reach postgres Pods by default, except Pods labeled app: web, and only on port 5432. A compromised Pod elsewhere in the namespace — even one running as root inside its container — has no network path to the database at all, which limits exactly the kind of lateral movement that turns a single compromised container into a full data breach.

5. Hands-on Exercise

6. Knowledge Check

Four quick questions. Expand each to check your answer.