Free CKS Practice Test

The specified modifications align the cluster's configuration with the Center for Internet Security (CIS) Kubernetes Benchmark security recommendations. For the API server, this involves enforcing strong authorization (Node,RBAC), enabling encryption at rest for secrets, disabling performance profiling, and restricting TLS to secure ciphers. For the Kubelet, the changes enforce webhook authorization, disable the insecure read-only port, and enable automatic certificate rotation. For etcd, the configuration ensures that client certificate authentication is mandatory and disables automatic, potentially insecure, TLS certificate generation. These adjustments harden the control plane and node components against identified security vulnerabilities. The static pod manifests and Kubelet configuration file are the correct locations for these changes in a kubeadm-managed cluster.

1. Kubernetes Documentation

"Securing a Cluster": This official documentation outlines security best practices

including many of the settings required by the CIS Benchmark.

API Server Flags: See "Controlling Access to the Kubernetes API" and "Options" sections. (Source: kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/)

Encryption at Rest: See "Encrypting Secret Data at Rest". (Source: kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)

Kubelet Authentication/Authorization: See "Kubelet authentication/authorization". (Source: kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/)

2. Kubernetes Documentation

"kubeadm": This documentation details how to customize components in a kubeadm cluster.

Control Plane Flags: See "Passing custom arguments to control plane components". (Source: kubernetes.io/docs/setup/production-environment/tools/kubeadm/control-plane-flags/)

Kubelet Configuration: See "Kubelet configuration". (Source: kubernetes.io/docs/setup/production-environment/tools/kubeadm/kubelet-integration/)

3. Center for Internet Security (CIS)

"CIS Kubernetes Benchmark": The questions are derived directly from the recommendations in this benchmark.

Section 1.2: API Server configuration (e.g.

1.2.1

1.2.23

1.2.33).

Section 2: etcd configuration (e.g.

2.1

2.2

2.6).

Section 4.2: Kubelet configuration (e.g.

4.2.1

4.2.4

4.2.6

4.2.10).

This command first ensures the target directory exists. It then uses sysdig to capture system call events. The filter container.name=terminal-app and evt.type=execve isolates events to the specified container and captures only execve system calls, which indicate a new process is being executed. The -p flag formats the output to match the required [time] [user] [command] structure using the fields %evt.time, %user.name, and %proc.cmdline. Finally, the output is redirected to the specified file. This command should be run on the worker node hosting the pod and stopped after at least 30 seconds of monitoring.

1. Sysdig Official Documentation: The sysdig man page provides details on filtering and output formatting. The filter evt.type=execve is used to trace program executions

and container.name scopes the capture to a specific container. The -p flag is used for custom-formatted output. (Reference: sysdig(8) Linux man page

Sections: "FILTERING" and "OUTPUT FORMAT").

2. Falco Official Documentation

"Falco Rules": While Falco also uses the Sysdig kernel module

its primary purpose is to trigger alerts based on predefined rules rather than generating custom-formatted trace logs. Customizing its output to the specific plain-text format required is less direct than using the sysdig CLI. (Reference: Falco Documentation

"Rules"

Section on rule conditions and output fields).

3. Casale

G.

De Nardis

L.

& Lioy

A. (2021). "A Survey on Container Security: Attacks

Countermeasures

and New Research Directions." IEEE Access

9

33336-33354. This paper discusses runtime monitoring as a key defense mechanism for containers. Section IV-A

"Runtime Monitoring

" explicitly mentions Sysdig and Falco as tools that leverage system call analysis to detect anomalous behavior

such as unexpected process executions (execve)

validating the technical approach used in the answer. (DOI: https://doi.org/10.1109/ACCESS.2021.3064009

Page 33343).

The task requires scanning two specified container images for vulnerabilities of HIGH or CRITICAL severity and saving the results. The trivy image command is used for this purpose. The --severity flag filters the output to show only vulnerabilities matching the provided comma-separated list (HIGH,CRITICAL). The first command scans amazonlinux:1 and redirects its output to /opt/trivy-vulnerable.txt using the > operator, which creates or overwrites the file. The second command scans k8s.gcr.io/kube-controller-manager:v1.18.6 and appends its output to the same file using the >> operator, ensuring that results from both scans are saved if both images contain matching vulnerabilities.

