OS Virtualization, Containers, Docker and Kubernetes Security

What it is

OS virtualization, also called containerization, lets many isolated user space instances share one operating system kernel. Each instance is a container. Containers start fast and use little memory, but they do not have a separate kernel the way a VM does.

Docker is the best known container platform, and Kubernetes is the orchestrator that schedules and manages containers across many hosts. The exam asks which practices make them safer.

How it works

OS virtualization security

Isolation comes from the Linux kernel: namespaces limit what a container can see (processes, network, mounts), and control groups (cgroups) limit how much CPU and memory it can use. Because the kernel is shared, a kernel flaw or an over privileged container can affect the host and every other container.

Container security best practices

• Use small, trusted base images, and scan every image for known vulnerabilities before use.
• Run as a non root user, and avoid privileged mode.
• Drop unneeded Linux capabilities and apply seccomp, AppArmor or SELinux profiles.
• Use a read only filesystem where possible.
• Set CPU and memory limits to stop one container from starving others.
• Never bake secrets (passwords, keys) into an image. Use a secrets store.
• Keep the host kernel and runtime patched, and use a minimal host operating system.
• Sign images and pull only from trusted registries.
• Monitor runtime behavior and log container activity.

Docker security best practices

Docker has a client, a daemon (dockerd), images and registries. The daemon runs with high privilege, so access to it is equal to root on the host.

User namespaces map root inside a container to an unprivileged user on the host, which limits damage from an escape.

Kubernetes security best practices

Kubernetes has a control plane and worker nodes.

Practices:

• RBAC: give each user and service account only the permissions it needs. Disable anonymous access to the API server.
• Network policies: by default every pod can reach every pod. Add policies that allow only required traffic.
• Pod Security Standards: three levels, Privileged, Baseline and Restricted. Enforce at least Baseline, and Restricted for sensitive workloads.
• Secrets: stored base64 encoded, which is not encryption. Enable encryption at rest for etcd and restrict access to it.
• Protect etcd and the kubelet: require authentication and TLS, and never expose them to the internet.
• Audit logging: record API server requests.
• Admission controllers: reject non compliant pods before they run.
• Keep Kubernetes patched and scan images in the pipeline.
• Use the CIS Kubernetes Benchmark, which tools such as kube-bench check.

A worked example

A developer mounts the Docker socket into a container so a build tool can start other containers. Anyone who compromises that container can start a privileged container and take over the host.

The defender removes the socket mount, runs the build with a rootless or isolated builder, and blocks privileged pods in Kubernetes with a Restricted Pod Security Standard.

How the exam asks about this

• "Which Linux feature limits the resources a container can use?" → Control groups (cgroups).
• "In Kubernetes, which component stores cluster state and secrets?" → etcd.
• "Which benchmark gives hardening guidance for Docker?" → The CIS Docker Benchmark.