CKS System Hardening — Timed 100 Questions

Question 1

A security team is hardening a Kubernetes cluster. They need to ensure that all control plane components run with the least privilege. Which approach should they take?

Accepted Answer

Configure control plane containers to run as non-root user and with read-only root filesystem. Option C is correct because running control plane containers as a non-root user and with a read-only root filesystem directly enforces the principle of least privilege at the container level. This approach limits the ability of an attacker who compromises a control plane component to escalate privileges or modify critical system files, which is a fundamental hardening requirement for the control plane.

Answer

Use seccomp profiles to block privilege escalation syscalls

Answer

Apply AppArmor profiles to all control plane pods

Answer

Enable PodSecurityPolicy with 'MustRunAsNonRoot' for control plane namespaces

Question 2

An administrator wants to restrict pods from running as root. Which admission controller should be enabled?

Accepted Answer

PodSecurity. The PodSecurity admission controller (D) is the correct choice because it enforces the Pod Security Standards (Privileged, Baseline, Restricted) defined in the Kubernetes documentation. By enabling this controller, the administrator can configure a policy that prevents pods from running as root, typically by setting the 'Restricted' profile which requires 'runAsNonRoot: true' and 'runAsUser: > 10000' in the pod security context.

Answer

NodeRestriction

Answer

AlwaysPullImages

Answer

ServiceAccount

Question 3

A cluster has been compromised due to a container running with privileged escalation. The team wants to prevent any container from gaining new privileges. Which configuration should be applied?

Accepted Answer

Set securityContext.allowPrivilegeEscalation: false. Setting `securityContext.allowPrivilegeEscalation: false` directly prevents a container from gaining new privileges beyond those it was initially granted, such as through setuid binaries or the `NO_NEW_PRIVS` flag. This is the exact control needed to block privilege escalation attacks, as it forces the kernel to deny any request for elevated privileges, even if the binary has the setuid bit set.

Answer

Set securityContext.runAsUser: 1000

Answer

Set securityContext.readOnlyRootFilesystem: true

Answer

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

Question 4

During a security audit, it was found that some pods have access to the host network. How can an administrator restrict host network access for all pods in the cluster?

Accepted Answer

Enable PodSecurity admission controller with baseline or restricted profile. Option B is correct because the PodSecurity admission controller (GA in Kubernetes v1.25+) enforces predefined security standards (baseline or restricted) that, among other restrictions, prevent pods from using `hostNetwork: true`. This is the recommended replacement for the deprecated PodSecurityPolicy and provides a built-in, cluster-wide mechanism to restrict host network access without requiring external tools.

Answer

Set --allow-privileged=false in kubelet configuration

Answer

Enable PodSecurityPolicy with 'hostNetwork: false'

Answer

Create NetworkPolicies that deny traffic to host network

Question 5

A DevOps team wants to ensure that all container images are pulled from a trusted registry only. Which cluster-level configuration should be applied?

Accepted Answer

Enable ImagePolicyWebhook admission controller. Option D is correct because the ImagePolicyWebhook admission controller allows you to configure a cluster-level admission plugin that intercepts all Pod creation requests and validates the container images against an external webhook backend. This backend can enforce policies such as allowing only images from a trusted registry (e.g., `mytrustedregistry.io/*`), rejecting any image that does not match the whitelist. It operates at the API server level, ensuring that no Pod with an untrusted image can be created in the cluster.

Answer

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

Answer

Enable PodSecurity with restricted profile

Answer

Use NetworkPolicy to block traffic to untrusted registries

Question 6

An attacker exploited a container escape vulnerability. The team wants to mitigate such attacks by restricting containers from accessing the host's kernel capabilities. Which set of capabilities should be dropped from all containers?

Accepted Answer

SYS_ADMIN, SYS_MODULE, SYS_PTRACE. Option A is correct because SYS_ADMIN, SYS_MODULE, and SYS_PTRACE are the most dangerous capabilities that enable container escape. SYS_ADMIN grants broad administrative privileges (e.g., mounting filesystems, accessing /proc/1/environ), SYS_MODULE allows loading kernel modules, and SYS_PTRACE permits tracing processes outside the container. Dropping these three capabilities is a key mitigation against kernel-level escapes.

Answer

CHOWN, DAC_OVERRIDE, FOWNER

Answer

KILL, SETPCAP, SYS_CHROOT

Answer

NET_RAW, NET_ADMIN, NET_BIND_SERVICE

Question 7

A cluster is running Kubernetes 1.24. The security team wants to enforce that all pods run with a read-only root filesystem. Which approach is most effective?

Accepted Answer

Enable PodSecurity admission controller with restricted profile. Option C is correct because in Kubernetes 1.24, PodSecurityPolicy (PSP) has been removed, and the PodSecurity admission controller with the restricted profile is the built-in replacement that enforces a read-only root filesystem for all pods. The restricted profile sets `securityContext.readOnlyRootFilesystem: true` by default, ensuring compliance without external tools.

Answer

Use OPA Gatekeeper to deny pods without readOnlyRootFilesystem

Answer

