System Hardening practice questions

Use OPA Gatekeeper to deny pods without readOnlyRootFilesystem

Why it fails: While possible, OPA Gatekeeper is an external tool; the question asks for the most effective built-in approach.

Enable PodSecurityPolicy with readOnlyRootFilesystem: true

Why it fails: PodSecurityPolicy is deprecated but still available in Kubernetes 1.24 and is scheduled for removal in 1.25. Although it can enforce readOnlyRootFilesystem, it is not the most effective forward-looking approach compared to the built-in PodSecurity admission controller with the restricted profile.

Set --read-only-port=0 in kubelet

Why it fails: This disables the read-only port but does not enforce read-only filesystem for containers.

Run the container with privileged: true

Why it fails: Setting privileged: true grants the container all capabilities, including CAP_SYS_ADMIN, and disables most security mechanisms like seccomp, AppArmor, and SELinux. This effectively equates the container to a host process, allowing unrestricted access to devices, kernel modules, and the host filesystem. While it may technically enable the kernel modification, it exposes the entire node to compromise and violates the principle of least privilege, making it an unacceptable solution in any serious cluster.

Add SYS_ADMIN capability to the container

Why it fails: Adding the SYS_ADMIN capability grants a broad set of administrative operations on the kernel namespace, including mounting filesystems, manipulating the network namespace, and loading kernel modules. While less extreme than privileged: true, SYS_ADMIN is often considered the ability to escape container isolation; for example, it can be abused to remount the host root filesystem or access host devices. The kernel treats this capability as a superuser override, and Kubernetes security best practices strongly discourage granting it to untrusted workloads.

Modify kubelet's --sysctl-whitelist to include the needed sysctl

Why it fails: Modifying the kubelet's --sysctl-whitelist to include the needed sysctl is a cluster-level change that affects every pod on the node. This approach is deprecated and not applied per-pod; moreover, enabling an unsafe sysctl globally exposes all workloads to potential kernel instability or security vulnerabilities. It also contradicts the Kubernetes admission control model, where pod-level securityContext settings should govern permissions, and requires direct intervention on the node, which is both operationally risky and often impossible in managed Kubernetes clusters.

Deploy OPA Gatekeeper and create constraints to enforce read-only root filesystem, no privilege escalation, and non-root user, with exceptions via label selectors

Why it fails: OPA Gatekeeper is a general-purpose policy engine that can enforce these standard controls via custom Rego constraint templates, but deploying it adds a webhook, constraint template CRDs, and ongoing Rego maintenance. The native Pod Security Admission controller provides the same standard restricted controls out of the box, integrated directly into the API server, with far less operational overhead and no need to define exception logic in a separate control plane. For this use case, Gatekeeper is over-engineered when a simpler native solution exists.

Keep the current 'privileged' profile and rely on runtime security tools like Falco to detect violations

Why it fails: Relying solely on Falco shifts security to detection after a pod has already violated policy; a privileged pod can immediately perform host-level actions before any alert is processed. The CISO mandates are admission-time requirements—read-only root filesystem, no privilege escalation, and non-root user—that must be enforced before a pod is created, which Falco does not do. Falco is a valuable runtime monitoring layer for detection, but it complements rather than replaces proactive, preventive controls.

Change the PodSecurity profile to 'restricted' cluster-wide and require all legacy apps to be rewritten to not need hostNetwork/hostPID

Why it fails: Applying the restricted profile to every namespace cluster-wide with no exceptions will cause any workload that needs hostNetwork, hostPID, privileged, or a runAsNonRoot user to fail to schedule, and legacy apps may not have a compatible image or code to change immediately. This hard cutover removes the ability to phase in the policy and forces a rewrite or significant reconfiguration of all workloads at once, which is operationally risky. The correct strategy is to enforce restricted where possible and explicitly allow exceptions via namespace labels for workloads with documented justification.

Set --anonymous-auth=true

Why it fails: Setting --anonymous-auth=true explicitly allows requests that no configured authenticator (client certificates, bearer tokens, etc.) can identify as a known user; kubelet then treats them as `system:anonymous` with group `system:unauthenticated`. This leaves the door open for unauthenticated clients to reach the kubelet's HTTPS API on port 10250 if RBAC or the kubelet's authorization settings permit it. For hardening, anonymous auth must be disabled so every request must carry verifiable credentials.

