CKS System Hardening Practice Test 2 — 15 Questions

Question 1

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 2

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

Use a mutating admission webhook to add a finalizer that drops capabilities. A mutating admission webhook can intercept Pod creation requests and modify the security context to drop capabilities like NET_RAW for all containers. This approach enforces the policy cluster-wide without requiring manual changes to each deployment, making it a viable alternative to deprecated PodSecurityPolicy.

Answer

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

Answer

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

Answer

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

Question 3

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 4

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 5

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

Question 6

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 7

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 8

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

Question 9

A security team wants to ensure that no pod runs with privileged access. They have created a PodSecurityPolicy (PSP) that sets 'privileged: false'. However, a pod with privileged: true still gets created. What is the most likely cause?

Accepted Answer

The user creating the pod does not have a RoleBinding that grants use of the PSP. A is correct because PodSecurityPolicy (PSP) requires the user or service account creating the pod to have a RoleBinding or ClusterRoleBinding that grants the `use` verb on the PSP resource. Without this RBAC authorization, the PSP is not enforced for that user, even if the PSP exists and the admission controller is enabled. The pod with `privileged: true` bypasses the PSP because the creating identity lacks the necessary RBAC permissions to trigger the PSP's validation.

Answer

The pod has a higher priority than the PSP

Answer

The PodSecurityPolicy admission controller is not enabled

Answer

The PodSecurityPolicy is defined after the pod creation

Question 10

You are a security engineer at a company running a Kubernetes cluster in production. The cluster uses containerd as the container runtime and has been configured with Node Authorizer and NodeRestriction admission controller. Recently, a security audit revealed that several pods running as root have been compromised via container escape vulnerabilities. The audit report recommends hardening the nodes to reduce the attack surface. Specifically, you need to ensure that even if an attacker gains root access inside a container, they cannot execute privileged operations on the host node, such as loading kernel modules, modifying host network settings, or accessing host devices. The cluster runs on Ubuntu 20.04 nodes with Linux kernel 5.4. You have access to modify node-level configurations but must minimize performance impact and avoid breaking existing workloads that rely on standard Linux capabilities. Which of the following actions would most effectively mitigate these risks?

Accepted Answer

Configure containerd to use a default seccomp profile that blocks unprivileged user namespaces and restricts kernel modules loading, and apply it to all pods via a mutating admission webhook.. Seccomp (secure computing mode) can filter system calls at the kernel level, and by configuring containerd to use a default seccomp profile that blocks syscalls related to unprivileged user namespaces (e.g., `clone` with `CLONE_NEWUSER`) and kernel module loading (e.g., `init_module`, `finit_module`), you prevent container escapes from performing privileged host operations. This approach is runtime-level, applies globally without modifying pod specs, and minimizes performance impact since seccomp uses a BPF-based filter that adds negligible overhead.

Answer

Enable user namespaces for all containers by setting the 'hostUsers: false' option in the pod spec, which maps container root to a non-root user on the host.

Answer

Remove the CAP_SYS_ADMIN and CAP_NET_ADMIN capabilities from all containers by setting a default PodSecurityPolicy that drops these capabilities.

Answer

Enable AppArmor on all nodes and apply a custom profile that denies all mount and network-related system calls.

Question 11

A security auditor reviews a Kubernetes cluster and finds that several nodes have container runtimes with default configurations. Which TWO of the following actions should be taken to harden the container runtime?

Accepted Answer

Enable AppArmor profiles on the nodes. Enabling AppArmor profiles on nodes enforces mandatory access control (MAC) on container processes, restricting them to only the resources they need. This hardens the container runtime by confining containers beyond the default, often permissive, runtime configuration. AppArmor profiles are a key security mechanism for system hardening in Kubernetes.

Answer

Set readOnlyRootFilesystem in pod security contexts

Answer

Set --no-new-privileges flag in the container runtime configuration

Answer

Disable swap on all nodes

Question 12

You are a platform engineer for a financial services company. Your Kubernetes cluster runs on bare-metal nodes with Ubuntu 20.04 and uses containerd as the container runtime. The cluster is in production with 50 worker nodes. A recent security scan shows that all nodes have the 'overlayfs' kernel module loaded, which is not required. The security policy requires minimal kernel modules. You need to disable the module without disrupting running containers. What should you do?

Accepted Answer

Add 'blacklist overlayfs' to /etc/modprobe.d/ and run 'update-initramfs -u', then reboot nodes one by one after draining. It permanently disables the overlayfs kernel module by adding it to the modprobe blacklist and updating the initramfs, ensuring the module is not loaded on subsequent boots. Draining and rebooting nodes one by one avoids disrupting running containers, as pods are rescheduled to other nodes before the node is taken offline. This approach aligns with the security policy of minimizing kernel modules while maintaining production uptime.

Answer

Restart containerd on each node to unload the module

Answer

Use 'rmmod overlayfs' after stopping all containers

Answer

Use 'modprobe -r overlayfs' on each node immediately

Question 13

Order the steps to configure and use Falco for runtime security in a Kubernetes cluster.

Accepted Answer

Install Falco, then configure rules, then deploy as DaemonSet, then monitor alerts, then tune rules. Falco installation, configuration, deployment as DaemonSet, monitoring alerts, and tuning are the key steps.

Answer

Install Falco, then deploy as DaemonSet, then configure rules, then monitor alerts, then tune rules

Answer

Install Falco, then configure rules, then monitor alerts, then deploy as DaemonSet, then tune rules

Answer

Install Falco, then tune rules, then configure rules, then deploy as DaemonSet, then monitor alerts

Question 14

Match each etcd security configuration to its description.

Accepted Answer

Client certificate authentication: Requires clients to present a valid certificate signed by a trusted CA.. In this matching exercise, each etcd security configuration should be paired with its correct description. Common confusions arise between client-to-server TLS and peer-to-peer TLS due to similar wording. Client-to-server TLS secures communication between clients and the cluster, while peer-to-peer TLS secures inter-member communication. Client certificate authentication and RBAC are distinct security features.

Answer

Client-to-server TLS: Encrypts communication between etcd members.

Answer

Peer-to-peer TLS: Encrypts communication between etcd clients and the cluster.

Question 15

An administrator wants to enforce the Pod Security Standard 'restricted' for all pods in the 'secure' namespace. Which kubectl command correctly enables the PodSecurity admission controller for that namespace?

Accepted Answer

kubectl label ns secure pod-security.kubernetes.io/enforce=restricted. The Pod Security Standards are enforced on namespaces using the `pod-security.kubernetes.io/enforce` label set to the desired policy level (e.g., `restricted`). The `kubectl label` command applies this label to the namespace, which triggers the PodSecurity admission controller to enforce the restricted policy on all pods created in that namespace.

Answer

kubectl annotate ns secure pod-security.kubernetes.io/enforce=restricted

Answer

kubectl label ns secure pod-security.kubernetes.io/enforce-version=restricted

Answer

kubectl label ns secure pod-security.kubernetes.io/audit=restricted