Select Two (Multi-Select) Questions

They improve container performance over native runc

Why it fails: Sandboxing generally adds overhead and reduces performance compared to native runc, not improves it. gVisor incurs latency by intercepting and translating system calls through a user-space kernel, while Kata Containers pays the cost of booting a lightweight virtual machine and performing hardware-virtualized I/O. CPU-, syscall-, or network-heavy workloads can see noticeably lower throughput and higher latency, so sandboxes are chosen for stronger isolation rather than speed.

They use the host kernel directly for all system calls

Why it fails: The defining behavior of native runc is executing containers with direct access to the host kernel for system calls; sandboxes explicitly avoid that. gVisor intercepts system calls and either emulates them or converts them into guarded host operations through a user-space kernel, while Kata routes system calls to an isolated guest kernel inside a VM. Thus a sandboxed container never makes unfiltered, direct syscalls to the host kernel, which is exactly what makes it more resistant to kernel-based container escape attacks than runc.

Use environment variables from the pod spec referencing Secret keys.

Why it fails: Using env vars with valueFrom.secretKeyRef avoids hardcoding plaintext secrets in the image, but the resolved secret value is injected as an environment variable at container startup and becomes visible in /proc/<pid>/environ, which can be read by any process on the host or any container sharing the process namespace. Environment variables are also prone to leaking into logs through error messages or debugging tools, and they are immutable during the pod's lifetime: rotating the Secret object will not update the already-running container until the pod is restarted. Compared to volume mounts, this method lacks the ability to update secrets dynamically and exposes them through a broader attack surface.

Pass secrets as command-line arguments to the container.

Why it fails: Passing secrets as command-line arguments in the container spec is extremely insecure because the arguments are stored in the pod spec, which is persisted in etcd, and the fully expanded command line is visible in the container runtime process listing via ps or /proc/<pid>/cmdline. Any process with access to the node or to the container runtime can retrieve the plaintext secret, and audit logs, monitoring agents, and debugging tools routinely capture command-line arguments. Unlike environment variables, command-line arguments are also visible to any user who has permission to read the pod definition, regardless of RBAC restrictions on Secrets. This method has no built-in rotation, no access auditing, and should never be used for sensitive data.

Store secrets in ConfigMaps with base64 encoded data.

Why it fails: ConfigMaps are designed for non-sensitive configuration data, and storing secrets there is a fundamental misuse because base64 encoding is trivially reversible and provides no confidentiality whatsoever. The encoded data is stored in etcd as part of the ConfigMap object, and any RBAC rule that grants access to ConfigMaps would expose the secret bytes to an attacker. Kubernetes Secrets, while also base64-encoded by default, are a separate API object with stricter access controls and a designated path to enable encryption at rest (e.g., KMS); ConfigMaps have no such protection. Even if you base64-encode a value inside a ConfigMap, it is still plaintext-equivalent and offers none of the security guarantees expected of a secret management system.

Docker

Why it fails: Docker is a full-featured container platform that includes an engine/daemon, image management, networking, and CLI, but it is not itself a sandboxing layer. Historically, Docker delegated container execution to runc, and later to containerd, both of which rely on standard Linux namespaces and cgroups for isolation. Because it does not introduce a guest kernel or user-space kernel filter, Docker offers no stronger sandbox than the underlying OCI runtime it happens to use.

containerd

Why it fails: containerd is a CRI-compatible daemon that manages the complete container lifecycle, from image pulling and storage to the creation and deletion of containers. When Kubernetes invokes containerd, containerd simply spawns a low-level OCI runtime — such as runc, runsc, or Kata's shim — based on the configured runtime handler. That configuration is what determines whether a sandbox is present, so containerd itself adds no security boundary and is not a sandboxing technology.

runc

Why it fails: runc is the reference OCI runtime that executes containers by directly forking processes into fresh namespaces and cgroups on the host kernel. It applies seccomp profiles, capabilities, and other standard security hardening, but these are ordinary kernel isolation primitives rather than an actual sandbox. A malicious syscall therefore still reaches the host kernel, which is why runc-based containers are considered less secure than gVisor or Kata workloads.

