CKS Practice Questions

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

The first command fetches the name of the default service-account secret in the testing namespace, selects its base-64-encoded token field, decodes it, and saves it to token.txt. The create secret command places the required key/value pairs into a namespaced secret called test-db-secret. The Pod manifest mounts that secret as a volume, ensuring the nginx container can read the credentials from /etc/mysql-credentials as individual files (username, password) with default permissions. All steps follow Kubernetes’ documented methods for reading existing secrets, creating new secrets from literals, and consuming them as volumes inside Pods.

(No alternative options were supplied in the prompt.)

1. Kubernetes Documentation

“Accessing API from a Pod

” Example: extracting SA token

v1.28

Section: Accessing the cluster

step 2.

https://kubernetes.io/docs/tasks/configure-pod-container/access-cluster/#accessing-the-api-from-a-pod

2. Kubernetes Documentation

“Secrets

” v1.28

Section: Creating a Secret Using kubectl command line.

https://kubernetes.io/docs/concepts/configuration/secret/#creating-a-secret

3. Kubernetes Documentation

“Using Secrets as files from a Pod

” v1.28

Section: Consuming Secrets.

https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod

The series of configuration changes listed in the prompt are standard security hardening practices for a Kubernetes cluster. Each specified argument and its recommended value directly corresponds to security controls designed to mitigate specific risks. These controls are outlined in authoritative security guides, such as the CIS (Center for Internet Security) Kubernetes Benchmark.

API Server: Enabling RotateKubeletServerCertificate, setting a --kubelet-certificate-authority, and using appropriate admission controllers like PodSecurityPolicy (or its modern successor, Pod Security Admission) are critical for securing communication and enforcing workload policies.

Kubelet: Disabling anonymous authentication (--anonymous-auth=false) and delegating authorization decisions to the API server (--authorization-mode=Webhook) are fundamental steps to ensure that only authenticated and authorized entities can interact with the Kubelet API.

ETCD: Disabling automatic TLS (--auto-tls=false and --peer-auto-tls=false) prevents the use of insecure, automatically generated self-signed certificates, enforcing the use of a properly configured and trusted Public Key Infrastructure (PKI) for securing etcd communication.

The answer "False" would be incorrect. Neglecting these configurations would directly contradict widely accepted security best practices. It would leave the cluster vulnerable to multiple attack vectors, including unauthorized access to the Kubelet API, insecure communication between cluster components, and the deployment of privileged or insecure pods. The tool kube-bench, mentioned as a hint, is specifically designed to audit a cluster against these and other benchmark recommendations.

1. Center for Internet Security (CIS) Kubernetes Benchmark v1.8.0. This document provides prescriptive guidance for establishing a secure configuration posture for Kubernetes.

Section 1.2.10: "Ensure that the --rotate-kubelet-server-certificate argument is set to true." (p. 51)

Section 1.2.5: Recommends including PodSecurityPolicy in the --enable-admission-plugins list. (p. 41). Note: PodSecurityPolicy is deprecated in Kubernetes v1.21 and removed in v1.25

replaced by Pod Security Admission. However

its inclusion represents a valid security principle.

Section 1.2.9: "Ensure that the --kubelet-certificate-authority argument is set as appropriate." (p. 49)

Section 4.2.1: "Ensure that the --anonymous-auth argument is set to false." (p. 193)

Section 4.2.2: Recommends setting --authorization-mode to Webhook or Node. (p. 195)

Section 2.3: "Ensure that the --auto-tls argument is not set to true." (p. 121)

Section 2.6: "Ensure that the --peer-auto-tls argument is not set to true." (p. 127)

2. Official Kubernetes Documentation

"Securing a Cluster". This documentation outlines the core concepts for hardening a Kubernetes cluster.

Controlling access to the Kubelet: The documentation explicitly advises: "Kubelets expose HTTPS endpoints... By default

Kubelets allow unauthenticated access to this API. Production clusters should disable anonymous authentication and use webhook authentication and authorization..." This directly supports the Kubelet-related fixes. (Source: kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/#controlling-access-to-the-kubelet)

3. Official Kubernetes Documentation

"Kube-apiserver". The command-line reference details the security implications of various flags.

--kubelet-certificate-authority: "Path to a cert file for the certificate authority." This flag is essential for the API server to verify the identity of connecting Kubelets. (Source: kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/)

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