CKS System Hardening Practice Test 3 — 15 Questions

Question 1

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 2

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. 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 3

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. 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 4

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. 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 5

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

Accepted Answer

Enable --authentication-token-webhook. To harden the kubelet's own HTTPS endpoint, enable --authentication-token-webhook to validate bearer tokens via the Kubernetes TokenReview API, and configure --client-ca-file with --tls-cert-file to require and validate client certificates. NodeRestriction is an admission controller that limits what the kubelet can modify in the API server; it does not protect the kubelet endpoint from unauthorized access.

Answer

Set --read-only-port=10255

Answer

Enable the NodeRestriction admission controller

Answer

Set --anonymous-auth=true

Question 6

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 7

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

Accepted Answer

Use nodeSelector in pod spec. `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 8

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

Accepted Answer

The container has a writable root filesystem. 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 9

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. 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 10

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. 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 11

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 12

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 13

Which TWO of the following are effective measures to harden the Kubernetes API server against unauthorized access?

Accepted Answer

Enable the NodeRestriction admission controller. The NodeRestriction admission controller limits the Node and Pod objects a kubelet can modify, preventing compromised nodes from accessing or modifying resources beyond their own. This is a key hardening measure because it enforces the principle of least privilege directly within the API server's admission chain, reducing the blast radius of a node compromise.

Answer

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

Answer

Enable audit logging to detect unauthorized attempts

Answer

Disable all authentication mechanisms and rely on network policies

Question 14

Which THREE of the following are recommended practices for securing container images in a Kubernetes environment?

Accepted Answer

Scan images for vulnerabilities before deployment. Scanning container images for vulnerabilities before deployment is a fundamental security practice in Kubernetes environments. Tools like Trivy, Clair, or Anchore Grype can identify known CVEs in the base image and application dependencies, allowing teams to remediate issues before the image is run. This aligns with the principle of shifting security left and is a key requirement for compliance with standards like the NIST Application Container Security Guide.

Option C is correct because using imagePullSecrets is a recommended practice to authenticate to private container registries. While imagePullSecrets do not enforce access control policies on which images can be pulled, they securely store credentials and enable pods to pull images from private registries, which is essential for using images that are not publicly accessible. This prevents unauthorized access to private images and reduces the risk of using compromised public images.

Option D is correct because using minimal base images such as distroless or scratch reduces the attack surface by eliminating unnecessary packages, libraries, and utilities. This aligns with the principle of least functionality and minimizes the number of potential vulnerabilities that could be exploited.

Answer

Store sensitive configuration data directly in the image

Answer

Run containers as root to avoid permission issues

Question 15

A cluster uses a custom mutating admission webhook that adds a sidecar container to all pods. After an upgrade, the webhook crashes and pods cannot be created. What is the best way to prevent this scenario in future?

Accepted Answer

Set the webhook's failurePolicy to Ignore. Setting the webhook's failurePolicy to Ignore ensures that if the webhook fails (e.g., crashes or times out), the API server will bypass the webhook and allow the pod creation to proceed. This prevents a single point of failure from blocking all pod creation, which is critical for cluster availability. The default failurePolicy is Fail, which would cause the entire admission request to fail if the webhook is unreachable.

Answer

Run multiple replicas of the webhook

Answer

Disable admission webhooks in the cluster

Answer

Create a validating webhook as a backup