Store secrets in ConfigMaps and use them in pods

Why it fails: ConfigMaps are designed for non-sensitive configuration data and have no native encryption mechanism; they are stored as plaintext in etcd using base64 encoding, which is trivially reversible. Even if you enable EncryptionConfiguration, ConfigMaps are not intended to hold confidential material, and using them for secrets exposes data to any user with read access to the resource. Moreover, Secret objects support fine-grained RBAC and are the configured input for many Kubernetes integrations, whereas ConfigMaps lack the same data-encryption semantics. Because ConfigMaps are not encoded with any confidentiality guarantee, storing secrets in them is a security anti-pattern.

Commit secrets to a private Git repository

Why it fails: Committing secrets to a private Git repository does not protect them from compromise: anyone with repository access—including contractors, CI/CD pipelines, or a compromised developer laptop—can read them, and they are permanently persisted in the commit history even after deletion. Git itself does not encrypt file contents at rest, and protection relies entirely on repository permissions that are notoriously difficult to keep tight across teams. Additionally, rotating a secret that lives in Git requires rewriting history and may still leak the old value through forks, caches, or pull-request diffs. This is why modern practices use dedicated secret-management tools like SOPS or git-crypt that encrypt secrets before committing.

Store secrets directly in the application code

Why it fails: Hardcoding secrets directly in application code is insecure because it couples the secret to the source code and exposes it to anyone who can read the repository or inspect the compiled artifact. It also makes rotation extremely difficult: you must modify, rebuild, and redeploy the application every time the secret changes, which increases the risk of outages and leaks. Secrets in code may also be logged, printed in stack traces, or displayed in debuggers, and they violate the principle of least privilege by giving every developer access to every secret. Secure alternatives include referencing Secrets mounted as volumes or using environment variables, both of which can be updated independently of the application code.

Set the container image to use a root user

Why it fails: Configuring the container image to use a root user explicitly sets the effective UID to 0 for every process in the container. This directly contradicts the requirement to enforce non-root execution, as root privileges are granted by default. This is not a policy or enforcement mechanism; it merely ensures the container runs as the most privileged user, making the workload unsafe and non-compliant.

Use a PodSecurityPolicy (PSP)

Why it fails: PodSecurityPolicy (PSP) was an admission controller that could enforce non-root and other security constraints, but it has been deprecated since Kubernetes 1.21 and completely removed in v1.25. In current Kubernetes releases, the PSP API object no longer exists, so referencing it as a valid enforcement method is obsolete and would fail in a real cluster. Its official replacement is Pod Security Admission (PSA), which uses predefined standardized profiles, or external policy engines such as Kyverno or OPA Gatekeeper.

Set runAsUser: 0 in the container securityContext

Why it fails: Setting `runAsUser: 0` in the container's securityContext explicitly sets the process's UID to 0, which is the root user. This is the exact opposite of enforcing non-root execution, as it forces the container to run with full root privileges. This configuration does not enforce any security restriction; rather, it is a common misconfiguration that exposes the container to serious security risks.

Use trivy image to check for vulnerabilities

Why it fails: Trivy is a vulnerability scanner that analyzes installed packages and dependencies for known CVEs (e.g., via vulnerability databases) and misconfigurations. It does not, however, provide any cryptographic guarantee of image integrity — it never verifies a digest or signature, so a tampered image with no known vulnerabilities would pass a Trivy scan undetected. Thus, scanning for vulnerabilities is a security best practice but not a valid method for integrity verification.

Use docker history to view layers

Why it fails: docker history displays the build-time command history and layer metadata for an image, including the commands run in each step and the layer sizes. This output is informational; it does not generate or compare any cryptographic checksums, and it can even be influenced by build context or history annotations. Therefore, it cannot detect modification of image content and is not a valid integrity verification method.

Use kubectl describe pod to check image details

Why it fails: kubectl describe pod retrieves the pod's specification from the Kubernetes API and shows the image reference (e.g., name:tag) that was requested, but it does not inspect the actual container image content fetched from a registry. The command never verifies the image digest, signature, or authenticity — it merely reflects the image string in the pod spec. Consequently, it cannot catch tag mutability, registry compromise, or anything related to the image's actual bytes.