Enable PodSecurityPolicy with readOnlyRootFilesystem: true

Answer

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

Question 8

A developer wants to run a container that needs to modify kernel parameters. What is the secure way to achieve this?

Accepted Answer

Use allowedUnsafeSysctls in pod securityContext for safe sysctls like net.ipv4.tcp_syncookies. Option C is correct because Kubernetes provides a secure mechanism to modify kernel parameters via `allowedUnsafeSysctls` in the Pod's `securityContext`. This approach allows specific sysctls (e.g., `net.ipv4.tcp_syncookies`) to be set without granting full privileged access or dangerous capabilities. It ensures that only explicitly whitelisted sysctls are permitted, reducing the attack surface while meeting the developer's requirement.

Answer

Run the container with privileged: true

Answer

Add SYS_ADMIN capability to the container

Answer

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

Question 9

Which TWO of the following are effective methods to harden the kubelet against unauthorized access?

Accepted Answer

Enable the NodeRestriction admission controller. Option C is correct because the NodeRestriction admission controller limits the Node and Pod objects a kubelet can modify, preventing a compromised node from escalating privileges or tampering with other workloads. This is a key Kubernetes-native control to harden the kubelet's authorization scope.

Answer

Set --read-only-port=10255

Answer

Enable --authentication-token-webhook

Answer

Set --anonymous-auth=true

Question 10

Which THREE of the following are recommended practices for securing the etcd datastore?

Accepted Answer

Bind etcd to localhost only if not required to be accessible from other nodes. Binding etcd to localhost (127.0.0.1) when it does not need to be accessed from other nodes restricts network exposure, reducing the attack surface. This is a fundamental network hardening practice that prevents unauthorized remote access to the etcd datastore, which stores all cluster state and secrets.

Answer

Disable peer client cert authentication

Answer

Allow anonymous access to etcd for performance

Question 11

Which TWO of the following are valid approaches to restrict which nodes a pod can run on?

Accepted Answer

Use nodeSelector in pod spec. Option A is correct because `nodeSelector` is a simple field in the Pod spec that constrains which nodes a Pod can be scheduled on by matching against node labels. This is a native Kubernetes scheduling mechanism that directly restricts node placement based on key-value pairs defined on nodes.

Answer

Define NetworkPolicy to allow only certain nodes

Answer

Enable PodSecurity with baseline profile

Answer

Use tolerations in pod spec

Question 12

A pod manifest is shown. What security issue remains in this configuration?

Accepted Answer

The container has a writable root filesystem. Option B is correct because the pod manifest does not set `readOnlyRootFilesystem: true` in the container's security context. Without this setting, the container's root filesystem is writable by default, allowing an attacker who compromises the container to modify binaries, configuration files, or write malicious scripts to persistent storage, thereby increasing the attack surface and potentially enabling persistence or privilege escalation.

Answer

The container runs as root (user 0)

Answer

The container has dangerous capabilities

Answer

The container can escalate privileges

Question 13

Given the exhibit, what will happen when a user creates a pod with an image from an untrusted registry?

Accepted Answer