Set --read-only-port=10255

Why it fails: Setting --read-only-port=10255 enables or leaves enabled the kubelet's unauthenticated read-only port. Hardening requires disabling the read-only port with --read-only-port=0 and/or setting --anonymous-auth=false to reject unauthenticated requests on the main HTTPS port.

Set --authentication-token-webhook=false

Why it fails: Setting --authentication-token-webhook=false disables the kubelet's ability to validate bearer tokens by calling the API server's TokenReview endpoint, so service account tokens and other webhook-authenticated identities are no longer trusted. This removes a secure authentication path and makes the node less secure; it does not itself allow anonymous access, but it makes the kubelet fall back to fewer authentication mechanisms and can break legitimate authenticated requests. Hardening requires enabling token webhook authentication, not disabling it.

Create a PodSecurityPolicy with requiredDropCapabilities: [NET_RAW] and assign it to a role binding

Why it fails: Incorrect. PodSecurityPolicy (PSP) is deprecated and removed in Kubernetes v1.25+. It should not be used in current clusters.

Configure kubelet with --allowed-unsafe-sysctls to restrict capabilities

Why it fails: Incorrect. The kubelet flag --allowed-unsafe-sysctls is for sysctls, not for dropping capabilities.

Modify each deployment to include securityContext.capabilities.drop: [NET_RAW]

Why it fails: Incorrect. While this works, it is not cluster-wide enforcement; it requires modifying each deployment individually, which is not scalable for all containers.

Change runAsUser to 0

Why it fails: Changing runAsUser to 0 does not resolve the conflict because the pod's securityContext still has runAsNonRoot: true. In Kubernetes, when runAsNonRoot is true, the kubelet refuses to start the container if the effective UID is 0 — even if that UID is explicitly set by runAsUser. Therefore, setting runAsUser to 0 directly violates the runAsNonRoot assertion, and the pod will continue to be rejected with the same error.

Use a different image that runs as non-root

Why it fails: Switching to an image that is designed to run as a non-root user would indeed satisfy the runAsNonRoot constraint, making it a viable workaround. However, the question specifically asks for a change to the given manifest, not a replacement of the image. Moreover, swapping images can introduce different behavior, dependencies, or vulnerabilities, so it is not the minimal or expected fix for this scenario — the correct manifest-level change is to adjust the securityContext.

Add NET_ADMIN capability

Why it fails: Adding the NET_ADMIN capability has no effect on the runAsNonRoot error because capabilities and user ID constraints are separate security mechanisms in Kubernetes. The runAsNonRoot check is performed by the kubelet as part of the container security context validation, and it only verifies that the container's UID is not zero. Granting capabilities such as NET_ADMIN gives the container additional kernel privileges but does not alter the effective user ID, so the pod will still be blocked for the same reason.

The pod has a higher priority than the PSP

Why it fails: Pod priority is a scheduling mechanism that controls the order in which pending pods are scheduled onto nodes; it never influences admission control. The PodSecurityPolicy admission controller evaluates the pod's security context against allowed policies at creation time, and priority is not a factor in that decision. A high-priority pod does not bypass or override PSP enforcement.

The PodSecurityPolicy admission controller is not enabled

Why it fails: Although disabling the PodSecurityPolicy admission controller would indeed render all PSPs ineffective, the scenario implies that PSPs are in use and expected to govern pod creation. If the controller were disabled, no binding or PSP would ever matter, which is a distinct failure mode from the authorization gap described. Moreover, even with the controller enabled, a PSP must be authorized for the creating user; simply being enabled is not sufficient.

The PodSecurityPolicy is defined after the pod creation

Why it fails: PSP enforcement happens at admission time, which occurs when a pod is created or updated, so the relative creation order of the PSP object and the pod is irrelevant. If a PSP is created after a pod, that pod was never subject to the policy, but that does not explain why a later-created pod would bypass a policy that supposedly applies. The decision is based on the PSP's existence and the user's authorization at the moment the pod is submitted, not on object creation chronology.

securityContext: capabilities: drop: ["ALL"] add: ["ALL"]

Why it fails: Adding ALL after dropping ALL is pointless; it grants all capabilities again.

