Harden containers with seccomp profiles, AppArmor, Linux capabilities, rootless containers, and read-only rootfs.
0 / 5 completed
1 / 5
What is a seccomp profile in container security?
seccomp (Secure Computing Mode): a seccomp BPF filter is loaded into the kernel and evaluated for every syscall. Blocking unnecessary syscalls (like ptrace, mount, kexec_load) means a malicious payload inside the container cannot use those kernel interfaces to escape or escalate privileges.
2 / 5
What are Linux capabilities and how do they apply to containers?
Linux capabilities: a container does not need all root capabilities. Dropping CAP_SYS_ADMIN, CAP_NET_ADMIN, and others limits what a compromised process can do. Docker drops many by default; in Kubernetes you specify securityContext.capabilities.drop to enforce least privilege.
3 / 5
What does AppArmor provide for container security?
AppArmor: a profile like deny /etc/shadow r prevents the containerised process from reading the shadow password file even if it has root. Docker automatically loads a default AppArmor profile. Kubernetes supports securityContext.appArmorProfile to apply custom profiles per pod.
4 / 5
What are rootless containers and why are they more secure?
Rootless containers: Podman and rootless Docker use user namespaces to map container UIDs to unprivileged host UIDs. If a process escapes the container, it is an unprivileged user on the host. Contrast this with root containers where an escape grants host root access.
5 / 5
What is the purpose of read-only root filesystems in container security?
Read-only rootfs:securityContext.readOnlyRootFilesystem: true in Kubernetes. Combined with tmpfs mounts for /tmp and application-specific write paths, this ensures the running container is identical to the image — making the attack surface predictable and auditable.