Container Security practice questions

Enable the Docker API to listen on TCP port 2375 for remote management.

Why it fails: Exposing the Docker API on unencrypted TCP port 2375 allows unauthorized users to execute arbitrary commands with root privileges on the host. This effectively grants full control to any entity with network access, representing a critical security misconfiguration that must be avoided in all production environments.

Mount the Docker socket into all application containers.

Why it fails: Mounting the Docker socket inside a container allows the containerized application to communicate with the host daemon. This effectively permits the container to spawn and manage other containers, leading to trivial container escapes and root-level host access if the application within the container is successfully exploited.

Run the Docker daemon as a non-root user without any additional privileges.

Why it fails: While running as a non-root user is a goal, the default Docker daemon architecture requires elevated privileges to manage network interfaces and mount filesystems. Simply running as a non-root user without proper capability management will break the core functionality required for container orchestration and resource isolation.

The image is missing a health check instruction.

Why it fails: While health checks are recommended for operational availability and automated container orchestration, their absence is not a security vulnerability. The security of the image depends on the software included and the privileges used to execute the entrypoint, rather than the existence of a status verification endpoint.

The USER instruction is placed too early in the Dockerfile.

Why it fails: Placing the USER instruction after the package installation is actually correct because the package manager requires root privileges to write to system directories. The security concern here is not the order of the instructions, but rather the broad dependencies installed and the lack of a multi-stage build.

The CMD instruction does not use the exec form syntax.

Why it fails: The Dockerfile uses the JSON array format (exec form) for the CMD instruction, which is the recommended practice. This ensures that the application receives Unix signals (like SIGTERM) directly from the container runtime, allowing the process to perform graceful shutdowns and cleanup operations when the container is stopped.

Storing all application source code inside the registry.

Why it fails: The registry is intended for storing container images, not source code. Storing source code in the registry increases the registry's attack surface and potentially exposes intellectual property. Source code should be managed in a version control system with appropriate access controls, not bundled within the container artifact distribution platform.

Disabling internal container networking completely.

Why it fails: Disabling internal networking renders most microservices-based architectures non-functional. Containers must communicate for the system to work. Instead of disabling networking, security teams should implement network policies and service meshes to segment traffic, ensuring the principle of least privilege is applied to network communication between microservice components.

Enable readOnlyRootFilesystem in the container's securityContext to prevent the malicious image from writing to disk.

Why it fails: A read-only root filesystem blocks persistence and some tampering at runtime, yet the malicious code in a substituted image still executes in memory and can exfiltrate secrets or alter behavior. It also fails to stop the image substitution itself, which is the actual risk described. The control mitigates post-exploitation effects rather than preventing the swapped image from being pulled and run.

Add a NetworkPolicy that restricts egress from the paymentsvc pods to only the payment processor's IP range.

Why it fails: An egress NetworkPolicy limits where a running container can send traffic, which reduces exfiltration paths, but it does nothing about which image the kubelet launches. A malicious image swapped in via the mutable latest tag would still execute with the same network restrictions and could still steal data over the permitted payment-processor channel, so this does not address the supply-chain concern.

Raise the pod's runAsUser to a high UID and add a seccomp profile of RuntimeDefault to the pod spec.

Why it fails: Running as an unprivileged UID and applying the default seccomp profile reduces the kernel attack surface available to any container, including a malicious one, but neither control verifies image integrity. The backdoored image would still be pulled from the registry and executed. These are defense-in-depth runtime controls, not mechanisms that bind the workload to a reviewed, immutable artifact.

AlwaysPullImages

Why it fails: AlwaysPullImages is an admission controller that forces image pulls on every pod creation, ensuring the latest image is used. It does not validate securityContext settings such as read-only root filesystems. It addresses image freshness, not filesystem security.

NodeRestriction

Why it fails: NodeRestriction is an admission controller that limits the permissions of kubelets, ensuring they can only modify their own Node and Pod objects. It does not enforce pod security settings like read-only root filesystems. It is unrelated to this requirement.

PodSecurityPolicy

Why it fails: PodSecurityPolicy (PSP) was deprecated in Kubernetes 1.21 and removed in 1.25. While it could enforce read-only root filesystems via the readOnlyRootFilesystem field, it is no longer available in current versions. Using it would not work in modern clusters.

AppArmor profiles applied via pod annotations

