Certified Kubernetes Security Specialist CKS (CKS) — Questions 226–300

The encryption is transparent to clients; you can verify by reading the raw data from etcd or enabling audit logging. Option A is correct: direct etcd access shows encrypted data.

A is correct because disabling anonymous authentication (via the `--anonymous-auth=false` flag on the API server) removes the ability for unauthenticated requests to reach the API server. This forces all requests to present valid credentials, thereby restricting access to only authenticated users.

The ImagePolicyWebhook can reject images based on external policy. If the image is not signed or the signature cannot be verified, the webhook may deny the request.

crictl and ctr are CLI tools for interacting with the CRI-compatible container runtime (e.g., containerd). kubectl goes through the API server. docker is not typically used in Kubernetes nodes (unless using Docker as runtime).

Option B is correct because the CIS Benchmark for Kubernetes recommends enabling audit logging to record all API server requests, which is essential for security monitoring, incident response, and compliance. Audit logs capture the sequence of actions performed by users, administrators, and system components, providing an immutable record that can be analyzed for suspicious activity or policy violations.

The correct way is to create a YAML file for a ValidatingWebhookConfiguration resource and apply it with kubectl apply. There is no kubectl create command for webhook configurations directly; you must use a manifest.

Option C is correct because the audit policy file path is specified in the kube-apiserver manifest (usually a static pod YAML in /etc/kubernetes/manifests/). Running `kubectl get pod kube-apiserver-<node> -n kube-system -o yaml` and grepping for `audit-policy-file` reveals the exact path to the policy file currently in use, which is the authoritative way to confirm which audit policy the API server is loading.

Using 'kubectl exec' with '--' to run commands inside the container is invasive and may alter state. Using 'kubectl cp' to copy the container's filesystem out allows offline analysis without changing the running container. Option C is the most forensically sound approach.

Checkov includes checks for verifying image signatures as part of supply chain security.

Option D is correct because in Kubernetes v1.28, the `--experimental-encryption-provider-config` flag has been graduated to stable and renamed to `--encryption-provider-config`. Adding this flag to the kube-apiserver manifest (static pod YAML) causes the kubelet to automatically restart the static pod when the manifest file changes, minimizing downtime. This ensures both existing and new secrets are encrypted using the configured provider (e.g., AES-CBC or secretbox) as the apiserver rewrites existing secrets on startup.

kube-bench audits CIS benchmarks. After installation, run it, analyze results, remediate, and re-audit.

Option B is correct because the `--anonymous-auth=false` flag explicitly disables anonymous authentication on the kube-apiserver. By default, anonymous requests are allowed (with a system:anonymous user), so setting this flag to false prevents unauthenticated users from accessing the API server. This is a key hardening measure to ensure only authenticated clients can interact with the cluster.

The error message 'exec: "/app": stat /app: no such file or directory' indicates that the container runtime (e.g., containerd) cannot find the executable specified in the container's ENTRYPOINT or CMD. This occurs when the container image does not include the /app binary or script at that path, causing the container to fail immediately on start and enter CrashLoopBackOff. Option D correctly identifies that the container image is missing the /app executable.

Recovery involves identifying expired certs, renewing, restarting components, verifying, and updating configs.

Option B is correct because it first drops all capabilities with `drop: ["ALL"]` and then adds back only the specific capability needed (`NET_BIND_SERVICE`), which satisfies the security policy of least privilege. The order of `drop` and `add` in the YAML does not matter; Kubernetes processes both directives to produce the final capability set.

Using a minimal base image reduces the attack surface. The other options are not best practices.

Option D is correct because setting --anonymous-auth=false disables unauthenticated requests, ensuring all API calls require authentication, and --authorization-mode=RBAC enforces Role-Based Access Control for authorization. This combination aligns with the security team's requirement for authenticated and RBAC-authorized API requests, as RBAC is the standard Kubernetes authorization mode for fine-grained access control.

Option B is correct because the seccomp.security.alpha.kubernetes.io/pod annotation was the original method to apply a seccomp profile to an entire pod in Kubernetes versions prior to v1.19. This annotation specifies the seccomp profile path or type (e.g., 'runtime/default' or 'localhost/<profile>') for the pod's containers, and it remains valid in older clusters or when using legacy configurations.

Mounting secrets as volumes and using external secret managers like HashiCorp Vault are recommended practices.

Isolating the pod via NetworkPolicy, preserving evidence by not deleting the pod, and collecting forensic data using kubectl exec are recommended. Deleting the pod immediately and restarting it are not recommended as they destroy evidence.

Using signed images and scanning for vulnerabilities are key supply chain security practices. Options A and C are correct.

