Certified Kubernetes Security Specialist CKS (CKS) — Questions 451–525

Kyverno policies are enforced as admission webhooks. If the policy denies the pod, the creation is rejected. The pod will not be created, and an error message is returned to the user.

The `--protect-kernel-defaults` flag ensures that the kubelet enforces kernel parameter hardening, preventing modifications that could weaken node security. Without it, a compromised or misconfigured pod could alter kernel settings (e.g., `net.ipv4.ip_forward`, `vm.overcommit_memory`), reducing the overall security posture of the node. This does not affect image pulling, pod scheduling, or kubelet startup.

The restricted Pod Security Standard (PSS) level is the correct choice because it enforces the most stringent set of security controls, including the prohibition of privileged containers. This level denies any pod that requests `privileged: true` or uses other privileged capabilities, ensuring that no container in the namespace can run with elevated host access. The baseline level is less restrictive and allows some privileged configurations, while the privileged level imposes no restrictions at all.

Option A is correct because the PodSecurity admission plugin is the successor to PodSecurityPolicy (PSP) and is designed specifically to enforce Pod Security Standards (PSS) at the namespace level. It evaluates pods against the three predefined PSS levels (privileged, baseline, restricted) based on labels set on the namespace, and can be configured in warn, audit, or enforce mode. This plugin is built into the kube-apiserver and is the recommended approach for pod security in Kubernetes v1.25 and later.

The `--anonymous-auth=false` flag explicitly disables anonymous authentication on the kubelet, preventing unauthenticated requests from being processed. By default, anonymous authentication is enabled (`--anonymous-auth=true`), which allows any unauthenticated user to make requests to the kubelet API. Setting this flag to `false` ensures that only authenticated clients can interact with the kubelet, directly addressing the requirement to block anonymous requests.

Option B is correct because deploying a sidecar container that tails the log file and writes to its own stdout is the most efficient, Kubernetes-native pattern for capturing logs from applications that write to files. The sidecar container shares the same Pod and volume, reads the log file (e.g., using `tail -F`), and outputs to stdout, which is then collected by `kubectl logs` and the cluster-level logging pipeline. This approach requires no modification to the legacy application and leverages the existing container runtime and kubelet log collection.

Option B is correct because it first drops all capabilities with `drop: ['ALL']` and then explicitly adds only `SYS_PTRACE`, ensuring the container runs with the minimum privileges required. This follows the principle of least privilege by removing any inherited or default capabilities before granting only the needed one. In Kubernetes, capabilities are Linux kernel capabilities; dropping all and adding only what is necessary is the recommended security practice.

The `--protect-kernel-defaults` kubelet flag ensures that the kubelet will not use insecure kernel defaults by enforcing that certain sysctl settings (e.g., `kernel.panic`, `vm.overcommit_memory`) are set to secure values. If these kernel parameters are not explicitly configured to safe values, the kubelet will fail to start, preventing the node from running with potentially insecure kernel defaults. This directly addresses CIS benchmark checks that require hardening of the kubelet's interaction with the host kernel.

Option B is correct because using minimal base images like distroless or scratch significantly reduces the attack surface by eliminating unnecessary packages, libraries, and utilities that could contain vulnerabilities. This aligns with the principle of least functionality, as fewer components mean fewer potential entry points for an attacker to exploit in a supply chain attack.

The RequestResponse level logs both request and response bodies. Metadata only logs metadata, Request logs request body, and None disables audit logging.

The `--audit-log-path` flag on the kube-apiserver enables audit logging and specifies the file path where audit events are written. Without this flag, audit logging is disabled by default. Setting this flag is the first step to capturing API request logs for security monitoring and compliance.

SeccompDefault is not a valid seccomp profile type in Kubernetes. The valid profile types are Unconfined, RuntimeDefault, and Localhost. SeccompDefault is a feature gate (introduced in Kubernetes 1.22) that, when enabled, tells the kubelet to use the RuntimeDefault seccomp profile by default for pods, but it is not itself a profile type.

Falco output fields include %evt.type, %proc.name, %container.id, %fd.name etc.

Option A is correct: external secret managers like Vault provide secure secret management. Option D is correct: Kubernetes Secrets mounted as volumes are more secure than environment variables. Option B is not a valid mechanism; Option C is insecure; Option E is not a native Kubernetes secret.

The CIS Kubernetes Benchmark is a set of security best practices developed by the Center for Internet Security (CIS) specifically for hardening Kubernetes clusters. It provides prescriptive guidance on configuring cluster components (e.g., kube-apiserver, kubelet, etcd) to reduce the attack surface and meet compliance standards. Option A correctly identifies this purpose, as the benchmark is not about performance, networking, or automation.

To validate the registry for container images, you use a validation rule that checks the image field.

MutatingWebhookConfiguration defines a webhook that can mutate (modify) incoming API objects, such as adding labels. Validating webhooks only validate and reject, not modify.

