CCNA Container Security Questions

Fetching and executing a remote script during a Docker build introduces unverified third-party code into the image. Because there is no checksum or signature validation, a compromised endpoint can inject malicious content that becomes part of a trusted image. Registry scanning may not catch bespoke or obfuscated payloads, so the integrity of the supply chain is the primary concern.

Mounting the Docker socket into a container effectively gives that container root-level control over the host's Docker daemon. An attacker who compromises the container can use the Docker API to start privileged containers, mount host directories, or execute commands on the host, resulting in full system compromise. This is a critical misconfiguration that should be avoided.

RBAC least privilege is the authoritative control over what a service account can do against the API server. Binding a narrowly scoped Role that grants only the required verbs and resources means a compromised pod's token cannot enumerate secrets or perform privileged actions, directly containing the blast radius from the RCE compromise.

Specifying runAsUser: 0 in a Kubernetes securityContext forces the container to run as the root user. This violates the principle of least privilege and increases the potential impact of a container compromise. Best practice is to run containers as a non-root user, often defined in the image or via runAsUser with a high UID.

Content trust and image signing using tools like Notary or Cosign ensure that the image pulled by a runtime is exactly the same one pushed by the CI/CD pipeline. By cryptographically signing the manifest, organizations prevent man-in-the-middle attacks and unauthorized registry modifications. This is vital in modern DevSecOps, as compromised images could introduce persistent backdoors or vulnerabilities into the production environment without triggering standard application-level alerts.

Kata Containers runs each pod in a lightweight virtual machine with its own guest kernel, so workloads do not share the host kernel. This hardware-virtualization-based isolation provides a stronger boundary than runc, containerd with runc, or CRI-O with SELinux, all of which share the host kernel and are therefore vulnerable to kernel-level escapes.

This configuration enforces the principle of least privilege by ensuring the container cannot run as root and preventing any process from gaining more privileges than its parent. 'allowPrivilegeEscalation: false' is a critical setting that prevents setuid binaries from changing the process effective user ID, which is a common technique used by attackers to escalate privileges within a container after achieving initial execution.

Kernel vulnerabilities are a primary vector for container escapes. By using technologies like gVisor or Kata Containers, the container environment uses a hardened kernel or a separate micro-VM, providing an additional layer of isolation. Standard containers share the host kernel directly; if the kernel is exploited via a system call, the attacker can break out of the container boundary entirely, leading to full system compromise of the underlying host node.

The restricted Pod Security Standard is the most restrictive of the three built-in profiles and enforces controls such as requiring non-root execution, dropping all capabilities, and mandating a seccomp profile. When a namespace enforces this profile, non-compliant pods are denied at admission, directly preventing root-running containers from being scheduled.

Pod Security Admission decides admission based on the namespace's pod-security.kubernetes.io/enforce label, and the privileged value on the tenants namespace overrode the cluster-wide restricted profile. That exemption is precisely what let a pod mount the node's /var/lib/kubelet directory via hostPath. Removing the label restores restricted enforcement, which forbids hostPath volumes, and refactoring the legacy job removes the need for the exemption so the exposure cannot be recreated.

Secrets should never be baked into container images because they remain in the image layers even if deleted in later steps. Once an image is pushed to a registry, those secrets are accessible to anyone with pull access. Using orchestrator-native secret management (like Kubernetes Secrets or Vault) ensures that sensitive data is injected at runtime, keeping it out of the persistent image layers and the source control history.

Service account token volume projection utilizes short-lived tokens cryptographically signed by the cluster, mounting them securely into specific pods with restricted audiences. This approach replaces static long-lived credentials stored in environment variables or generic secrets, significantly reducing lateral movement risks if an application is compromised.

Container images are composed of immutable layers, one per Dockerfile instruction. Removing a file in a later RUN step only records a deletion in that new layer; the bytes remain in the earlier layer and can be recovered by extracting the image. Secrets must therefore be injected at runtime via secrets management, never copied into any layer.