securityContext: capabilities: drop: ["CHOWN","DAC_OVERRIDE"]

Why it fails: This only drops two specific capabilities, not all. The policy requires dropping all capabilities first.

securityContext: capabilities: add: ["NET_BIND_SERVICE"] drop: ["ALL"]

Why it fails: The order in the YAML does not matter; however, it is conventional to drop first then add. But functionally this is correct if drop ALL is included. However, option D is more explicit and common.

baseline

Why it fails: Baseline disallows privilege escalation but does not prevent containers from running as root; it does not require runAsNonRoot.

privileged

Why it fails: Privileged allows running as root and allows privilege escalation.

default

Why it fails: Default is not a valid PSS level.

unrestricted

Why it fails: Unrestricted is not a valid PSS level.

apparmor.security.beta.kubernetes.io/container-name: "k8s-apparmor-example-deny-write"

Why it fails: Incorrect. The annotation key should be 'container.apparmor.security.beta.kubernetes.io/<container-name>', not 'apparmor.security.beta.kubernetes.io/...'.

container.apparmor.security.beta.kubernetes.io/pod-name: "k8s-apparmor-example-deny-write"

Why it fails: Incorrect. The annotation key format is wrong; it should be 'container.apparmor.security.beta.kubernetes.io/<container-name>' and not 'container.apparmor.security.beta.kubernetes.io/pod-name'.

container.apparmor.security.beta.kubernetes.io/container-name: "k8s-apparmor-example-deny-write"

Why it fails: Incorrect. While the key format is correct, the value is missing the 'localhost/' prefix. The correct value should be 'localhost/k8s-apparmor-example-deny-write'.

kubectl describe node <node> | grep AppArmor

Why it fails: kubectl describe node <node> | grep AppArmor does not work because `kubectl describe` only retrieves the Kubernetes Node API object, which contains kubelet-reported conditions, addresses, and allocatable resources, not the host's AppArmor LSM configuration or loaded profiles. AppArmor status is not part of the Node status payload, so the grep would return nothing even on a node with strict AppArmor profiles. To see AppArmor state, you need direct host access, such as aa-status via a node shell.

kubectl get apparmor

Why it fails: There is no Kubernetes API resource type named `apparmor`, so `kubectl get apparmor` will fail with an unrecognized resource error. AppArmor profiles are configured on each node by the administrator and attached to workloads via pod annotations like `container.apparmor.security.beta.kubernetes.io/<container>`; these annotations are not top-level API objects. The kubectl command cannot query kernel security modules at all, only Kubernetes resources.

kubectl exec <pod> -- aa-status

Why it fails: `kubectl exec <pod> -- aa-status` is wrong because it executes the command inside a container's filesystem and mount namespace, not on the node. Even if aa-status were installed in the container image, the container typically lacks access to the host's `/sys/kernel/security` directory, so it cannot enumerate the node's loaded AppArmor profiles. Exec is only useful for inspecting the container's runtime environment and its own AppArmor confinement, not the node-wide LSM state.

CAP_NET_RAW

Why it fails: CAP_NET_RAW is wrong because it governs low-level network socket operations, such as crafting and sending raw packets. Setuid privilege escalation depends on the ability to switch process user IDs, which is a credential-management operation entirely unrelated to network stack access. Removing CAP_NET_RAW would impair utilities like ping or tcpdump but would leave setuid binaries fully functional.

CAP_DAC_OVERRIDE

Why it fails: CAP_DAC_OVERRIDE is wrong because it lets a process bypass discretionary access control checks on files, directories, and other objects. Setuid behavior is not about overriding file permissions at access time; it is a kernel-triggered credential change that occurs when an executable with the setuid bit is launched. Dropping CAP_DAC_OVERRIDE would tighten file access enforcement but would not prevent the setuid mechanism from elevating privileges.

CAP_SYS_ADMIN

Why it fails: CAP_SYS_ADMIN is wrong because it is a broad administrative capability covering operations like mount, namespace manipulation, and device control, not the specific act of changing user IDs. Setuid requires only the narrow credential-switching capability, not a sweeping set of system administration powers. Even if CAP_SYS_ADMIN were removed, a setuid binary would still run and switch UIDs as long as CAP_SETUID remains available.