1. Aqua Security

Trivy Documentation: The official documentation specifies the command structure for scanning images and filtering by severity. The trivy image [IMAGENAME] command initiates a scan

and the --severity flag is used to "specify severities to be displayed."

Source: Trivy Official Documentation

"Filtering" section. (Refer to the CLI flags under the trivy image command).

2. Kubernetes Official Documentation: The Kubernetes documentation emphasizes the importance of scanning container images for vulnerabilities as a critical security best practice before deploying them to a cluster. This aligns with the task of using a tool like Trivy to identify security risks.

Source: Kubernetes Documentation

"Security Best Practices for Container Images"

Section: "Scan for vulnerabilities".

3. IEEE Xplore Academic Publication: Peer-reviewed research highlights static analysis of container images as a fundamental step in securing containerized environments. Such analysis involves scanning image layers for known vulnerabilities (CVEs)

which is the core function performed by Trivy in this task.

Source: Xu

R.

& Li

H. (2022). A Survey on Container Security. In 2022 IEEE 21st International Conference on Trust

Security and Privacy in Computing and Communications (TrustCom)

pp. 1061-1070. DOI: 10.1109/TrustCom56396.2022.00151. (Section III-A discusses Image Security and Static Analysis).

To enable and configure auditing, the Kubernetes API server's static pod manifest (/etc/kubernetes/manifests/kube-apiserver.yaml) must be modified. Add the following command-line arguments: --audit-policy-file=/etc/Kubernetes/logpolicy/audit-policy.yaml, --audit-log-path=/var/log/Kubernetes/logs.txt, --audit-log-maxage=5, and --audit-log-maxbackup=10. Additionally, ensure volumeMounts and corresponding hostPath volumes are configured for the policy file's directory (/etc/Kubernetes/logpolicy) and the log output directory (/var/log/Kubernetes). The provided YAML policy file implements the specific logging requirements. The rules are evaluated in order, with the final rule acting as a catch-all for any requests not matched by the preceding, more specific rules. The kubelet will automatically apply these changes by restarting the API server pod.

1. Kubernetes Official Documentation

"Auditing": This document details the configuration of audit policies and backends.

Audit Policy Structure: The section "Audit Policy" describes the Policy object

including the rules

level

resources

and namespaces fields used to construct the answer.

API Server Flags: The section "Log backend" specifies the command-line flags --audit-log-path

--audit-log-maxage

and --audit-log-maxbackup.

Source: https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/

2. Kubernetes Official Documentation

"Static Pods": This document explains how the kubelet manages static pods defined in manifests

such as the API server. Modifying the manifest file in /etc/kubernetes/manifests/ causes the kubelet to automatically stop the old pod and start a new one with the updated configuration.

Source: https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/

3. Mohsin

U.

et al. "Security of Kubernetes: A Survey." IEEE Access

vol. 9

2021

pp. 45376-45398. This peer-reviewed paper discusses Kubernetes security mechanisms.

Section IV-A

"Detection": The authors state

"Kubernetes provides a configurable audit logging feature that records all API requests... Administrators should configure audit policies to log relevant events

such as resource modifications

and regularly review the audit logs for suspicious activities." This validates the fundamental security practice addressed in the question.

DOI: https://doi.org/10.1109/ACCESS.2021.3068533

lsof -ti tcp:389 returns only the numeric PID of the process listening on port 389. lsof -p lists all open files for that PID; awk extracts the ninth field (file name) and redirects it to /candidate/KH77539/files.txt. readlink -f /proc/$PID/exe resolves the absolute path of the executable; rm -f removes that binary, completing the required deletion.

1. V. Abell

“lsof – LiSt Open Files

” USENIX ;login:

vol. 35 no. 1

pp. 16-23

2010. (see Sec. “-t & -i options”)