Why it fails: AppArmor confines a program's capabilities such as file access, network operations, and mount permissions based on path-based rules. While it is a kernel-level Mandatory Access Control mechanism, it does not filter system calls by number the way seccomp does. The question specifically asks about restricting system calls, which is seccomp's domain, not AppArmor's.

Kubernetes NetworkPolicy resources applied to the pod's namespace

Why it fails: NetworkPolicy controls pod-level ingress and egress traffic based on labels, ports, and CIDR blocks. It operates at the network layer and has no visibility into system calls. While valuable for segmentation, it does nothing to restrict the syscalls a container process can invoke against the host kernel, so it does not meet the analyst's requirement.

SELinux context labels applied to container processes

Why it fails: SELinux enforces type enforcement and multi-level security policies that restrict how processes interact with files, sockets, and other resources. It is a kernel MAC framework but does not operate by filtering individual system call numbers. The analyst's goal of restricting system calls is achieved by seccomp, not by SELinux labeling of container processes.

Store cloud provider credentials in base64-encoded Kubernetes Secret objects and mount them as environment variables.

Why it fails: Base64 encoding is merely obfuscation, not encryption at rest. Environment variables are notoriously insecure because they can be easily dumped by malicious processes running inside the container or exposed via debugging interfaces and container inspection logs.

Configure cluster-wide IAM roles on the underlying worker nodes and allow all hosted pods to inherit administrative permissions.

Why it fails: Inheriting node-level administrative permissions violates the principle of least privilege. Any compromise of a single low-risk pod would immediately grant an attacker full administrative control over all cloud provider resources accessible by that worker node.

Embed the static cloud API keys directly into the container base image layers to ensure consistency across deployments.

Why it fails: Embedding credentials inside container image layers makes them permanently accessible to anyone who pulls the image from the registry. Image layers persist sensitive data indefinitely even if the files are subsequently deleted in later build stages.

Implementing a read-only filesystem for the container at runtime.

Why it fails: While read-only filesystems limit the impact of an exploit by preventing runtime modification of local files, they do not verify the authenticity of the container image itself. This control is a defense-in-depth measure rather than a supply chain integrity validation mechanism for image distribution.

Using SHA-256 image digests instead of mutable image tags.

Why it fails: Digests provide content addressability which prevents tag-swapping attacks. However, they do not inherently provide cryptographic proof of the author's identity or verify that the image has not been maliciously tampered with during the transit between the build system and the private registry storage.

Scanning images for known vulnerabilities using a static analyzer.

Why it fails: Vulnerability scanning identifies known CVEs within the image layers but does not guarantee the integrity or origin of the code. An attacker could potentially modify an image to include a malicious backdoor while still maintaining a clean vulnerability report from the static scanning tools.

Disable all kernel modules on the host operating system.

Why it fails: Disabling all kernel modules is generally impractical, as many are required for network and storage operations. Furthermore, it does not prevent direct system call exploitation against the core kernel. While reducing modules can shrink the surface, it does not provide the robust isolation required for untrusted containerized workloads.

Increase the memory limit for every container in the cluster.

Why it fails: Adjusting resource limits is a capacity planning and availability task, not a security isolation control. Increasing memory does not prevent a malicious actor from exploiting vulnerabilities within the application code or the kernel. It may even provide more resources for an attacker to perform malicious activities like crypto-mining.

Run all containers with the --privileged flag to ensure compatibility.

Why it fails: The --privileged flag disables almost all security isolation features, granting the container full access to host devices and kernel capabilities. This is a severe security risk that enables trivial container escapes and host takeover. It should only be used in highly specific, trusted scenarios and never for general applications.

Encrypt the Dockerfile using a secret key before building.

Why it fails: Encrypting the Dockerfile does not protect secrets inside the resulting image layers. When the container builds, the secret must be provided in plaintext to the build environment. Furthermore, the final image manifest and layers will contain the decrypted version of the data, making it retrievable by any container runtime user.

Delete the secrets in a subsequent RUN layer during the build.

Why it fails: Deleting a file in a later Dockerfile layer does not remove the data from the underlying image history. The data persists in previous layers and can be easily recovered using image inspection tools. To remove data truly, one must use multi-stage builds where secrets are never present in the final image.

Set the file permissions on the secret to 600 after copying it.

Why it fails: Setting file permissions inside the container only restricts access to the file for processes running within that container. It does not prevent an attacker or an administrator from extracting the secret from the container image itself, as the file content is still stored permanently in the image layer metadata.

The pod will be unable to pull the image from the registry.

