System Hardening practice questions

Use seccomp profiles to block privilege escalation syscalls

Why wrong: A seccomp profile filters system calls at the kernel boundary, but it does not change the UID/GID that the container process runs with; a root user inside the container simply cannot invoke blacklisted syscalls, yet retains a broad set of permitted root-only operations. Blocking syscalls such as unshare or mount does not satisfy the requirement to run the control plane as a non-root user with a read-only filesystem.

Apply AppArmor profiles to all control plane pods

Why wrong: AppArmor confines a specific executable or daemon to an allowed set of files, capabilities, and network operations via an LSM profile, but it leaves the container's user context untouched. The profile is also tied to the host's loaded profiles and must be applied per pod via annotations; it cannot force the control plane process to run as non-root or make its root filesystem read-only.

Enable PodSecurityPolicy with 'MustRunAsNonRoot' for control plane namespaces

Why wrong: PodSecurityPolicy is deprecated since Kubernetes 1.21 and removed in 1.25, so it cannot be reliably used on modern versions; the replacement Pod Security Admission does not define a must-run-as-non-root and read-only-filesystem pair. Even if MustRunAsNonRoot were valid, it only validates that the container runs with a non-zero UID, and it does nothing to prevent container processes from modifying the root filesystem.

NodeRestriction

Why wrong: NodeRestriction is a kubelet authorization admission controller that constrains the kubelet's ability to modify Node and Pod objects, such as preventing it from altering its own Node's status or Pod bindings. It does not inspect or enforce any container security context, so it cannot restrict the user ID that container processes run as. Thus, it is entirely unrelated to the goal of preventing root execution.

AlwaysPullImages

Why wrong: AlwaysPullImages is an admission controller that forces every Pod creation to query the image registry and always pull the image, even if it already exists locally on the node. This prevents the reuse of stale or tampered images but has no effect on the runtime user of the container processes. An image can still be configured to run as root, so this mechanism does not satisfy the administrator's requirement.

ServiceAccount

Why wrong: The ServiceAccount admission controller manages the default service account and the automatic mounting of API credentials into Pods, ensuring Pods use the correct identity for API access. It does not evaluate or modify the Pod's securityContext or the user ID of container processes. Therefore, while it controls authentication to the Kubernetes API, it cannot prevent a container from running as root.

Set securityContext.runAsUser: 1000

Why wrong: Running as a non-root user (e.g., UID 1000) only changes the numeric user ID of the process; it does not modify the kernel's authorization model or disable setuid semantics. A malicious process can still execute a binary with the setuid bit set, such as /usr/bin/sudo or a program with the SUID root flag, which temporarily grants euid=0 and therefore privileges beyond the original user. Additionally, runAsUser does not restrict syscalls like ptrace or mount, nor does it prevent exploiting kernel vulnerabilities to elevate privileges. Thus, while runAsUser is a good hardening step, it does not directly block the privilege escalation channel described in the incident.

Set securityContext.readOnlyRootFilesystem: true

Why wrong: Setting readOnlyRootFilesystem: true prevents writes to the root filesystem, making tampering with binaries or configuration files harder, but it does not stop a process from executing privilege-escalating operations. The kernel still allows the process to invoke privileged syscalls (e.g., mount, chroot, or ptrace) because the filesystem restriction is orthogonal to capability checks. An attacker could also write a setuid binary to an emptyDir volume or writable path and execute it, and temporary filesystems like /dev/shm or /tmp remain writable unless explicitly remounted. Therefore, read-only root is a filesystem integrity control, not a privilege-escalation prevention mechanism.

Drop all capabilities with securityContext.capabilities.drop: ["ALL"]

Why wrong: Dropping all Linux capabilities with capabilities.drop: ["ALL"] removes the process's permitted and effective capability sets, but it does not disable the setuid mechanism that many binaries rely on. When a process executes a setuid-root binary, the kernel sets the effective UID to 0 and then grants the process the full root capabilities regardless of its previous capability state, because the privilege escalation is based on UID transition, not on existing capabilities. Thus, even a container with no capabilities can gain complete root privileges by running a setuid binary that is present in the image (e.g., /bin/su, mounted host binaries, or a compromised setuid utility). Capability dropping is valuable for reducing the attack surface, but it does not directly block the setuid path.