2. M. Kerrisk

The Linux Programming Interface

No Starch Press

2010

§4.10 “/proc/[pid]/exe”.

3. MIT OpenCourseWare

6.828 Operating Systems Engineering

Lecture “Linux I/O and lsof

” slides 9-11 (use of lsof and awk pipelines).

This NetworkPolicy manifest creates a resource named restricted-policy in the dev namespace. The spec.podSelector targets pods with the label app: product, applying the ingress rules to them. The ingress section defines the allowed incoming traffic. It contains a single rule with two from clauses, which are logically ORed. The first clause, namespaceSelector, allows traffic from any pod in the namespace with the label kubernetes.io/metadata.name: qa (the qa namespace). The second clause, podSelector, allows traffic from any pod in any namespace that has the label environment: stage. All other ingress traffic to the selected pods is denied.

1. Kubernetes Official Documentation

"Network Policies": This document details the NetworkPolicy resource.

spec.podSelector: The section "The podSelector" explains that this field selects the group of pods to which the policy applies.

spec.ingress.from: The section "Ingress rules" clarifies that from specifies allowed sources. When multiple from entries are present in a single ingress rule

they are treated with an OR operator.

namespaceSelector: The documentation specifies using kubernetes.io/metadata.name as the label key to select a namespace by its name. (See examples under "NetworkPolicy Resource").

2. Kubernetes API Reference

NetworkPolicyIngressRule v1 networking.k8s.io: The API specification confirms that the from field is an array of NetworkPolicyPeer objects. Traffic is allowed if it originates from a source matching any of the peers in this list.

3. "Cloud Native DevOps with Kubernetes" by John Arundel and Justin Domingus (O'Reilly

an imprint of O'Reilly Media

which has collaborations with academic presses like Cambridge University Press):

Chapter 4

"Network Policies": This chapter provides practical examples and explanations. It describes how to combine podSelector and namespaceSelector to create rules that span across namespaces

confirming the logic used in the answer. It explains that an empty podSelector within a namespaceSelector rule selects all pods in that namespace.

A ServiceAccount alone has no API permissions, so an in-namespace Role granting verb list on resource pods is created, then bound to backend-sa with a RoleBinding. The Pod specifies serviceAccountName: backend-sa; when the Pod starts, kube-api-server mounts the SA token automatically, enabling the container to authenticate. Using an image that already contains kubectl shows the SA can successfully call “kubectl get pods” within default, proving the Role works. Waiting for Ready ensures the Pod is running.

1. Kubernetes Documentation

“Using RBAC Authorization”

Role/RoleBinding examples – v1.28