Why it fails: The securityContext defined in the pod specification governs the execution of the container process once started, not the image pulling process. The image pull is handled by the container runtime using credentials provided in the ImagePullSecrets, which are independent of the securityContext applied to the running application process.

The pod will block all network traffic from the container.

Why it fails: The securityContext shown does not contain any network-related configuration. Network isolation in Kubernetes is managed via NetworkPolicies, not through the Pod's securityContext. This pod will retain default network connectivity unless a NetworkPolicy is specifically defined in the cluster to deny or limit incoming and outgoing traffic to the pod.

The application will automatically have its vulnerabilities patched.

Why it fails: Security contexts provide runtime constraints, not automated vulnerability remediation. Even with these settings, an application could still be vulnerable to code-level exploits like SQL injection or buffer overflows. The context restricts what an attacker can do after exploitation, but it does not remove the underlying flaws in the code.

Enable the NodeRestriction admission plugin and rotate the kubelet client certificates on all worker nodes.

Why it fails: NodeRestriction limits what a kubelet can modify in the API, and certificate rotation hardens node identity, but neither affects whether a pod may mount a hostPath volume. The pod would continue to read /var/lib/kubelet because the mount is permitted by the namespace's privileged enforcement label. This option addresses node-to-API authorization, which is unrelated to the described filesystem exposure.

Add a seccomp profile of RuntimeDefault to the pod and set allowPrivilegeEscalation to false in its securityContext.

Why it fails: These runtime hardening settings limit syscall exposure and privilege escalation, but they do not prevent the hostPath volume from being mounted. The pod would still see the node's kubelet directory, and the restricted profile already requires these settings anyway, so the exposure persists. The real enabler is the permissive namespace label combined with the hostPath volume, neither of which this option changes.

Create an OPA Gatekeeper constraint that denies pods whose namespaces carry the privileged enforcement label.

Why it fails: Denying the label is a convoluted workaround that leaves the namespace's enforcement posture ambiguous and can break other workloads that legitimately need the exemption. It also does not remove the existing hostPath volume from the running pod or prevent the legacy job from being re-admitted under a different namespace. The straightforward fix is to remove the exemption and eliminate the hostPath mount, not to build a policy around the exemption.

It prevents the container from writing to its own filesystem, causing application failures.

Why it fails: Mounting the Docker socket does not affect the container's ability to write to its own filesystem. It provides access to the Docker daemon, which is a security risk, not a filesystem write restriction. Application failures would be due to other misconfigurations.

It exposes the container's internal ports to the host network, increasing the attack surface.

Why it fails: Mounting the Docker socket does not directly expose container ports; port exposure is controlled by the -p or --publish flags or the ports section in Compose. While port exposure can increase attack surface, it is not the primary risk of mounting the Docker socket.

It allows the container to bypass network policies and communicate with other containers without restriction.

Why it fails: While Docker socket access could be used to manipulate network settings, bypassing network policies is not the direct or primary risk. The immediate danger is the ability to control the Docker daemon, which can lead to host compromise. Network policies are typically enforced at the orchestration layer.

The container will be unable to write to any mounted volumes due to permission restrictions.

Why it fails: Running as root typically grants full permissions to write to mounted volumes, unless volume permissions are specifically restricted. This setting does not prevent writing; it actually gives broad access. The security concern is elevated privileges, not restricted access.

The container will run as a non-privileged user, enhancing security by default.

Why it fails: runAsUser: 0 specifies UID 0, which is the root user. This is the opposite of running as a non-privileged user. In Kubernetes, the default is often to run as the user defined in the image, which may be root, but explicitly setting UID 0 ensures root privileges.

The container will automatically drop all Linux capabilities, reducing its attack surface.

Why it fails: runAsUser: 0 does not affect Linux capabilities; capabilities are controlled separately via securityContext.capabilities. Running as root often retains default capabilities, which can be dangerous. Dropping capabilities is a separate security best practice that must be explicitly configured.

The pod is admitted but an audit annotation is added to the pod's metadata for later review.

Why it fails: This describes the 'audit' mode, not the 'restricted' profile. The restricted profile enforces strict controls and will reject non-compliant pods rather than merely annotating them. Annotations alone do not prevent the pod from running as root, which is the security concern in this scenario.

The pod is scheduled but the kubelet forcibly changes the container's user to a non-root UID at runtime.