Set --allow-privileged=false in kubelet configuration

Why wrong: The `--allow-privileged` kubelet flag is deprecated and has no effect in current Kubernetes versions; it historically controlled whether containers could run in privileged mode, not whether a pod could request `hostNetwork: true`. Even when the flag was available, `hostNetwork` is a pod-level networking choice that is independent of the container's privilege level, so disabling privileged containers would still permit pods to join the host's network namespace. Thus, this kubelet configuration cannot remediate the audit finding.

Enable PodSecurityPolicy with 'hostNetwork: false'

Why wrong: PodSecurityPolicy (PSP) is deprecated as of Kubernetes v1.21 and was completely removed in v1.25, so it is unavailable in virtually any modern cluster. Even when PSP was functional, it required explicit enabling of the `PodSecurityPolicy` admission plugin and the creation of policies; a policy with `hostNetwork: false` would indeed block host networking, but the feature's removal makes this option obsolete. Relying on PSP today would fail to enforce anything on clusters running supported Kubernetes versions, so it is not a valid fix for the audit finding.

Create NetworkPolicies that deny traffic to host network

Why wrong: NetworkPolicies are evaluated only in the pod network and cannot be applied to pods that run with `hostNetwork: true`, because those pods share the host's network namespace and are invisible to the standard pod networking layer. Even if a policy could see them, a NetworkPolicy is designed to filter traffic between selected pods and external endpoints; it has no mechanism to prevent a pod from being scheduled or started with the `hostNetwork` field set. Therefore, creating NetworkPolicies that deny traffic to the host network cannot restrict or audit the use of `hostNetwork` itself.

Configure kubelet with --pod-manifest-path pointing to a whitelist

Why wrong: The --pod-manifest-path kubelet flag designates a directory from which the kubelet creates static pods; it is not a registry allowlist. Static pods bypass the API server and admission controllers, so they could still pull from untrusted registries, and regular API-managed workloads would be completely unaffected. This flag can only control which manifest files are read on a single node, not the image source of every Pod in the cluster.

Enable PodSecurity with restricted profile

Why wrong: PodSecurity with a restricted profile enforces Kubernetes Pod Security Standards, such as running as non-root, dropping capabilities, and avoiding privileged containers. Its admission evaluation only examines the Pod spec's security context fields, not the image field or the registry that hosts it. Therefore, a Pod could satisfy every restricted requirement while still using a container image fetched from an untrusted repository.

Use NetworkPolicy to block traffic to untrusted registries

Why wrong: NetworkPolicy objects control layer 3/4 traffic to and from Pods in the selected namespaces, but image pulls are performed by the kubelet and container runtime on the node using the host network, before any Pod network namespace exists. Even if network policy blocked egress to a registry, it wouldn't be an admission decision about the image source, and cached or pre-pulled images would still run. It can affect runtime connectivity but cannot guarantee image provenance.

CHOWN, DAC_OVERRIDE, FOWNER

Why wrong: These allow file permission changes but are less likely to cause escape.

KILL, SETPCAP, SYS_CHROOT

Why wrong: SYS_CHROOT can be dangerous, but KILL and SETPCAP are less critical.

NET_RAW, NET_ADMIN, NET_BIND_SERVICE

Why wrong: These are network capabilities, not typically used for container escape.

Use OPA Gatekeeper to deny pods without readOnlyRootFilesystem

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

Enable PodSecurityPolicy with readOnlyRootFilesystem: true

Why wrong: PodSecurityPolicy was removed in Kubernetes 1.25, so it's not available in 1.24 (deprecated).

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

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

Run the container with privileged: true

Why wrong: 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 wrong: 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 wrong: 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.

Set --read-only-port=10255

Why wrong: Setting --read-only-port exposes an unauthenticated read-only endpoint; this does not harden against unauthorized access and actually increases the attack surface.

Enable --authentication-token-webhook

Why wrong: Enabling --authentication-token-webhook allows the kubelet to validate bearer tokens via the API server's webhook token review. However, this alone does not harden the kubelet because anonymous requests are still accepted by default unless --anonymous-auth is set to false and client certificate authentication is configured. Therefore, it is not an effective standalone hardening measure.