Add multiple ClusterRoleBindings to a single service account to ensure it has access to all resources

Why it fails: Adding multiple ClusterRoleBindings to a single service account expands its effective permissions beyond what is necessary, directly violating least privilege. Each ClusterRoleBinding grants a distinct set of RBAC rules cluster-wide, so stringing together several bindings to ‘ensure access to all resources’ creates a superuser-like service account that can read or modify any object. This not only broadens the attack surface but also makes auditing confusing because the effective permissions are the union of all bound roles. Least privilege means granting only the minimum permissions needed for the workload, not aggregating broad access for convenience.

Use the default service account for all workloads

Why it fails: Using the default service account for all workloads is dangerous because the default service account in a namespace is automatically mounted with a token and, depending on the cluster configuration, may have additional permissions (e.g., the ability to list secrets or access the Kubernetes API). Default accounts are shared, so any workload that uses them inherits whatever permissions are bound to that account, which are often broader than needed. This practice also removes the ability to audit which workload accessed which resource, as all pods appear as the same identity. For least privilege, you should create a dedicated service account per workload or logical group, with only the RBAC rules that workload requires.

Grant cluster-admin ClusterRole to the service account for simplicity

Why it fails: Granting the cluster-admin ClusterRole to a service account gives it unrestricted, cluster-wide superuser permissions, which is the exact opposite of least privilege. The cluster-admin role can perform any action on any resource, including deleting nodes, reading secrets from all namespaces, and modifying RBAC policies. If such a service account is compromised, the attacker effectively owns the entire cluster, allowing lateral movement and data exfiltration across all workloads. Instead, you should bind narrowly scoped roles and use RoleBindings within namespaces where possible; cluster-admin should be reserved only for human cluster administrators, never for application service accounts.

Allow privileged containers for system-critical workloads.

Why it fails: Privileged containers essentially disable all Linux security controls, including seccomp, AppArmor, and capability dropping, giving them near-host-level access. They can access host devices, manipulate the iptables/netfilter stack, and even run privileged operations that normally require root on the host. For system-critical workloads, there are always better alternatives: either run them as non-privileged with the specific capabilities they need (such as NET_ADMIN for kube-proxy) or use dedicated node agent patterns. Allowing privileged containers violates the principle of least privilege and is explicitly prevented by baseline and restricted PSS profiles.

Allow containers to use hostNetwork for easier service discovery.

Why it fails: Setting hostNetwork: true places the container directly in the node's network namespace, so it shares the host IP and network stack. This breaks network isolation, creates port collision risks with other daemons, and exposes the container to host-level network policies and raw traffic sniffing. It also increases the blast radius of a container compromise, as an attacker gains visibility into all host traffic. Kubernetes-native service discovery via DNS and ClusterIP Services makes hostNetwork unnecessary for normal workloads; only a few node-level agents like cAdvisor or kube-proxy might need it, and those should be tightly controlled.

NetworkPolicy

Why it fails: NetworkPolicy is a namespaced Kubernetes resource that controls traffic flow between pods, namespaces, and external endpoints at the network layer (L3/L4). It is completely unrelated to authorization of API requests; RBAC restricts what a user or service account can do with the Kubernetes API, not which pods can communicate with each other. Therefore, NetworkPolicy cannot implement RBAC.

PodSecurityPolicy

Why it fails: PodSecurityPolicy was an admission controller resource that enforced security constraints on pod specifications, such as privileged mode, host namespaces, and allowed capabilities. It never defined user permissions or API access rules, so it was not a component of RBAC. Moreover, PodSecurityPolicy was deprecated in Kubernetes 1.21 and removed in 1.25, making it even less relevant to current RBAC implementations.

ServiceAccount

Why it fails: ServiceAccount is an identity object used by pods to authenticate to the Kubernetes API server. While RBAC involves granting permissions to service accounts through Roles or ClusterRoles and their bindings, the ServiceAccount resource itself contains no permission rules—it merely represents a non-human principal. Thus, a ServiceAccount is a subject for authorization, not an RBAC resource that defines permissions.

Set --anonymous-auth=true to allow all users