The baseline standard restricts: (A) privilege escalation (allowPrivilegeEscalation must be false), (B) running as root (must set runAsNonRoot: true), and (C) adds some capability restrictions. (D) is not a baseline restriction; hostNetwork is allowed in baseline. (E) is not a restriction; seccomp is not required in baseline.

Kubesec is a static analysis tool for Kubernetes resources. Checkov and others serve similar but broader purposes, but Kubesec is specifically named.

Using a non-root user limits the privileges within the container, reducing the impact of a compromise.

Option C is correct because granting the cluster-admin ClusterRole to a service account provides unrestricted superuser access across the entire cluster, violating the principle of least privilege. The CKS exam emphasizes that service accounts should be bound only to the minimal RBAC permissions required for their function, and cluster-admin should never be used for routine workloads.

C is correct because `nodeSelector` is the simplest and most direct field in a Pod spec for constraining which nodes the Pod can be scheduled on based on node labels. By setting `nodeSelector` with `disktype: ssd`, the scheduler will only place the Pod on nodes that have that exact label key-value pair, making it the ideal choice for this straightforward label-based scheduling requirement.

Option A correctly isolates the pod by applying a NetworkPolicy that denies all ingress and egress, and then uses 'kubectl exec' to collect forensic data. Options B, C, and D either do not preserve evidence or fail to isolate the pod.

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.

The Rego rule should deny when the violation condition holds: the pod spec contains a container without readOnlyRootFilesystem set to true. Option C uses 'not input.review.object.spec.containers[_].securityContext.readOnlyRootFilesystem' to detect missing true.

Option A is correct because AppArmor profiles operate in two modes: 'enforce' (where violations are blocked and logged) and 'complain' (where violations are only logged without blocking). This is a fundamental characteristic of AppArmor, and Kubernetes supports both modes when referencing profiles via annotations.

The CIS Benchmark for Kubernetes recommends enabling the NodeRestriction and ServiceAccount admission plugins on the kube-apiserver. NodeRestriction limits the Node identity's ability to modify Node and Pod objects, enforcing the principle of least privilege for kubelets. ServiceAccount ensures that every Pod is assigned a default ServiceAccount and that the token is automatically mounted, which is essential for secure pod-to-API-server communication.

A Gatekeeper constraint template that validates image registries against an allowed list is appropriate. The other options either allow any registry or use incorrect logic.

The cosign sign command signs a container image and generates a signature. The other options are incorrect commands or actions.

The recommended way to provide TLS certificates to the API server is by using the `--tls-cert-file` and `--tls-private-key-file` flags. These flags explicitly point the kube-apiserver to the certificate and key files, ensuring the server presents a valid TLS certificate for encrypted HTTPS communication. This is the standard, documented method for configuring TLS on the API server, as it allows the server to authenticate itself to clients.

When the API server lacks a properly configured client certificate and key for kubelet communication, it falls back to anonymous authentication when making requests to kubelets. This means the kubelet cannot verify the API server's identity, allowing any unauthenticated request to be processed, which violates the principle of mutual TLS (mTLS) and weakens cluster security.

Option C is correct because a mutating admission webhook intercepts Pod creation requests and can automatically modify the pod spec to drop CAP_SYS_ADMIN before the pod is persisted. This approach works cluster-wide, is not deprecated like PodSecurityPolicy, and does not require modifying node-level components or relying on namespace-level enforcement that only warns or rejects but does not automatically drop capabilities.

The kube-bench check for 'Ensure that the --audit-log-path argument is set' specifically targets the kube-apiserver component, as it is the primary component that handles API requests and should log them for audit purposes. The correct remediation is to add '--audit-log-path=/var/log/audit.log' to the kube-apiserver's startup arguments, which enables writing audit logs to a specified file path. This ensures that all API server requests are recorded for security monitoring and compliance.

The condition should check for outbound connections (evt.type=connect) from a container (container.id != host) to external IPs (not RFC 1918 private IPs or loopback). Option A matches this.

Option B is correct because `ClusterRoleBindings` are cluster-scoped resources that grant permissions across all namespaces, including the `development` namespace. By piping the YAML output through `grep -B 10 namespace: development`, you can identify which `ClusterRoleBinding` references a service account in the `development` namespace, revealing any binding that could grant cluster-admin privileges to that namespace's service accounts.

Option C is correct because kube-bench expects etcd to use certificates signed by a trusted CA (typically the Kubernetes CA) for secure communication. Self-signed certificates are not trusted by default and can lead to man-in-the-middle attacks or connection failures. Replacing the self-signed certificate with one signed by the Kubernetes CA ensures that the certificate chain is validated, aligning with the CIS Benchmark requirement for etcd.