Set --anonymous-auth=true

Why wrong: This would allow unauthenticated access, weakening security.

Disable peer client cert authentication

Why wrong: Disabling peer client cert authentication is wrong because etcd cluster peers must mutually verify each other's identity via client certificates to establish a secure communication channel. Without this mutual TLS authentication, an attacker can introduce a rogue etcd member, intercept inter-node traffic, or tamper with cluster state. This would compromise the integrity and availability of the entire Kubernetes control plane.

Allow anonymous access to etcd for performance

Why wrong: Allowing anonymous access to etcd for performance is dangerous because it removes all authentication mechanisms, meaning anyone who can reach the etcd endpoint can read or modify the cluster's entire state, including secrets, configuration, and certificates. This dramatically increases the risk of data exfiltration and cluster takeover. Performance gains are negligible and never justify such a critical security hole; proper authentication via client certificates is mandatory.

Define NetworkPolicy to allow only certain nodes

Why wrong: NetworkPolicy objects govern pod-to-pod network communication by filtering traffic at the CNI level based on labels, IP blocks, and ports. They operate entirely at L3/L4 and have no effect on the Kubernetes scheduler's decision of which node a pod runs on. Defining a policy to allow only certain nodes cannot influence placement because network policies are not evaluated during scheduling and do not add or remove node labels or taints.

Enable PodSecurity with baseline profile

Why wrong: PodSecurity is an admission controller that enforces the Pod Security Standards (privileged, baseline, restricted) at the namespace level, validating the pod's security context, capabilities, and volume types. It rejects pods that violate the baseline profile due to unsafe settings such as privileged containers or host namespaces, but it performs no checks on node placement. The baseline profile is about hardening pod workloads, not about constraining where those workloads are scheduled.

Use tolerations in pod spec

Why wrong: A toleration in a pod spec allows the pod to be scheduled onto nodes that have a matching taint; it does not require or force placement on any particular node. Tolerations are permission-granting rather than restricting: a pod that tolerates a taint may still run on any tainted or untainted node, and the scheduler only prohibits pods that do not tolerate a node's taint. To restrict to specific nodes you must combine taints/tolerations with other mechanisms, and taints themselves are not labels that identify a hard set of nodes for a pod.

The container runs as root (user 0)

Why wrong: runAsUser is set to 1000, not root.

The container has dangerous capabilities

Why wrong: All capabilities are dropped.

The container can escalate privileges

Why wrong: allowPrivilegeEscalation is set to false.

The pod is rejected by NodeRestriction admission

Why wrong: NodeRestriction admission controller is an alpha/beta feature that constrains the kubelet's ability to modify Node and Pod objects, primarily by enforcing that the kubelet can only update its own Node and the pods bound to it. It applies only to kubelet API requests, not to normal user authentication when creating a pod, and it has no logic to inspect image names or registries. Therefore it cannot reject a user's pod creation.

The pod is rejected by PodSecurity admission

Why wrong: PodSecurity admission (the successor to PodSecurityPolicy) evaluates the pod's security context against a policy level of privileged, baseline, or restricted, checking options like privileged containers, Linux capabilities, host namespaces, and allowed volume types. It does not parse the image reference, registry host, or digest, nor does it enforce any policy on which registries are allowed. A pod with an unusual registry would still pass PodSecurity because that is outside its scope.

The pod is created but the image is not pulled because it's untrusted

Why wrong: There is no built-in mechanism in the standard Kubernetes admission chain that checks whether an image registry is 'trusted' or 'untrusted'. The kubelet simply attempts to pull the image based on the imagePullPolicy; if the registry is reachable and the image exists, it will be pulled. Blocking untrusted registries requires explicit supply-chain security layers, such as a validating admission policy, an image policy webhook, or container runtime signature verification like Container Image Signing, none of which are indicated in the exhibit.

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 wrong: 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 wrong: 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 wrong: 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.

Disable anonymous authentication immediately, then enable NodeRestriction, and finally apply the restrictive seccomp profile