The pod is created and the image is pulled. Option C is correct because, by default, Kubernetes does not enforce any restrictions on image registries. The kubelet will attempt to pull the image from any registry, including untrusted ones, unless an admission controller like ImagePolicyWebhook or a runtime-specific policy (e.g., containerd's `untrusted_workload` mode) is explicitly configured. In this scenario, no such policy is mentioned, so the pod is created and the image is pulled.

Answer

The pod is rejected by NodeRestriction admission

Answer

The pod is rejected by PodSecurity admission

Answer

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

Question 14

You are a security engineer for a large e-commerce company. The Kubernetes cluster runs on-premises and hosts critical payment processing applications. Recently, a security scan revealed that several pods are running with privileged escalation enabled, and some have a writable root filesystem. The cluster uses Kubernetes v1.26 with PodSecurity admission controller enabled but currently set to 'privileged' profile for all namespaces. The development teams require flexibility for some legacy applications that need to run with hostNetwork or hostPID. However, the security team wants to enforce a restricted profile for most namespaces while allowing exceptions. The CISO has mandated that no pod should run as root, and all pods must have read-only root filesystem and privilege escalation disabled. Additionally, any pod that requires hostNetwork or hostPID must be explicitly approved and placed in a separate namespace. You need to design a solution that meets these requirements with minimal operational overhead. What is the best course of action?

Accepted Answer

Use PodSecurity admission with 'restricted' profile for most namespaces by labeling them with 'pod-security.kubernetes.io/enforce=restricted', and create a separate namespace with 'baseline' profile for legacy apps that require hostNetwork/hostPID, after reviewing and approving each exception. Option C is correct because PodSecurity admission (PSA) is the native Kubernetes mechanism for enforcing pod security standards with minimal operational overhead. By labeling most namespaces with 'pod-security.kubernetes.io/enforce=restricted', you enforce the CISO's mandates (non-root, read-only root filesystem, no privilege escalation) automatically. Creating a separate namespace with the 'baseline' profile allows legacy apps requiring hostNetwork/hostPID to run after explicit approval, while still blocking privileged escalation and other dangerous capabilities.

Answer

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

Answer

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

Answer

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

Question 15

You are managing a Kubernetes cluster that hosts multiple microservices. The cluster uses Kubernetes v1.25. Recently, a security audit identified that containers are running with the default seccomp profile (unconfined). The security team has requested that all containers use a seccomp profile that blocks unnecessary syscalls. You need to implement this cluster-wide without breaking existing applications. The audit also found that the kubelet's anonymous authentication is enabled, which should be disabled. Additionally, you need to ensure that the kubelet's NodeRestriction admission controller is enabled to limit what nodes can do. Which of the following is the most appropriate sequence of actions?

Accepted Answer

First, configure the kubelet to use a seccomp profile that logs violations (e.g., 'runtime/default' with log), then after verifying no breakage, switch to 'runtime/default'. Then disable anonymous authentication and enable NodeRestriction admission controller. Option D is correct because it follows the principle of least disruption: first, it applies the 'runtime/default' seccomp profile in logging mode to detect any blocked syscalls without breaking applications. After verifying no breakage, it switches to enforcing mode. Then, it disables anonymous authentication and enables the NodeRestriction admission controller, both of which are non-disruptive configuration changes. This sequence minimizes risk to existing workloads while meeting all audit requirements.

Answer

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

Answer

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

Answer

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

Question 16

A security engineer is hardening a Kubernetes node and wants to ensure that kubelet does not accept requests from unauthorized sources. Which kubelet configuration change should be made?

Accepted Answer

Set --anonymous-auth=false. Setting `--anonymous-auth=false` on the kubelet disables anonymous requests, meaning the kubelet will reject any request that does not present valid authentication credentials. This is a critical hardening measure to ensure only authenticated and authorized sources (e.g., the API server) can interact with the kubelet’s HTTPS API, preventing unauthorized nodes or attackers from querying or modifying pod/container state.

Answer

Set --anonymous-auth=true

Answer

Set --read-only-port=10255

Answer

Set --authentication-token-webhook=false

Question 17

During a security audit, it is found that containers running in a cluster have CAP_NET_RAW capability by default. The team wants to drop this capability for all containers. Which approach should be taken?

Accepted Answer

Create a PodSecurityPolicy with requiredDropCapabilities: [NET_RAW] and assign it to a role binding. Option B is correct because PodSecurityPolicy (PSP) is the native Kubernetes mechanism to enforce cluster-wide security constraints, including dropping specific capabilities like NET_RAW. By defining a PSP with `requiredDropCapabilities: [NET_RAW]` and binding it to a role via RoleBinding or ClusterRoleBinding, all containers in the cluster will automatically have that capability removed, ensuring consistent enforcement without modifying individual workloads.

Answer

Use a mutating admission webhook to add a finalizer that drops capabilities

Answer

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

Answer

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

Question 18

A cluster has enabled the NodeRestriction admission controller. A developer is trying to create a pod with hostNetwork: true but is getting an error. What is the most likely reason?

Accepted Answer

The error is unrelated to NodeRestriction; the issue is likely a missing PodSecurityPolicy or Pod Security Admission that denies hostNetwork. The NodeRestriction admission controller only limits node self-updates to kubelet nodes, preventing them from modifying their own labels, taints, or other node objects. It does not block pods with `hostNetwork: true`. The error is most likely caused by a missing PodSecurityPolicy or Pod Security Admission (PSA) that denies pods with `hostNetwork: true`, as these are the mechanisms that enforce host namespace restrictions.

Answer

The NodeRestriction admission controller blocks pods with hostNetwork

Answer

The nodeSelector on the pod conflicts with NodeRestriction

Answer

The developer lacks RBAC permissions to create pods

Question 19

Refer to the exhibit. A security engineer sees that podPidsLimit is set to -1. What security concern does this raise?

Accepted Answer

It disables PID limiting, allowing a single pod to consume all PIDs on the node, risking a fork bomb. Setting `podPidsLimit` to `-1` in Kubernetes disables PID limiting for pods, meaning a single pod can create an unlimited number of processes. This poses a security risk because a compromised or malicious pod could launch a fork bomb, exhausting all available PIDs on the node and causing a denial of service (DoS) for other workloads. The correct answer is C.

Answer

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

Answer

It limits each container to 1000 PIDs

Answer

It enforces a default PID limit of 100 per pod

Question 20

Refer to the exhibit. The pod fails to start with the error 'container has runAsNonRoot but image will run as root'. Which change would fix the issue?

Accepted Answer

Set runAsNonRoot: false. The error 'container has runAsNonRoot but image will run as root' occurs because the Pod's security context sets `runAsNonRoot: true`, but the container image is configured to run as root (UID 0). Setting `runAsNonRoot: false` removes the enforcement, allowing the container to run as root as the image expects. This directly resolves the conflict between the security context constraint and the image's default user.

Answer

Change runAsUser to 0

Answer

Use a different image that runs as non-root

Answer

Add NET_ADMIN capability