Why it fails: The kubelet does not rewrite the container's user identity at runtime. User identity is determined by the image's USER instruction or the pod's securityContext. Pod Security Admission operates at the API server admission phase, not by mutating runtime behavior on the node, so this mechanism does not exist.

The pod is admitted and a warning is written to the API server logs, but no enforcement action is taken.

Why it fails: This describes the 'warn' mode behavior. The restricted profile in enforce mode does not simply log warnings; it denies the pod. Logging alone would not stop the root-running pods the engineer is trying to eliminate, leaving the multi-tenant cluster exposed to privilege escalation risks.

The .env file is recreated automatically by the base image's entrypoint at container start.

Why it fails: Base images do not recreate arbitrary files like .env at runtime. The actual exposure comes from how image layers are stored, not from any base image behavior. This distractor misattributes the leak to runtime behavior rather than to the immutable layer history that preserves the file's contents.

Docker automatically backs up deleted files into a hidden volume that is mounted into every container.

Why it fails: Docker does not create hidden backup volumes for deleted files. Volumes are explicitly declared and are not used to preserve deleted build artifacts. The real issue is that image layers are additive and immutable, so a deletion in a later layer does not remove the file from earlier layers.

The .env file is cached in the Docker daemon's build cache and pushed to the registry alongside the image manifest.

Why it fails: The build cache is local to the daemon and is not part of the image manifest pushed to a registry. The credentials leak because of layer immutability in the image itself, not because of cache propagation. This option confuses local build caching with the contents of the published image.

Enabling audit logging on the API server to record all requests made by service accounts.

Why it fails: Audit logging records what happens but does not restrict what a service account can do. The attacker would still be able to list secrets and query the API server; the logs would only document the activity after the fact. The team's goal is to limit the blast radius, which requires authorization controls, not observability.

Disabling the automountServiceAccountToken field on the pod spec so no token is projected into the container.

Why it fails: Disabling token automount prevents the pod from receiving a service account token, which does limit API access. However, the question asks what most directly limits what the service account can do when a token is present. Removing the token is a valid hardening step but does not address the authorization scope if a token is obtained by other means.

Applying a NetworkPolicy that blocks egress from the pod to the API server's ClusterIP.

Why it fails: Blocking egress to the API server would prevent the pod from reaching it, but many applications legitimately need API access for service discovery or controllers. It is a blunt control that can break functionality and does not address authorization if the token is used from another network path. The precise control for limiting what a service account can do is RBAC scoping, not network isolation.

runc with user namespaces enabled

Why it fails: User namespaces map container UIDs to unprivileged host UIDs, which reduces the impact of a container escape but still shares the host kernel. The kernel remains the same attack surface, so a kernel vulnerability could still be exploited from within the container. The requirement explicitly demands kernel isolation, which user namespaces do not provide.

CRI-O with the default runtime configured for SELinux enforcement

Why it fails: CRI-O is a Kubernetes-native container runtime, and SELinux enforcement adds mandatory access control on top of shared-kernel containers. It hardens the container against certain attacks but does not isolate the kernel. The requirement for a separate kernel is not met by SELinux policy enforcement alone, regardless of the runtime.

containerd configured with the default runc shim

Why it fails: containerd with the default runc shim uses standard Linux namespaces and cgroups, and containers share the host kernel. While containerd is a production-grade runtime, it does not provide the kernel-level isolation the requirement demands. It is the baseline against which stronger runtimes are compared, not a solution to the stated requirement.

The instruction allows the build host's environment variables, including registry credentials, to be exfiltrated by the remote script.

Why it fails: Build-time ARG and ENV values can be exposed to RUN commands, but the scenario does not establish that sensitive variables are present in the build context. The remote script could read them if they were injected, yet that is a conditional risk, not the primary supply chain risk introduced by piping an unverified remote script into a shell.

The curl command creates a writable layer that persists at runtime and can be modified by an attacker after deployment.

Why it fails: The RUN instruction only affects the image during build; its filesystem changes are committed to the image layer, not made writable at runtime. A container's writable layer is created from the image at start, so this instruction does not create a persistent writable path that an attacker can modify post-deployment.

The instruction bypasses Kubernetes NetworkPolicy because build-time traffic does not originate from a pod in the cluster.

Why it fails: NetworkPolicy governs pod network traffic inside the cluster, not image build traffic on a build host. The build occurs before deployment, so NetworkPolicy is irrelevant here. The real issue is the unverified remote code being incorporated into the image, which is a supply chain integrity problem rather than a network policy bypass.