Why it fails: Setting --anonymous-auth=true makes the kube-apiserver accept unauthenticated requests, attributing them to the synthetic system:anonymous user. While RBAC might restrict this user, any unauthenticated attacker who can reach the API server endpoint (e.g., via a misconfigured NetworkPolicy, a compromised pod, or a public ingress) gains the ability to enumerate endpoints, read resources if RBAC allows, or potentially exploit additional misconfigurations. This flag should be false in production, forcing every request to carry valid credentials, otherwise authentication becomes a mere formality and the cluster's security boundary collapses.

Enable audit logging to detect unauthorized attempts

Why it fails: Audit logging is a detective control that records a chronological trail of API requests, including who made them, what they accessed, and the outcome. It does not intercept or block malicious actions at execution time; if an attacker has already passed authentication and authorization, they can still perform their actions before any log-based alert triggers. Hardening measures must be preventive, such as NodeRestriction for limiting node privileges or client TLS certificates for establishing identity, while audit logs serve only for post-incident analysis and compliance, not as a barrier against the initial threat.

Disable all authentication mechanisms and rely on network policies

Why it fails: Disabling all authentication mechanisms and relying solely on network policies fundamentally misunderstands the threat model: network policies filter pod-to-pod and pod-to-service traffic at the CNI layer, but they do not police who can issue HTTP requests to the kube-apiserver, which is a workload itself often exposed on a cluster-facing port. Without authentication, every request to the API server is effectively anonymous, so any process with network access—including a compromised pod in a different namespace or a rogue container on a host—can call admin endpoints. Network policies also cannot distinguish between legitimate and malicious API verbs, making this an unworkable substitute for identity-based security.

PreProcessing

Why it fails: There is no audit stage called PreProcessing in Kubernetes. The valid audit stages are strictly RequestReceived, ResponseStarted, ResponseComplete, and Panic. This term might be confused with the admission controller phases, but audit events are not generated during a preprocessing phase. The request lifecycle is captured only at the four defined stages, and any other name is not a real audit stage.

None

Why it fails: 'None' is not an audit stage; it is one of the four valid audit levels (None, Metadata, Request, RequestResponse) that determine how much information is logged. Setting the level to None disables audit logging for a particular rule, but it does not represent a point in the request lifecycle. Stages identify when an event is emitted, while levels specify the verbosity of the event, so confusing them is a common mistake.

PostProcessing

Why it fails: There is no PostProcessing stage in Kubernetes audit. The closest valid stage is ResponseComplete, which is emitted after the entire response has been written to the client. The term might imply a phase after request processing, but Kubernetes uses ResponseComplete instead, and audit events are not generated after the request has been fully handled. Therefore, PostProcessing is not a recognized stage in the audit policy.

Seccomp profiles can only be applied to privileged containers

Why it fails: This statement is false: seccomp is a kernel-level syscall filter that applies equally to privileged and non-privileged containers. The privileged flag in Kubernetes expands capabilities and device access, but it does not control or require seccomp filters. In fact, seccomp is most beneficial for unprivileged containers because it reduces attack surface, and privileged containers can also be constrained by seccomp to mitigate their elevated privileges.

Seccomp can only restrict system calls, not allow them

Why it fails: Seccomp profiles are actually BPF programs that can both prohibit and permit individual system calls. A common pattern is a whitelist profile, where all syscalls are denied by default and only specific ones are explicitly allowed. Profiles can also return custom error codes like EPERM or EACCES, so they do more than simply restrict execution; they give fine-grained control over the syscall interface.

medium

Why it fails: 'medium' is not a defined Pod Security Standard (PSS) level. The Kubernetes Pod Security Admission controller recognizes exactly three enforcement levels: privileged, baseline, and restricted. Namespace labels such as pod-security.kubernetes.io/enforce must be set to one of these three values, so 'medium' is not a valid selector and cannot be used to enforce a security profile.

high

Why it fails: 'high' is also not one of the three Pod Security Standards levels. The standards are strictly ordered by increasing restriction: privileged, baseline, and restricted; 'high' does not fit into this ordering. Pod Security Admission accepts only 'privileged', 'baseline', or 'restricted' as valid values for the enforce, audit, and warn labels, so 'high' is invalid.

