Week 9: Container & Kubernetes Security

1. Image Scanning & Building Minimal, Non-Root Images

A container image bundles an application with every dependency it needs — including, often, far more than it actually needs. Every extra package, library, and shell binary in an image is Week 3's attack surface principle, applied to a container: more installed means more that could carry a known vulnerability or be abused if the container is compromised.

$ trivy image node:18

node:18 (debian 12.4)
==================
Total: 143 (HIGH: 12, CRITICAL: 3)

CVE-2024-XXXXX  libssl3  CRITICAL  Fixed in 3.0.13-1

# Every one of these is a known, disclosed vulnerability in something
# bundled into this image -- exactly Week 11's CVE/patch-management
# process, but applied to container base images instead of a full OS

Two changes shrink this dramatically: a minimal base image, and running as a non-root user inside the container.

# BAD: a full OS image, running as root by default
FROM node:18
COPY . .
CMD ["node", "server.js"]

# GOOD: minimal base + a multi-stage build + explicit non-root user
FROM node:18 AS build
COPY . .
RUN npm ci && npm run build

FROM node:18-slim
RUN useradd --uid 1001 appuser
COPY --from=build /app/dist /app
USER appuser        # everything after this runs as appuser, not root
WORKDIR /app
CMD ["node", "server.js"]

node:18-slim (or a distroless image, which strips out even the shell) has a dramatically smaller attack surface than the full image — fewer packages means fewer possible CVEs, and no shell means a common post-exploitation step (getting an interactive shell inside a compromised container) simply isn't available at all.

2. Kubernetes RBAC

Week 5's RBAC concept, applied to a Kubernetes cluster: Roles define a set of permissions on resources within a namespace, and RoleBindings grant a role to a specific user or service account.

# A role that can only read pods in the "staging" namespace -- nothing else
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: staging
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]     # read-only -- no create/update/delete

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: alice-can-read-pods
  namespace: staging
subjects:
- kind: User
  name: alice
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

The dangerous default to watch for is ClusterRole bound with a ClusterRoleBinding — that grants the permission cluster-wide, across every namespace, instead of scoped to one. The same "start narrow, widen with evidence" discipline from Week 8's IAM section applies directly here: a service account almost never needs cluster-wide access, even if it's the easiest thing to grant while getting something working.

3. Network Policies in Kubernetes

By default, every Pod in a Kubernetes cluster can talk to every other Pod, across namespaces — a flat network, exactly the anti-pattern Week 2 warned about. NetworkPolicies are how you segment it.

# Default-deny all ingress traffic in the "backend" namespace --
# nothing gets in unless a later policy explicitly allows it
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: backend
spec:
  podSelector: {}
  policyTypes: ["Ingress"]

---
# Now explicitly allow the frontend to reach the backend's API pods, on port 8080 only
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-api
  namespace: backend
spec:
  podSelector:
    matchLabels: { app: api }
  policyTypes: ["Ingress"]
  ingress:
  - from:
    - namespaceSelector:
        matchLabels: { name: frontend }
    ports:
    - port: 8080

This is Week 2's segmentation and Week 3's minimal-attack-surface thinking, expressed as Kubernetes-native configuration: exactly which pods can reach exactly which other pods, on exactly which ports — a compromised frontend pod shouldn't be able to reach the database directly, the same principle as the three-tier network from Week 2's exercise.

4. Pod Security Standards

Kubernetes' Pod Security Standards define three progressively strict profiles for what a Pod is allowed to do, enforced cluster- or namespace-wide.

Privileged  # no restrictions -- effectively opts out of pod-level security controls
Baseline    # blocks known privilege escalations (no privileged containers, no host
             # namespaces, no dangerous Linux capabilities) while staying broadly compatible
Restricted  # the strictest, hardening-focused profile: enforces non-root, drops all
             # Linux capabilities by default, requires a read-only root filesystem

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted

With this label applied, the cluster rejects any Pod spec that doesn't comply — including a Pod requesting privileged: true (giving it near-host-level access) or running as root, both of which are exactly what an attacker who's already exploited an application inside a container would want in order to escalate further.

5. Container Escapes & Runtime Isolation

A container escape is when a process breaks out of its container's isolation boundaries and gains access to the host system, or to other containers on the same host — the worst-case outcome this entire week's controls exist to prevent or limit.

1. A privileged container (--privileged, or CAP_SYS_ADMIN granted) with
   near-full access to the host's devices and kernel features
2. A mounted host path (e.g. mounting the Docker socket /var/run/docker.sock
   INTO a container) -- that container can now control the host's Docker
   daemon directly, which is effectively root on the host
3. A kernel vulnerability -- since containers share the host kernel,
   a kernel exploit can cross the container boundary entirely

The Docker-socket mount is worth calling out specifically because it's a genuinely common, well-intentioned mistake (often done to let a CI container build other container images) that is, in practical terms, equivalent to granting that container root on the host — Week 3's "the docker group is functionally root" callout, in container form.

6. Hands-on Exercise

7. Knowledge Check

Four quick questions. Expand each to check your answer.