securityContext: dropCapabilities: ALL

Why it fails: The `securityContext` object does not expose a `dropCapabilities` field; capabilities are configured under the `capabilities` subfield with a `drop` list. This typo would either cause a validation error or be ignored, meaning no capabilities are actually dropped. The correct syntax is `securityContext.capabilities.drop: ALL`.

securityContext: capabilities: drop: ["all"]

Why it fails: The value `"all"` is treated as a literal capability name, not the special `ALL` token, and since no capability named `all` exists, it has no effect. Kubernetes compares the list entries exactly, so lowercase is invalid and the container retains its default capabilities. The correct entry is the uppercase string `ALL`.

securityContext: capabilities: remove: ALL

Why it fails: The `capabilities` object only supports `add` and `drop` keys; `remove` is not a recognized field and using it will not alter the container's capability set. Kubernetes will either reject the manifest during validation or ignore the unknown key, leaving privileges unchanged. The proper way to relinquish capabilities is to list them in `drop`.

No, because baseline requires dropping ALL first

Why it fails: The baseline profile does not require containers to drop all capabilities before adding any specific ones. It evaluates the final capability set against a forbidden list, and NET_ADMIN is not on that list. Dropping ALL first is an optional hardening practice, not a policy prerequisite, so the admission decision does not hinge on it.

Yes, because the pod drops all capabilities before adding specific ones

Why it fails: It is true that the pod drops all capabilities and then adds NET_ADMIN, but that sequence is not the reason the baseline policy allows it. The baseline policy inspects the resulting capability set, not the order of operations. Since NET_ADMIN is not among the capabilities banned by the baseline profile, the pod would be permitted even if ALL were not dropped first.

No, because dropping ALL capabilities is not allowed by baseline

Why it fails: Dropping all capabilities is fully compatible with the baseline Pod Security Standard; nothing in the policy forbids removing capabilities. In fact, dropping capabilities is a recommended defensive measure. The baseline only constrains adding certain dangerous capabilities, and NET_ADMIN is not one of them, so the pod is allowed.

The profile name is misspelled in the pod specification

Why it fails: A misspelled profile name would produce a 'file not found' error during seccomp setup, but the kubelet still resolves the (misspelled) name relative to its seccomp root, so the failure is a straightforward filename mismatch. The event in question stems from using an absolute path, which makes the kubelet bypass the intended relative resolution and look in an unexpected location. Thus, a typo alone is unlikely to be the root cause when the error occurs before the profile is even read.

The node does not have seccomp enabled in the kubelet

Why it fails: If seccomp were disabled at the kubelet or container runtime level, the kubelet would reject the pod with an error indicating the feature is unsupported, such as 'seccomp is not enabled' or 'operation not permitted', rather than a profile generation failure. The fact that the runtime attempts to generate a seccomp spec proves the feature is at least functionally available and that the failure occurs while locating or reading the specified profile. Therefore, a disabled seccomp feature is inconsistent with the event described in the question.

The seccomp profile JSON is malformed

Why it fails: A syntactically invalid seccomp profile would produce a JSON parsing or unmarshalling error from the container runtime, such as 'invalid character' or 'unexpected end of file', not a 'profile not found' event. The runtime must first locate and open the file before validating its semantic content, so a malformed JSON implies the file exists and is readable, which contradicts the observed error during path resolution. Because the pod event points to a missing profile or incorrect location, a malformed file is not the cause.

hostIPC: false

Why it fails: The hostIPC field specifies whether a container can access the host's IPC namespace, which manages inter-process communication resources such as shared memory and message queues. Setting it to false (the default) prevents a pod from sharing these host-level IPC objects, but it has absolutely no bearing on network namespaces, network interfaces, or pod-to-host network isolation. Since the question asks about preventing host network access, this setting is irrelevant and thus not the correct answer.

hostNetwork: true

Why it fails: Setting hostNetwork to true deliberately attaches the pod to the node's network namespace, giving the pod the host's IP address, routing table, and network interfaces. This is the exact opposite of the requested behavior: instead of preventing access to the host network, it grants unfettered access to host-level network resources and bypasses the usual per-pod network isolation. Therefore, it cannot be the correct answer for preventing host network use.

hostPID: false