default

Why it fails: 'default' is an informal description of the behavior when no Pod Security Standard is applied, but it is not an actual PSS level. In a cluster without enforcement labels, the API server allows any Pod, which is often called 'default' or 'permissive', yet this is simply the absence of a policy, not a named level. The only valid level names are privileged, baseline, and restricted, so 'default' cannot be selected.

--plugin-dir=/admission

Why it fails: The --plugin-dir flag is not a valid kube-apiserver flag for enabling admission plugins. The correct way to enable admission controllers is via --enable-admission-plugins; plugin directories are not used by the API server to discover admission plugins. The flag appears may be confused with --plugin-dir for certain CLI tools, but it has no effect on admission control.

--admission-control=NodeRestriction

Why it fails: The --admission-control flag was the old, deprecated flag used in older Kubernetes versions (pre-1.10) to enable admission controllers. In modern Kubernetes, it has been replaced by --enable-admission-plugins, and using the deprecated flag with a newer API server will not enable the controller; it may either be ignored or cause an error depending on the version. Thus, this flag is no longer valid for enabling NodeRestriction.

Use TokenReview API for authentication

Why it fails: Use TokenReview API for authentication (wrong): While the TokenReview API is a legitimate Kubernetes object used to validate bearer tokens in webhook authentication flows, it is not listed as a recommendation in the CIS Kubernetes Benchmark. CIS guidance centers on concrete hardening controls like disabling anonymous access, enabling audit logging, and configuring RBAC, rather than prescribing specific authentication mechanisms. Treating TokenReview as a CIS-mandated security control is incorrect; it is an optional implementation detail for custom authenticators, not a benchmark requirement.

Set --protect-kernel-defaults=false on kubelet

Why it fails: Set --protect-kernel-defaults=false on kubelet (wrong): CIS actually requires setting --protect-kernel-defaults=true on the kubelet, not false. This flag instructs the kubelet to fail or error if kernel parameters—such as sysctl values encompassed by the kernel.* and net.* namespaces—are changed from their system defaults, which could compromise node security or container isolation. Setting it to false disables this safeguard, permitting unsafe kernel tuning that may break the node or weaken the security boundary. Therefore, this option is the opposite of the CIS recommendation and is incorrect.

Enable the insecure port for kubelet

Why it fails: Enable the insecure port for kubelet (wrong): The kubelet's insecure port, historically listening on 10255, serves API requests without requiring authentication or TLS, exposing node information and potentially allowing write access to all containers and pods on the node. CIS Kubernetes Benchmark explicitly mandates that the insecure port be disabled by setting --port=0, and also that the read-only port (--read-only-port=0) be disabled, leaving only the secure authenticated endpoint on 10250. Enabling this port would allow any network-adjacent attacker to retrieve sensitive cluster data and issue destructive commands, directly contradicting CIS hardening guidance.

Open all ports on nodes to allow easy debugging

Why it fails: Opening all ports on nodes removes the network access controls that protect node services and pod traffic. This practice directly contradicts the security principle of default deny: it allows any network attacker to reach any service on the node, including kubelet's unauthenticated read-only port (10255) or other sensitive management interfaces. For debugging, Kubernetes provides safer alternatives such as kubectl port-forward, ephemeral containers, or temporarily creating a NetworkPolicy to allow specific traffic. Exposing all ports also bypasses the Egress/Access control that firewalls and security groups provide, making the node trivially reachable from the internet or other untrusted networks.

Run all containers as root user

Why it fails: Running containers as root is the reverse of least privilege and is especially dangerous on Kubernetes. Although processes inside a container are namespaced, the root user still has root-equivalent capabilities (like CAP_SYS_ADMIN, CAP_NET_ADMIN) over the container's kernel namespace, and a kernel vulnerability can let them break out to the host. Kubernetes best practices require setting securityContext.runAsNonRoot: true and runAsUser to a non-root UID to reduce privilege; many images also run with read-only root filesystems. Root containers also make filesystem writes more impactful—for example, filling /var/log or /var/lib/kubelet could disrupt the whole node.