Option A is correct because configuring the log collector to use TLS (e.g., Fluentd with TLS output plugin or Filebeat with SSL/TLS) encrypts log data in transit, preventing eavesdropping or tampering during shipping to a central system like Elasticsearch or Splunk. This directly protects confidentiality and integrity against man-in-the-middle attacks on the network path.

Both hostNetwork and hostPID expose the container to host-level resources, but hostPID allows the container to see all host processes and potentially interfere with them, which is a direct risk to other workloads and the host itself.

Option C is correct because the CIS Kubernetes Benchmark explicitly recommends disabling anonymous authentication on the API server to prevent unauthenticated access. Anonymous requests bypass all authentication checks and can lead to unauthorized cluster operations if RBAC is not properly scoped. Setting the `--anonymous-auth=false` flag on the API server ensures that only authenticated users can interact with the cluster.

crictl logs <container-id> fetches logs from a container.

`trivy fs` is the command to scan a filesystem for vulnerabilities, including configuration files and source code.

Falco uses syscall events. Container spawning a shell is detected by looking for spawned processes with a shell binary, excluding the container's own entrypoint. The condition 'spawned_process and container and proc.name in (bash, sh, zsh)' is correct.

The `Request` level logs metadata (like user, timestamp) and the request body. `Metadata` logs only metadata. `RequestResponse` logs metadata, request body, and response body. `None` logs nothing.

Option D is correct because the cluster-admin ClusterRole grants superuser access across all namespaces, which violates the principle of least privilege. The best practice is to review the specific permissions required by the service account, create a custom Role with only those necessary permissions, and bind it via a RoleBinding or ClusterRoleBinding scoped appropriately. This minimizes the attack surface and aligns with Kubernetes RBAC hardening guidelines.

Metadata level logs request metadata (user, timestamp, verb, resource) but not the request or response body. It is suitable for logging all requests without exposing sensitive data.

Option C is correct because configuring containerd to use Harbor as a mirror for all registries and setting the endpoint to Harbor only effectively blocks pulls from any external registry at the container runtime level. This approach works even if Kubernetes manifests reference Docker Hub images, as the kubelet will redirect all image pull requests to the internal Harbor registry, preventing direct pulls from public registries. It enforces the policy without requiring immediate changes to existing manifests, which aligns with the constraint of not modifying them due to a large backlog.

Option B is correct because minimal base images like distroless reduce the attack surface by eliminating unnecessary packages, libraries, and shell access. This aligns with the principle of least functionality, making it harder for attackers to exploit vulnerabilities or execute arbitrary commands within the container. Distroless images typically contain only the application and its runtime dependencies, significantly lowering the risk of privilege escalation or lateral movement.

Syft generates SBOMs from container images. Option A is correct.

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.

The `--audit-log-path` flag is the correct kube-apiserver flag to enable audit logging because it specifies the file path where audit logs are written. When this flag is set, the API server starts recording audit events to the designated file, effectively enabling the audit logging feature. Without this flag, audit logging is disabled by default, even if other audit-related flags like `--audit-policy-file` are provided.

The audit policy is defined in a YAML file and passed to the kube-apiserver via the `--audit-policy-file` flag. There is no CRD or ConfigMap standard; it's a plain file.

The `--enable-admission-plugins` flag is the correct parameter to activate admission controllers in the kube-apiserver. The NodeRestriction plugin limits the Node and Pod objects a kubelet can modify, enforcing the principle of least privilege. Option A correctly uses this flag with the plugin name.

Admission controllers can be chained, ImagePolicyWebhook is for image validation, and ValidatingAdmissionWebhooks can enforce custom policies. MutatingAdmissionWebhooks can modify pods but are not the only way to inject sidecars. OPA/Gatekeeper uses constraint templates for policy.

Option A is correct because etcd supports Role-Based Access Control (RBAC) that allows you to define roles and permissions to restrict read and write access to keys. By enabling etcd RBAC, you can enforce fine-grained authorization, ensuring that only authenticated and authorized clients (e.g., the Kubernetes API server) can perform specific operations on etcd data.

The ImagePolicyWebhook admission controller is an external admission controller that must be properly configured and registered. If the webhook is not reachable or returns an error, Kubernetes may allow the request to proceed depending on the failure policy. However, the most common issue is that the ImagePolicyWebhook is not enabled in the API server or the webhook configuration is incorrect.

Option C is correct because setting `securityContext.readOnlyRootFilesystem: true` in the Pod spec directly enforces that the container's root filesystem is read-only, preventing any unauthorized writes to the root filesystem. This is the simplest and most direct way to achieve the requirement at the Pod level, as it applies to all containers in the Pod unless overridden at the container level.