Certified Kubernetes Security Specialist CKS (CKS) — Questions 826–900

If the image tag was overwritten (e.g., pushed again without signing), the old signatures are lost and the new image is unsigned.

RequestReceived, ResponseStarted, ResponseComplete, and Panic are valid stages. RequestReceived and ResponseStarted are two of them. 'RequestSent' and 'ResponseReceived' are not standard stages.

The 'cosign sign' command signs the image and pushes the signature to the registry.

Option B is correct because the `--anonymous-auth=false` flag explicitly disables anonymous authentication on the Kubernetes API server. By default, anonymous requests are allowed (equivalent to `--anonymous-auth=true`), so setting this flag to `false` prevents unauthenticated users from accessing the API server, which is a key hardening requirement for the CKS exam.

ImagePolicyWebhook is the admission controller that can enforce policies based on image signatures. Option C is correct.

The --audit-policy-file flag specifies the path to the audit policy file, which is required to enable audit logging.

Option A is correct because `aescbc` (AES in Cipher Block Chaining mode) is the only provider listed that is officially supported by Kubernetes for encrypting secrets at rest in etcd. The EncryptionConfiguration resource allows you to specify `aescbc` as a provider, which encrypts data using a 32-byte key and is the recommended default for production clusters.

The secret volume type mounts a Kubernetes Secret as files into a container. ConfigMaps are for non-sensitive data. hostPath is for host filesystem. emptyDir is ephemeral.

Certificate management is essential for securing communication in Kubernetes.

Option C is correct because to enable RBAC authorization on the API server, you must set `--authorization-mode=RBAC`. Disabling anonymous authentication is achieved with `--anonymous-auth=false`, which prevents unauthenticated requests from being processed. Together, these flags enforce role-based access control and block anonymous access, meeting the administrator's requirements.

Running as non-root, read-only root filesystem, and dropping all capabilities are recommended for least privilege. Setting CPU requests high does not reduce vulnerabilities; it may cause resource contention. Using secrets in environment variables is insecure as they can be exposed in logs or via /proc.

Option C is correct because `kubectl describe pod <pod>` displays the pod's full configuration, including the liveness probe's exact parameters (e.g., initialDelaySeconds, periodSeconds, failureThreshold, and the probe action like HTTP GET, TCP socket, or exec command). This allows you to verify if the probe is misconfigured (e.g., too aggressive or pointing to a non-existent endpoint) and causing the CrashLoopBackOff.

The default directory for localhost seccomp profiles is /var/lib/kubelet/seccomp/. The profile file must be located there.

Option D is correct because it directly addresses the violation of least-privilege by replacing the overly permissive cluster-admin ClusterRoleBinding with a binding to a more restrictive role like 'view'. This ensures the 'monitor' service account retains only the necessary read permissions, adhering to the principle of least privilege without disrupting its functionality.

Gatekeeper's validating webhook (part of ValidatingAdmissionWebhook) enforces constraints. The admission flow: MutatingAdmissionWebhooks run first, then ValidatingAdmissionWebhooks. Since OPA/Gatekeeper uses a ValidatingAdmissionWebhook, it runs after mutating webhooks but before the final validation.

Falco runs as a DaemonSet to ensure each node has an instance that can intercept system calls from containers using kernel modules or eBPF.

The field `readOnlyRootFilesystem: true` makes the container's root filesystem read-only, which forces all writes to go to mounted volumes.

Option A is correct because the cluster-admin ClusterRole grants unrestricted access to all Kubernetes resources across all namespaces, which violates the principle of least privilege. Service accounts should be assigned only the specific permissions required for their function, not full administrative access. Using cluster-admin for service accounts increases the blast radius of a potential compromise and is a common misconfiguration that the CKS exam penalizes.

Falco can detect shell spawning by checking spawned_process and container conditions, and specific process names.

Kubesec is a tool that scans Kubernetes resource manifests and provides security scores based on security best practices.

gVisor intercepts system calls and may not support all of them, especially ones that require direct hardware access. Option C is most likely to fail.