The kube-apiserver must be restarted to reload the encryption configuration, and the --encryption-provider-config flag must point to the configuration file.

Container sandboxing provides an additional isolation layer, supports OCI runtime, and adds a security layer. They do not use host kernel directly (that's typical containers). They do not necessarily improve performance; they often add overhead.

A PeerAuthentication resource with mTLS mode set to STRICT enforces mutual TLS for all traffic within the namespace. This is an Istio security policy.

PeerAuthentication with mTLS mode STRICT enforces that all incoming traffic to the namespace uses mutual TLS. DestinationRule is for traffic policies including TLS settings for the destination, but PeerAuthentication is the correct resource to enforce mTLS mode.

crictl exec allows running commands inside a container using the container runtime interface.

The error indicates that the user's current kubeconfig context lacks RBAC permissions to create ClusterRoleBindings. The `kubectl auth reconcile` command attempts to apply the RBAC resources defined in the YAML file, and if the user's credentials (typically from a certificate or token) do not include the `create` verb on `clusterrolebindings` in the RBAC authorization layer, the API server will reject the request with a 403 Forbidden error. This is a direct permission issue, not a connectivity or syntax problem.

Enabling TLS authentication for etcd peer and client communication ensures that all data in transit between etcd members and between etcd and the Kubernetes API server is encrypted and mutually authenticated. This prevents man-in-the-middle attacks and unauthorized access to the cluster's state store, which is a critical requirement for securing etcd as per the CIS Kubernetes Benchmark.

The `--audit-log-path` flag is the correct API server flag to specify the file path where audit logs are written. This flag defines the absolute or relative path to the audit log file, and the kube-apiserver will create or append to that file. Without this flag, no audit log file is generated, even if an audit policy is configured.

Syft and Trivy (via the 'trivy image --format cyclonedx' command) can generate SBOMs. Options A and B are correct.

Option A is correct because storing audit logs in an immutable object store like S3 with Object Lock ensures tamper-proof retention by preventing any object from being overwritten or deleted for a specified retention period. This directly satisfies the auditor's requirement for logs that cannot be altered or destroyed, regardless of the Kubernetes cluster state.

Option D is correct because RBAC (Role-Based Access Control) is the default authorization mode for new Kubernetes clusters since version 1.8. When you initialize a cluster with kubeadm, the API server is automatically configured with the `--authorization-mode=RBAC` flag, enabling fine-grained access control based on roles and bindings.

The 'restricted' Pod Security Standard with 'Enforce' mode is the correct choice because it mandates the most stringent security controls, including dropping all Linux capabilities and preventing containers from running as root. This directly mitigates container breakout attacks by eliminating the excessive privileges that enable such exploits. 'Enforce' mode actively blocks non-compliant pods, ensuring the policy is applied without relying on user awareness or audit logs.

Mounting secrets as volumes is more secure than environment variables because it reduces exposure in process listings and other system introspection.

Option D is correct because it defines a NetworkPolicy that selects pods with label 'app: db' as the target and allows ingress traffic only from pods with label 'app: api' on TCP port 5432. By default, if no NetworkPolicy exists, all traffic is allowed; once a NetworkPolicy selects a pod, all traffic not explicitly allowed is denied. This policy therefore restricts communication to only the intended api-to-db flow on the specified port.

The NodeRestriction admission plugin is recommended by the CIS Kubernetes Benchmark to restrict the kubelet's ability to modify nodes. It limits the kubelet's permissions to only modify its own node and its own pods, preventing it from altering other nodes or performing unauthorized operations. This plugin enforces a security boundary by rejecting requests that attempt to modify node labels, taints, or status outside the kubelet's assigned scope.

D is correct because Cilium, combined with Hubble, is specifically designed to provide deep network flow visibility and monitoring for Kubernetes pods. Hubble leverages eBPF to capture and report network traffic at the kernel level, offering granular observability into pod-to-pod communications, which directly meets the requirement for security analysis of network traffic between pods.

The rule produces a violation only when runAsNonRoot is not true. If it is true, the rule does not fire, and the pod is admitted.

Option C is correct because the 'baseline' PodSecurity standard enforces the minimum restrictions that prevent privilege escalation, including dropping the NET_RAW capability by default. The 'baseline' profile is designed to be applied to namespaces where most workloads run, and it automatically adds NET_RAW to the required drop capabilities list, which directly addresses the administrator's goal without the overhead of the more restrictive 'restricted' profile.

The SecurityContext at the container level has a 'readOnlyRootFilesystem' field. When set to true, the container's root filesystem is read-only.

Using a mutating webhook to inject secrets as volumes is a common pattern (e.g., with Vault Agent Sidecar Injector). It avoids storing secrets in environment variables and integrates with native Kubernetes resources. Option A is insecure; option B is deprecated; option D exposes secrets in the command line.

Syft is a CLI tool for generating an SBOM from container images. It outputs a list of packages and dependencies.

Pod Security Standards (restricted profile) and Pod Security Policies (deprecated but still valid in some contexts) both enforce runAsNonRoot. OPA Gatekeeper can also enforce custom policies.

The `cosign sign` command is used to sign a container image and attach the signature to the image registry.

Option B is correct because Pod Security Admission (PSA) in Kubernetes v1.24 enforces policies via namespace labels. Setting `pod-security.kubernetes.io/enforce=restricted` on the 'production' namespace will reject any new pod that violates the restricted policy, but existing pods are not re-evaluated and continue running. This behavior is by design: PSA evaluates pods at creation or update time, not retroactively, so existing workloads are unaffected.

Option A is correct because the `Localhost` seccomp profile type allows you to reference a custom seccomp profile stored as a JSON file on the node's filesystem. This is a valid profile type in Kubernetes, specified via the `localhostProfile` field in the pod's security context. Option B is correct because `RuntimeDefault` is a valid seccomp profile type that instructs the container runtime (e.g., containerd or CRI-O) to apply its own default seccomp profile, which typically blocks a set of dangerous syscalls while allowing normal operations.

Describing the constraint and constraint template reveals the specific rule and any error messages.

CIS control 1.1.1 specifically checks that the API server pod specification file (typically /etc/kubernetes/manifests/kube-apiserver.yaml) has permissions set to 644 or more restrictive (e.g., 600 or 640). This ensures that only authorized users (root or the kube-apiserver process) can read or modify the file, preventing unauthorized changes to critical API server configuration.

Option C is correct because enabling audit logging on the API server records all requests to the cluster, providing an immutable record for security monitoring, incident response, and compliance. Audit logs are essential for detecting unauthorized access attempts, misconfigurations, and policy violations, and are a core requirement for Kubernetes security hardening.

Option B is correct because 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.

Syft is specifically designed for SBOM generation. Trivy also has the ability to generate SBOMs. Cosign is for signing, Clair is a vulnerability scanner, and Kubesec is for static analysis of manifests.

Trivy can scan filesystems (trivy fs) to find vulnerabilities in packages before building an image. This allows catching issues early in the pipeline.

The 'privileged' level is the most permissive, with no restrictions.

Scanning images for vulnerabilities and signing images are key supply chain security practices. Storing secrets in the pipeline YAML is insecure, and ignoring critical CVEs is not a best practice.

Option D is correct because the default seccomp profile (RuntimeDefault) blocks a specific set of syscalls for security. When an application requires a blocked syscall, the proper approach is to create a custom seccomp profile that explicitly allows that syscall, then apply it to the container via `seccompProfile.type: Localhost` and reference the profile file. This maintains security by only relaxing the necessary restriction, rather than disabling the profile entirely.

Using minimal base images like distroless or Alpine reduces the number of packages and thus the attack surface.

Option C is correct because the `automountServiceAccountToken` field in the Pod spec controls whether the service account token is automatically mounted into the container. Setting this field to `false` prevents the automatic mounting of the token, which is a security best practice to reduce the attack surface for compromised pods. This field can be set at the Pod level or overridden at the ServiceAccount level.

The 'restricted' Pod Security Standard (PSS) enforces the strongest set of security constraints, including preventing containers from running as root and disallowing privilege escalation. Specifically, it requires `securityContext.allowPrivilegeEscalation: false` and prohibits running as root, which directly blocks escalation via setuid binaries. Applying this standard at the namespace level ensures all pods in that namespace inherit these controls, meeting the requirement.

Option A is correct because the `capabilities.add` field in the `securityContext` is specifically designed to add Linux capabilities (such as `SYS_TIME`) to a container without granting full root privileges. This follows the principle of least privilege, allowing only the required capability to modify the system clock.

The correct field is 'securityContext.runAsUser: 1000' at the pod or container level. Option C is the only one with the correct syntax.

Using minimal base images reduces the attack surface, and scanning images for vulnerabilities helps identify and fix security issues before deployment.

Webhook token authentication (Option B) is a valid method to restrict API server access because it delegates token validation to an external service via a webhook, allowing custom authentication logic. This is a supported authentication strategy in Kubernetes, enabling fine-grained control over who can access the API server.

Option A is correct because using image digests (e.g., `nginx@sha256:abc123...`) pins the image to an immutable content hash, ensuring that the exact same image is pulled every time, even if the tag is updated to a malicious version. This prevents tag-mutation attacks where an attacker replaces a benign image tag with a compromised one. Digests are verified by the container runtime (containerd) against the registry's manifest, providing cryptographic assurance of image integrity.

Option C is correct because the `--audit-log-path` flag is the mandatory parameter that enables audit logging in the kube-apiserver. Without specifying a file path for the audit log, the API server will not write any audit events, even if other audit-related flags are set. This flag tells the API server where to persist the audit log entries, effectively activating the audit logging feature.

If the image was signed, but verification fails, it could be due to an incorrect public key being used for verification. The webhook must have the correct key to validate the signature.