Container Security

Container Security

Why Engineers Care About This

Containers introduce security risks—vulnerable base images, exposed secrets, excessive privileges, and runtime attacks. But containers can be secured—image scanning, minimal base images, least privilege, and runtime security. Understanding container security helps you build secure containerized applications. Without container security, applications are vulnerable to attacks.

When container images contain vulnerabilities, or secrets are exposed in images, or containers run with excessive privileges, you're hitting container security problems. These problems compound. Vulnerable images enable attacks. Exposed secrets enable unauthorized access. Excessive privileges enable privilege escalation. Good container security solves these problems by securing containers throughout their lifecycle.

In interviews, when someone asks "How would you secure this container?", they're really asking: "Do you understand container security risks? Do you know how to scan images, manage secrets, and implement least privilege? Do you understand that container security is about the entire lifecycle?" Most engineers don't. They assume "containers are secure" or don't think about container security at all.

Core Intuitions You Must Build

• Image scanning detects vulnerabilities before deployment. Container images can contain vulnerabilities (outdated packages, known CVEs). Scan images for vulnerabilities before deployment—use scanning tools (Trivy, Clair, Snyk) in CI/CD pipelines. Don't deploy images with critical vulnerabilities—fix or update images first. Also, scan base images—vulnerabilities in base images affect all derived images.

• Minimal base images reduce attack surface. Minimal base images (Alpine Linux, distroless) include only what's needed for runtime, reducing attack surface (fewer packages = fewer vulnerabilities). Don't use full OS images (Ubuntu, CentOS) for simple applications—they include unnecessary packages and vulnerabilities. Use minimal base images when possible.

• Least privilege reduces risk of privilege escalation. Containers should run with least privilege—non-root users, read-only filesystems, minimal capabilities. Running containers as root enables privilege escalation if container is compromised. Use non-root users and read-only filesystems when possible. Don't run containers as root unless necessary—it increases risk.

• Secrets should never be in images. Secrets hardcoded in images or committed to version control are exposed to anyone with image access. Use secrets management (Kubernetes secrets, secrets managers) to inject secrets at runtime. Don't hardcode secrets in Dockerfiles or images—they will be leaked.

• Runtime security monitoring detects attacks. Image scanning detects vulnerabilities before deployment, but runtime attacks can still occur. Monitor container runtime (processes, network, file system) for suspicious activity. Use runtime security tools (Falco, Aqua, Sysdig) to detect attacks. Don't rely only on image scanning—monitor runtime too.

• Image updates fix vulnerabilities. Vulnerabilities are discovered continuously, and base images are updated with security patches. Keep images updated—rebuild images regularly with updated base images and packages. Also, use image tags that enable updates (avoid latest, use version tags). Don't use outdated images—they contain known vulnerabilities.

Subtopics (Taught Through Real Scenarios)

Image Scanning and Vulnerabilities

What people usually get wrong:

Engineers often don't scan container images for vulnerabilities, thinking "images are fine" or "scanning is too slow." But container images can contain vulnerabilities (outdated packages, known CVEs). Scan images for vulnerabilities before deployment—use scanning tools in CI/CD pipelines. Don't deploy images with critical vulnerabilities—fix or update images first.

How this breaks systems in the real world:

A service deployed container images without scanning. Images contained known vulnerabilities (outdated packages, CVEs). An attacker exploited a vulnerability, gaining access to containers and data. The fix? Implement image scanning in CI/CD pipeline—scan images before deployment, block deployments with critical vulnerabilities, update images with patches. Now vulnerabilities are detected and fixed before deployment. But the real lesson is: image scanning detects vulnerabilities. Don't deploy unscanned images.

What interviewers are really listening for:

They want to hear you talk about image scanning, vulnerability detection, and CI/CD integration. Junior engineers say "just use images." Senior engineers say "scan container images for vulnerabilities before deployment—use scanning tools in CI/CD pipelines, block deployments with critical vulnerabilities, and update images with security patches." They're testing whether you understand that image scanning is about prevention, not just "checking."

Minimal Base Images

What people usually get wrong:

Engineers often use full OS images (Ubuntu, CentOS) for all applications, thinking "they're familiar." But full OS images include unnecessary packages and vulnerabilities, increasing attack surface. Minimal base images (Alpine Linux, distroless) include only what's needed for runtime, reducing attack surface. Use minimal base images when possible—they're more secure.

How this breaks systems in the real world:

A service used Ubuntu base images for all containers. Images were large (500MB) and contained many packages (thousands), increasing attack surface. Vulnerabilities in unused packages were discovered, requiring updates. The fix? Use minimal base images (Alpine Linux, 5MB)—include only runtime dependencies, reduce attack surface. Now images are smaller and more secure. But the real lesson is: minimal base images reduce attack surface. Don't use full OS images unnecessarily.

What interviewers are really listening for:

They want to hear you talk about minimal base images, attack surface reduction, and base image selection. Junior engineers say "just use Ubuntu." Senior engineers say "use minimal base images (Alpine Linux, distroless) that include only runtime dependencies—reduce attack surface, fewer packages mean fewer vulnerabilities." They're testing whether you understand that base images affect security, not just "convenience."

Least Privilege and Runtime Security

What people usually get wrong:

Engineers often run containers as root, thinking "it's easier" or "it's needed." But running containers as root enables privilege escalation if container is compromised. Use least privilege—non-root users, read-only filesystems, minimal capabilities. Don't run containers as root unless necessary—it increases risk.

How this breaks systems in the real world:

A service ran all containers as root. When a container was compromised (vulnerability exploited), attacker had root access, enabling privilege escalation and access to host system. The fix? Use least privilege—run containers as non-root users, use read-only filesystems, limit capabilities. Now compromised containers have limited privileges, reducing risk. But the real lesson is: least privilege reduces risk. Don't run containers as root unnecessarily.

What interviewers are really listening for:

They want to hear you talk about least privilege, non-root users, and runtime security. Junior engineers say "just run as root." Senior engineers say "implement least privilege—run containers as non-root users, use read-only filesystems, limit capabilities—running as root enables privilege escalation if container is compromised." They're testing whether you understand that container security is about limiting privileges, not just "functionality."

---

• Image scanning detects vulnerabilities before deployment—scan images in CI/CD pipelines, block critical vulnerabilities
• Minimal base images reduce attack surface—use Alpine Linux or distroless, avoid full OS images
• Least privilege reduces risk of privilege escalation—use non-root users, read-only filesystems
• Secrets should never be in images—use secrets management to inject secrets at runtime
• Runtime security monitoring detects attacks—monitor container runtime for suspicious activity
• Image updates fix vulnerabilities—rebuild images regularly with updated base images and packages
• Good container security secures containers throughout their lifecycle (build, deploy, runtime)

---

• Docker & Containerization - Container fundamentals
• Secrets Management - Managing secrets in containers
• CI/CD Pipelines - Image scanning in pipelines