Option C is correct because deploying Istio as a service mesh with mutual TLS (mTLS) provides transparent encryption and authentication of all inter-service traffic without modifying application code. Istio's AuthorizationPolicy resources allow fine-grained, label-based access control to enforce the principle of least privilege, meeting the security mandate with minimal operational overhead through sidecar proxy injection.

Option D is correct because setting `runAsNonRoot: true` at the pod-level SecurityContext enforces that all containers in the pod must run with a non-root user (UID > 0). If a container image specifies a user with UID 0 (root) or does not specify a user, the container will fail to start, preventing privilege escalation from root access.

The NodeRestriction admission plugin limits the kubelet's ability to modify Node and Pod objects to only those it is authorized to manage based on its credentials. It ensures a kubelet can only label, taint, or update status on its own Node object and cannot modify other Nodes, preventing privilege escalation or misconfiguration.

Scanning images for vulnerabilities and signing images are key supply chain security practices.

Using minimal base images like distroless or Alpine reduces the attack surface by including only necessary packages. Option B is correct.

The kubelet flag `--anonymous-auth=false` disables anonymous authentication, preventing unauthenticated requests from being served. By default, anonymous requests are enabled (`--anonymous-auth=true`), which allows any user without credentials to access the kubelet API. Setting this flag to `false` enforces authentication for all requests, a critical hardening step for cluster security.

allowPrivilegeEscalation controls whether a process can gain more privileges than its parent. Setting it to false is the direct way to prevent privilege escalation.

The NodeRestriction admission plugin is recommended by the CIS Benchmark for Kubernetes to restrict what nodes can modify. It limits the Node and Pod objects a kubelet can modify, ensuring that a node can only modify its own Node object and Pods bound to it. This prevents a compromised node from affecting other nodes or pods in the cluster.

crictl logs is the command to fetch logs of a container, similar to 'docker logs'.

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.

The `--encryption-provider-config` flag is the correct answer because it is the kube-apiserver flag that specifies the path to a configuration file containing the encryption providers (like `aescbc`, `secretbox`, or `aesgcm`) and the associated keys for encrypting Kubernetes secrets at rest. This flag enables the encryption at rest feature for secrets and other resources, as defined in the encryption configuration file.

Option D is correct because the Pod Security Standards (PSS) define three levels: privileged, baseline, and restricted. The privileged level is the most permissive, allowing known privilege escalations and is intended for system-level workloads that require unrestricted access to host resources. It is explicitly listed in the Kubernetes documentation as one of the three valid PSS levels.

Syft is a tool specifically designed to generate SBOMs from container images. Option A is correct.

In OPA Gatekeeper, the ConstraintTemplate defines the policy (Rego) and the schema for parameters. A Constraint instantiates the template with specific parameters. The ValidatingWebhookConfiguration is typically created by the Gatekeeper installation, not as a first step by the user.

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.

ImagePolicyWebhook allows you to configure an external webhook to validate images. OPA/Gatekeeper can also enforce registry allowlisting through constraint templates. However, ImagePolicyWebhook is the built-in admission controller specifically designed for image policy enforcement.

Falco priorities are: EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, NOTICE, INFO, DEBUG. 'HIGH' is not a valid priority.

Access to a file is detected by the 'open' syscall event. To detect reads of /etc/shadow, use 'evt.type=open' and 'fd.name' containing the path.

Option D is correct because kube-bench checks that the kubelet's `--anonymous-auth` argument is set to `false` to prevent unauthenticated requests from reaching the kubelet API. This is a CIS Kubernetes Benchmark recommendation (e.g., 4.2.1) to enforce authentication for all kubelet requests. Setting this to false ensures that anonymous users cannot perform operations on the kubelet, reducing the attack surface.

MutatingAdmissionWebhook, ImagePolicyWebhook, and PodSecurity are valid admission controllers. Options A, C, and E are correct.

The `--protect-kernel-defaults` flag is a kubelet-specific security option that ensures the kubelet does not modify kernel parameters that could weaken node security. When set to true, it enforces that the kubelet respects kernel defaults, preventing privilege escalation via sysctl overrides. This check is part of the CIS Benchmark for the kubelet component, not for etcd, the API server, or the controller manager.

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.

The correct command to scan a local image with Trivy is 'trivy image <image-name>'. The other options are incorrect flags or commands.