Why wrong: Disabling anonymous authentication before enabling NodeRestriction and before testing seccomp reverses the safe rollout order. Kubelets and monitoring components may initially rely on permissive authentication, so cutting it off immediately can cause node authorization failures and API outages, leaving the cluster unavailable before the NodeRestriction admission controller is in place to constrain kubelet requests. Also, applying the restrictive seccomp profile last means workloads remain unprotected for the entire window, increasing exposure while the riskiest change is still untested.

Apply the 'runtime/default' seccomp profile cluster-wide immediately, then disable anonymous auth, and finally enable NodeRestriction

Why wrong: Applying 'runtime/default' cluster-wide immediately, without a logging phase, turns seccomp enforcement into a blind rollout that can crash every workload relying on a blocked syscall. Because the profile is applied to all nodes and pods at once, the blast radius is enormous, and there is no chance to observe violations in an audit log before deciding to enforce. The correct sequence first lets you detect incompatible syscalls without blocking them, preventing widespread application failures while preserving security hardening.

Enable NodeRestriction first, then apply a restrictive seccomp profile, and last disable anonymous authentication

Why wrong: Enabling NodeRestriction first is a reasonable authorization hardening step, but the sequence still fails because a restrictive seccomp profile is forced into enforcement before any violation logging or compatibility verification. NodeRestriction only limits kubelet API permissions; it cannot prevent an incompatible seccomp policy from denying syscalls to existing workloads, which causes subtle runtime crashes. Postponing the disablement of anonymous authentication to the end also leaves a serious unauthenticated access hole open during the entire migration, so the cluster never reaches a fully hardened state until the very last step, with no opportunity to safely abort after seccomp changes.

Set --anonymous-auth=true

Why wrong: 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 wrong: Setting `--read-only-port=10255` disables the read-only kubelet port, which prevents unauthenticated read access to node metrics and stats, but it does not enforce authentication on the main kubelet API port (10250). The stem requires that kubelet reject *all* requests from unauthorised sources, not merely read-only ones. This option is tempting because disabling an unauthenticated port is a common hardening step, and it would be correct if the goal were only to block anonymous read access while leaving authenticated writes intact.

Set --authentication-token-webhook=false

Why wrong: 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 wrong: 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 wrong: 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 wrong: Incorrect. While this works, it is not cluster-wide enforcement; it requires modifying each deployment individually, which is not scalable for all containers.

The NodeRestriction admission controller blocks pods with hostNetwork

Why wrong: The NodeRestriction admission controller does not block hostNetwork because its scope is limited to preventing kubelets from changing Node objects beyond their assigned node, modifying their own node's labels/taints, or writing status to pods that don't match a status-owning filter. It inspects the attributes of the API request (user/resource/name), not the hostNetwork field inside a Pod spec. This misconception confuses a node-hardening admission controller with an admission plugin that filters pod-level security features.

The nodeSelector on the pod conflicts with NodeRestriction

Why wrong: NodeRestriction has no mechanism to interpret or reject nodeSelector because it only restricts which objects a kubelet may modify, based on the kubelet's identity and the requested resource name. A pod's nodeSelector is a scheduling constraint that the Kubernetes scheduler uses to select an eligible node, and no admission controller in the NodeRestriction path examines it. Thus a nodeSelector conflict would show up as an unschedulable pod, not as an admission denial.

The developer lacks RBAC permissions to create pods

Why wrong: RBAC authorization occurs before admission controllers and would produce a Forbidden response with a message about 'pods is forbidden', not a hostNetwork-specific denial. A developer who already reaches the admission stage has satisfied RBAC, so NodeRestriction or PSA would be the next possible blocker. The question explicitly names NodeRestriction as the context, but RBAC ineffectiveness is independent from admission controller logic and cannot explain a hostNetwork policy denial.

It sets a hard limit of 1 PID per pod, which may break workloads

Why wrong: -1 means unlimited, not 1.

It limits each container to 1000 PIDs

Why wrong: podPidsLimit applies per pod, not per container.

It enforces a default PID limit of 100 per pod

Why wrong: -1 means unlimited, not 100.

Change runAsUser to 0

Why wrong: 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 wrong: 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 wrong: 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.