Configure RBAC for etcd

Why it fails: Kubernetes RBAC applies to the Kubernetes API server, not directly to etcd, which is a separate datastore. etcd does offer its own user/role object model, but in standard cluster deployments access is enforced through mutual TLS client certificate authentication, not RBAC. Configuring RBAC is therefore not one of the required controls to secure etcd itself.

Allow anonymous access for monitoring

Why it fails: Allowing anonymous access to etcd means any unauthenticated client can read or modify the entire cluster state, including secrets, without presenting credentials. This completely undermines the confidentiality and integrity of the datastore. Monitoring should be performed using authenticated read-only accounts or dedicated agent certificates, never by permitting anonymous connections, making this practice inherently insecure.

--dry-run

Why it fails: --dry-run is a client-side flag that prints the Kubernetes object that would be created without actually sending it to the API server. It is often paired with -o yaml or -o json to output the manifest for review or further editing. It neither accepts nor processes secret data from a file; it merely simulates the operation, so it is not an argument for specifying file content and does not contribute to creating a secret from a file.

--from-literal

Why it fails: --from-literal is used to supply secret data directly as key=value pairs on the command line (e.g., --from-literal=password=secret). It does not read an external file's contents at all, so it cannot fulfill the requirement of creating a secret from a file. This flag is intended for inline, ad-hoc values rather than file-based input, making it incorrect for this specific scenario.

--from-yaml

Why it fails: --from-yaml is not a recognized flag for kubectl create secret; the valid data-source flags are --from-file, --from-literal, and --from-env-file. There is no built-in support for reading a YAML file directly as a secret source via this subcommand. To create a Secret from a YAML manifest, you would use kubectl apply -f on a Secret manifest rather than a creation flag, so --from-yaml is simply invalid.

audit

Why it fails: Audit is not an AppArmor mode; it is a flag combined with enforce or complain to log confined actions without blocking them. It tempts because audit logging sounds like a profile state, yet the two selectable modes are enforce and complain.

allow

Why it fails: Allow is not an AppArmor mode; it is a rule action inside a profile, permitting specific file or capability access. It tempts because profiles contain allow rules, yet the two modes are enforce, which blocks violations, and complain, which only logs them.

unconfined

Why it fails: Unconfined is not one of the two AppArmor profile modes; it describes a process running without any profile applied. It tempts because unconfined processes appear in tooling output, but the selectable modes are enforce and complain.

Manually inject sidecar proxies into every pod to enforce mTLS.

Why it fails: Manually adding sidecar proxies to every Pod is not a secure, scalable mTLS strategy: it relies on human consistency, so any Pod that misses the injection will communicate using plaintext traffic and violate the service-mesh policy. Every Pod should instead be intercepted automatically by a mutating admission webhook or a managed sidecar injection mechanism (e.g., Istio or Linkerd), which labels and rewrites Pod specs consistently. Manual injection also complicates upgrades and forces operators to manage proxy configuration drift, creating gaps in identity coverage and encrypted connectivity between services.

Run containers in privileged mode to allow them to perform necessary system calls.

Why it fails: Privileged mode is far broader than simply allowing necessary system calls: it disables most container isolation, grants all capabilities (including CAP_SYS_ADMIN), exposes host devices, and effectively lets the process operate as root on the host for kernel operations, making container escape trivial if the workload is compromised. Kubernetes workloads almost never need this; instead, the correct hardening step is to drop all capabilities, add only the required Linux capabilities, and apply a seccomp profile that filters the exact system calls. Running privileged to satisfy a few syscalls needlessly elevates every microservice to maximum host access.

Store secrets directly in container images for easy access.

Why it fails: Baking secrets into a container image is fundamentally insecure because every image is built from immutable layers; anyone who can pull the image from a registry, cached copy, or CI artifact can inspect the layer history and extract plaintext credentials. Secrets placed in images also spread across base images and tags, making revocation and rotation impractical and turning each image into a persistent credential leak. Use Kubernetes Secrets (with RBAC, encryption at rest, and short-lived credentials) or an external secrets manager so secrets are delivered only to the Pod that actually needs them.