Why it fails: hostPID controls whether the container shares the host's PID namespace, which determines whether the container's processes can see or signal processes running on the node. Setting hostPID to false (default) keeps the container's process list isolated from the host, but this has no relationship to network configuration, IP addresses, or network namespaces. Hence, it is an incorrect option for the security context setting that blocks host network access.

The container is missing a memory limit and gets OOMKilled

Why it fails: A missing memory limit does not cause the container to be OOMKilled; OOMKill occurs when a cgroup memory limit is exceeded. Without a limit, the kernel may evict processes at the node level, but the container would not report an OOMKilled status specifically. Even if memory pressure caused repeated restarts, the root cause would be memory exhaustion, not a missing limit — and nginx failing to bind a port is unrelated to memory.

The namespace has a PodSecurity enforce level that restricts hostPID and hostNetwork

Why it fails: If the namespace had a PodSecurity enforce level that restricts hostPID or hostNetwork, the pod creation would be rejected at admission time by the PodSecurity admission controller. The API server would return a ValidationError before the kubelet ever runs the container, so the pod would never enter CrashLoopBackOff. Since the pod exists and is restarting, the admission layer must have allowed the security settings, meaning the crash stems from a runtime failure rather than a policy rejection.

The 'hostPID' and 'hostNetwork' fields cannot be combined

Why it fails: hostPID and hostNetwork control separate Linux namespaces: the PID namespace and the network namespace. These are independent and can be set simultaneously without conflict; a container can share both the node's process table and its network stack simultaneously. There is no inherent incompatibility in combining these fields, so this cannot be the cause of nginx failing to start.

Adding annotation 'container.apparmor.security.beta.kubernetes.io/<container>'

Why it fails: This is for AppArmor, not seccomp.

Including 'seccomp' profile in PodSecurityPolicy

Why it fails: PodSecurityPolicy is deprecated and removed in v1.25.

Including 'seccompProfile' under 'spec.securityContext' at the pod level

Why it fails: seccompProfile is a container-level field, not pod-level.

/etc/seccomp/

Why it fails: Incorrect. /etc/seccomp/ is not the default kubelet seccomp profile directory.

/etc/kubernetes/seccomp/

Why it fails: Incorrect. /etc/kubernetes/seccomp/ is not the default path.

/var/lib/kubelet/seccomp/profiles/

Why it fails: Incorrect. /var/lib/kubelet/seccomp/profiles/ has an extra 'profiles' subdirectory; the correct path is /var/lib/kubelet/seccomp/.

Apply a PodSecurity admission label with 'pod-security.kubernetes.io/enforce: privileged'

Why it fails: The privileged policy is the most permissive Pod Security Standard; it imposes no capability restrictions whatsoever, so a container can retain NET_RAW and even run with full host access if requested. Applying pod-security.kubernetes.io/enforce: privileged would explicitly allow the very raw socket capability the administrator wants to eliminate, meaning the cluster would remain vulnerable to packet spoofing and raw traffic inspection. Because the goal is to drop NET_RAW cluster-wide, this label does the opposite of enforcing that control.

Apply a PodSecurity admission label with 'pod-security.kubernetes.io/enforce: restricted'

Why it fails: While the restricted policy does drop NET_RAW as part of its baseline-inherited capability restrictions, it goes far further by requiring pods to meet hardened constraints such as running as a non-root user, avoiding privileged escalation, and setting restrictive seccomp profiles. If the administrator only wants to remove NET_RAW without forcing workload changes like seccomp annotations or a default non-root UID, restricted is overkill and may cause many existing workloads to be rejected on admission. The desire to minimize disruption while still blocking raw sockets points away from restricted toward a more targeted policy.

Use a PodSecurityPolicy with 'requiredDropCapabilities: [NET_RAW]'

Why it fails: PodSecurityPolicy is effectively dead as an enforcement mechanism in modern Kubernetes: it was deprecated in 1.21 and removed in 1.25, so using requiredDropCapabilities: [NET_RAW] would simply be ignored or fail to apply on any currently supported cluster. Even where PSP was available, it required enabling an admission plugin and writing PSP objects per cluster, whereas Pod Security Admission is built into the kube-apiserver. A cluster administrator should not rely on PSP for new controls; instead, Pod Security Standards labels are the supported path.