Valid incident response steps include isolating the pod via NetworkPolicy and capturing container logs for evidence.

In etcd, RBAC is not enabled by a dedicated RBAC flag; instead, authentication must first be turned on using `--client-cert-auth=true`. This flag requires clients to present a valid TLS certificate, which is the prerequisite for enabling RBAC. After setting this flag, you can use `etcdctl` commands like `etcdctl role add` and `etcdctl user add` to configure RBAC roles and users.

Setting runAsNonRoot: true in the security context enforces that the container runs as a non-root user; if the container attempts to run as root, it will be denied.

NodeRestriction (A) is correct because it limits the permissions of kubelet nodes to only modify their own pods and node objects, preventing a compromised node from accessing or modifying other nodes' resources. PodSecurity (B) is correct because it enforces Pod Security Standards (Privileged, Baseline, Restricted) at the namespace level, replacing the deprecated PodSecurityPolicy and ensuring pods comply with security contexts like running as non-root or dropping capabilities. Both are explicitly recommended in the CIS Benchmark for Kubernetes to reduce the attack surface.

Setting 'hostPID: true' allows the container to see all processes on the host, which greatly increases the attack surface. Option A is correct. Options B, C, and D are less risky: readOnlyRootFilesystem reduces risk, resource limits are good, and dropping capabilities reduces risk.

The evt.type=connect and fd.ip checks the destination IP; combined with a not in list condition detects unexpected outbound connections.

Taking a snapshot of the container filesystem (e.g., using crictl export) and capturing the container logs are standard forensic steps.

Option C is correct because when using a custom seccomp profile with type 'Localhost', the 'localhostProfile' field must specify a path relative to the kubelet's seccomp root directory (default: /var/lib/kubelet/seccomp). The path 'profiles/write-only.json' is relative and resolves to /var/lib/kubelet/seccomp/profiles/write-only.json, matching the file location. The 'type' field must be 'Localhost' to reference a local profile file.

In AppArmor, 'complain' mode (also known as 'learning' mode) allows all actions, including those that violate the profile, but logs the violation to the system audit log (typically via auditd or syslog). This is distinct from 'enforce' mode, which blocks violating actions. Therefore, when a pod runs with a profile in complain mode, prohibited actions are permitted and recorded.

The warning indicates that etcd is running without client certificate authentication, which means any client can communicate with etcd without verifying its identity. Setting `--client-cert-auth=true` enables TLS-based client certificate authentication, and `--trusted-ca-file` specifies the CA certificate used to validate client certificates. This is the recommended remediation because it ensures only clients with valid certificates signed by the trusted CA can access etcd, preventing unauthorized access to the cluster's key-value store.

The correct command is 'kubectl get mutatingwebhookconfigurations'.

Trivy is a comprehensive vulnerability scanner for container images, filesystems, and Git repositories. It can be integrated into CI/CD pipelines to scan images before deployment.

Option B is correct because accessing the Kubernetes Dashboard via `kubectl proxy` creates a secure, authenticated HTTP proxy between your local machine and the API server. This method leverages the API server's built-in authentication and authorization, ensuring that only users with valid kubeconfig credentials can reach the Dashboard. It also avoids exposing the Dashboard directly to the network, reducing the attack surface.

The valid stages are RequestReceived, ResponseStarted, ResponseComplete, and Panic. 'PreProcessing' and 'PostProcessing' are not valid stages.

Option A is correct because etcd supports Role-Based Access Control (RBAC) when you enable it with the `--auth-token=jwt` flag and then configure roles and users via `etcdctl`. This allows you to restrict which clients can read or write to the etcd key-value store, which is critical for securing Kubernetes cluster state. Without RBAC, any client that can reach the etcd port can access all secrets and configuration data.

Certificate rotation involves generating new certs, replacing files, restarting the service, and verifying. Kubeconfig updates may be needed if CA changes.

Mutating webhooks run before validating webhooks. If a mutating webhook runs first, it may modify the pod spec, and the validation may see the modified version.

OPA/Gatekeeper can be used to create a ConstraintTemplate that validates image registries. Kyverno is another option, but Gatekeeper is specifically designed for policy enforcement.