Container and Kubernetes Security
Containers and Kubernetes add their own attack surface on top of the cloud account, and this topic covers the security-relevant essentials while handing the operational depth to the existing Docker and Kubernetes courses. The recurring themes are familiar — minimize the image, drop privileges, isolate workloads, secure the control plane — but the container context sharpens them: a container escape or an exposed Kubernetes API can compromise a whole node or cluster.
This secures Meridian's containerized workloads without re-teaching how containers work — assuming the mechanics from the sibling courses and focusing on what makes them secure.
Image Security
A smaller image is a smaller attack surface: minimal or distroless bases, scanned for vulnerable packages (the SCA of Chapter 12), pinned by digest, and built without secrets baked in. The image is the artifact, so a bloated or vulnerable one ships the flaw everywhere it runs — which is why image hygiene multiplies across every deployment of that image.
Runtime Least Privilege
Do not run as root, drop Linux capabilities, use read-only root filesystems, and apply seccomp or AppArmor profiles (Chapter 7). A container running as root with full capabilities is one kernel bug away from owning the host, so runtime least privilege is what keeps a compromised container from becoming a compromised node.
Isolation and Container Escape
Containers share the host kernel, so isolation is weaker than a virtual machine — a theme from the Docker course. The risk is a container escape to the node, countered by not running privileged containers, keeping the kernel patched, and using VM-strength isolation (gVisor, Kata) for untrusted or multi-tenant workloads rather than relying on the container boundary alone.
Kubernetes Control-Plane Security
The API server is the cluster's crown jewel: authenticate and authorize every request (Kubernetes RBAC, Chapter 3), never expose it publicly, secure etcd (it holds all the secrets), and apply NetworkPolicies (Chapter 4's segmentation) and Pod Security standards. Meridian's container posture is a concrete baseline — minimal scanned images, non-root least-privilege runtime, network-policy segmentation, RBAC on the API, secrets from a manager — with the operational how-to pointed at the Docker and Kubernetes deep dives.
VM — a hardware-level boundary via the hypervisor: strong isolation, the right choice for hard multi-tenant or untrusted workloads.
Container — shares the host kernel: lighter, but a kernel vulnerability or misconfiguration can escape to the node, so it is a weaker security boundary. For untrusted code, add VM-strength sandboxing (gVisor, Kata) rather than relying on the container boundary alone.
- Running containers as root with full capabilities and writable root filesystems, turning a container bug into host compromise.
- Bloated images with vulnerable packages and baked-in secrets (Chapter 12), shipping the flaw to every deployment.
- Exposing the Kubernetes API server publicly or with weak RBAC, and leaving etcd (all the secrets) unsecured.
- Treating the container boundary as VM-strength isolation for untrusted or multi-tenant workloads.
- Skipping NetworkPolicies, so a compromised pod can reach every other pod in the cluster.
- Ship minimal, scanned, digest-pinned images with no baked-in secrets, built on distroless or minimal bases.
- Run least-privilege at runtime: non-root, dropped capabilities, read-only root filesystem, seccomp or AppArmor (Chapter 7).
- Secure the Kubernetes control plane: private API, strong RBAC (Chapter 3), protected etcd, NetworkPolicies (Chapter 4), Pod Security standards.
- Use VM-strength sandboxing for untrusted workloads, and defer operational depth to the Docker and Kubernetes courses.
- Scan images continuously and rebuild on base-image CVEs rather than letting them age.
Knowledge Check
Why is a container a weaker security boundary than a virtual machine?
- They share the host kernel, so a flaw can reach the node
- Containers cannot make use of any access controls whatsoever
- Virtual machines are unable to run untrusted code
- Containers always run as the root user by design
Why is the Kubernetes API server the cluster's crown jewel?
- Every action goes through it, so weak RBAC is total
- It stores every one of the cluster's container images
- It is the only cluster component that can be encrypted
- It runs the application workloads on nodes directly
What is the right way to isolate an untrusted or multi-tenant containerized workload?
- Use VM-strength sandboxing like gVisor or Kata
- Run it as the root user so it has the resources it needs
- Give it full Linux capabilities for broad compatibility
- Expose the API server so the workload can self-manage itself
You got correct