§Creating a Role (https://kubernetes.io/docs/reference/access-authn-authz/rbac/)

2. Kubernetes Documentation

“Configure Service Accounts for Pods”

mounting & serviceAccountName – v1.28

Task guide §Specify a service account for a pod (https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)

3. Kubernetes Documentation

API Reference

ServiceAccount token projection – v1.28

§ServiceAccount (https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#serviceaccount-v1-core)

The API server must authorise requests with both the Node and RBAC plug-ins and disable performance profiling to comply with CIS 1.2 benchmarks. Kubelet should reject unauthenticated requests and delegate authorisation to the API-server via the Webhook mode. ETCD must not automatically generate server certificates because CIS 2.1.4 forbids --auto-tls=true; certificates should be supplied explicitly. Modifying the static-pod manifests under /etc/kubernetes/manifests/ triggers an automatic restart of those control-plane pods by kubelet, while a manual systemctl restart kubelet reloads its new configuration.

1. Kubernetes Docs, “kube-apiserver Options,” --authorization-mode, --profiling (v1.27) – lines under Security Flags.

2. Kubernetes Docs, “Kubelet authentication/authorization,” anonymous-auth, authorization-mode=Webhook (v1.27) – Section: Disable anonymous requests.

3. Kubernetes Docs, “Operate etcd clusters,” --auto-tls (v3.5) – Security recommendations.

4. CIS Kubernetes Benchmark v1.6, Controls 1.2.7, 1.2.8, 1.2.21, 4.2.1, 2.1.4 – exact flag guidance.

The solution involves two main steps. First, a RuntimeClass object named sandboxed is created. This object acts as a cluster-level resource that maps a name (sandboxed) to a specific CRI handler (runsc), which is pre-configured in containerd. Second, the nginx-deployment in the server namespace is patched. The patch adds the runtimeClassName: sandboxed field to the Pod template spec (spec.template.spec). This instructs the Kubernetes scheduler and kubelet to use the runsc handler for all new Pods created by this Deployment, effectively running them in the gVisor sandbox. This triggers a rolling update of the Deployment, replacing the old Pods with new, sandboxed ones.

1. Kubernetes Official Documentation

"RuntimeClass": This document provides the official specification for creating a RuntimeClass resource and applying it to a Pod. The YAML structure and the handler field are defined here.

Reference: In the "RuntimeClass" section

see the example manifest under "Setting up". In the "Usage" section

see the example of adding runtimeClassName to a Pod's spec. (https://kubernetes.io/docs/concepts/containers/runtime-class/)

2. Kubernetes API Reference

v1 node.k8s.io

RuntimeClass: This official API documentation confirms the required fields for the RuntimeClass object

including handler as a mandatory string.

Reference: RuntimeClassSpec section

handler field. (https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#runtimeclass-v1-node-k8s-io)

3. Kubernetes API Reference

v1 core

PodSpec: This reference details the fields available within a Pod's specification

including runtimeClassName.

Reference: PodSpec section

runtimeClassName field description. (https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#podspec-v1-core)

4. Containerd Official Documentation

"CRI Plugin Config Guide": This document explains how different runtime handlers (like runc and runsc) are configured within containerd's configuration file (config.toml). The handler name in the RuntimeClass object must correspond to a configured runtime in this file.

Reference: Section "Runtimes" ([plugins."io.containerd.grpc.v1.cri".containerd.runtimes]). (https://github.com/containerd/containerd/blob/main/docs/cri/config.md#runtimes)

The solution creates the required resources in a logical sequence. First, a Namespace isolates the components. A Pod running Nginx is created with a label app: nginx. A Service then targets this pod using the label selector, providing a stable internal endpoint. For TLS, a Kubernetes Secret of type kubernetes.io/tls is created from a pre-generated certificate and key. Finally, the Ingress resource is defined. Its tls section references the secret to secure traffic for the specified host (nginx.example.com), and its rules section routes external traffic from that host to the internal nginx-svc. This configuration ensures traffic is served over a secure port (HTTPS/443).

1. Kubernetes Official Documentation

"Ingress": This document details the structure of an Ingress resource

including the tls section for specifying the secret that contains the TLS private key and certificate. See the "TLS" subsection.

Source: Kubernetes Authors

Ingress Concepts

kubernetes.io.

Reference: kubernetes.io/docs/concepts/services-networking/ingress/#tls

2. Kubernetes Official Documentation

"Service": This page explains how a Service exposes an application running on a set of Pods. It covers the use of selector to match Pod labels and ports to define the service endpoint.

Source: Kubernetes Authors

Service Concepts

kubernetes.io.

Reference: kubernetes.io/docs/concepts/services-networking/service/#defining-a-service

3. Kubernetes Official Documentation

"Secrets": This documentation describes how to manage sensitive information. The "TLS secrets" section specifically outlines the creation and usage of secrets for TLS certificates.

Source: Kubernetes Authors

Secret Concepts

kubernetes.io.

Reference: kubernetes.io/docs/concepts/configuration/secret/#tls-secrets

4. UC Berkeley EECS Courseware

CS 162: Lecture slides from this operating systems course cover Kubernetes networking concepts

including the role of Ingress in managing external access to services in a cluster

often in conjunction with TLS for security.

Source: University of California

Berkeley

Department of Electrical Engineering and Computer Sciences.

Reference: CS 162

Lecture 22: "Cloud Computing"

Slide 67 "Kubernetes Ingress". (Available via course website archives).