Certified Kubernetes Security Specialist CKS (CKS) — Questions 526–600

Mounting Secrets as volumes is recommended over environment variables because they are not exposed in container environment or command output. Secrets themselves are base64 encoded but not encrypted by default; enabling encryption at rest adds another layer.

The correct command uses 'kubectl label' to set the enforce label to 'restricted'. Option C is correct.

Trivy's image scanning command is 'trivy image <image-name>'. The other options are incorrect: 'trivy scan' is not a valid subcommand, 'trivy repo' scans a repository, and 'trivy fs' scans a filesystem.

Option D is correct because it uses the standard Kubernetes `securityContext.capabilities` field with `drop: ['ALL']` to remove all Linux capabilities from the container, then `add: ['NET_BIND_SERVICE']` to grant only the `CAP_NET_BIND_SERVICE` capability. This is the proper YAML syntax for the desired capability set.

RuntimeClass is the standard Kubernetes way to select a container runtime. For gVisor, the handler is 'runsc'.

Mounting secrets as volumes is more secure than environment variables because volumes do not expose secrets in process listings or logs.

CrashLoopBackOff indicates the container keeps crashing after starting. The restart policy 'Always' causes the kubelet to restart it, but if the crash persists, the backoff delay increases. The most likely cause is the application itself failing (e.g., error on startup).

The `kubectl auth can-i --list` output shows that the service account `my-sa` has `create pods` permission via a RoleBinding. To remove that permission, you must delete the RoleBinding object itself, not the service account or the role (unless the role is exclusively used by this binding). Option C correctly uses `kubectl delete rolebinding` with the specific binding name and namespace to revoke the RBAC grant.

Binding etcd to localhost (127.0.0.1) when it does not need to be accessed from other nodes restricts network exposure, reducing the attack surface. This is a fundamental network hardening practice that prevents unauthorized remote access to the etcd datastore, which stores all cluster state and secrets.

crictl ps lists all running containers on the node. crictl pods lists pods, not containers. crictl images lists images. crictl stats shows resource usage.

The capabilities field with drop: ["ALL"] removes all Linux capabilities from the container, increasing security.

The valid audit stages are RequestReceived, ResponseStarted, ResponseComplete, and Panic. RequestReceived and ResponseComplete are two of them.

Gatekeeper constraints can enforce specific registries. If the constraint does not match the exact registry name (e.g., missing port or path), the pod will be denied.

kubectl cp copies files from the container to the local machine. Using a tarball pipeline is an alternative, but kubectl cp is the standard method.

The NodeRestriction admission plugin ensures that a kubelet can only modify its own Node object and Pods bound to it. This prevents a compromised or misconfigured kubelet from tampering with other nodes, enforcing the principle of least privilege. Without this plugin, a kubelet could potentially update labels, taints, or status on any node, leading to cluster instability or privilege escalation.

Cosign sign/verify uses cryptographic signing. Notary is a CNCF project for image signing. ImagePolicyWebhook can call an external service to verify images based on policy.

Option C is correct because PodSecurity admission (PSA) is the native Kubernetes mechanism for enforcing pod security standards with minimal operational overhead. By labeling most namespaces with 'pod-security.kubernetes.io/enforce=restricted', you enforce the CISO's mandates (non-root, read-only root filesystem, no privilege escalation) automatically. Creating a separate namespace with the 'baseline' profile allows legacy apps requiring hostNetwork/hostPID to run after explicit approval, while still blocking privileged escalation and other dangerous capabilities.

NetworkPolicy with empty podSelector and policyTypes: Ingress, Egress denies all traffic.

Using distroless base images reduces the attack surface by minimizing installed packages and dependencies.

Cosign verify checks the signature of an image. Option A is correct.

Setting `automountServiceAccountToken: false` in the Pod spec prevents the automatic mounting of the service account token into the container. This enforces least privilege by ensuring that pods which do not require API access cannot inadvertently use the token to authenticate to the Kubernetes API server, reducing the attack surface.

The 'restricted' Pod Security Standard (PSS) explicitly prohibits adding any capabilities beyond the default set, which is empty. Since the pod's securityContext adds the NET_BIND_SERVICE capability, it violates the restricted policy, causing the pod to fail to start.

It detects a bash shell spawned inside a container where the parent process is not sshd.

Option D is correct because the 'restricted' Pod Security Standard enforces seccomp to RuntimeDefault as a baseline requirement. By labeling the namespace with 'pod-security.kubernetes.io/enforce: restricted', the built-in Pod Security Admission controller automatically rejects any pod that does not set seccomp to RuntimeDefault (or a custom profile), without needing a separate policy or manual auditing.

Isolation techniques include using NetworkPolicy to restrict network traffic, adding a label to the pod and applying a policy that denies all traffic, and cordoning the node to prevent new pods. Deleting the pod is a response action but not isolation; modifying the container image is not isolation.

ValidatingWebhookConfiguration is the resource for admission webhooks that validate resources.

Option A is correct because exposing the Kubernetes dashboard to the public internet significantly increases the attack surface, making it a prime target for credential theft, API abuse, and cluster compromise. The dashboard should only be accessible via internal networks, VPNs, or using kubectl proxy with authentication, never directly over the internet.

Option B is correct because the pod manifest does not set `readOnlyRootFilesystem: true` in the container's security context. Without this setting, the container's root filesystem is writable by default, allowing an attacker who compromises the container to modify binaries, configuration files, or write malicious scripts to persistent storage, thereby increasing the attack surface and potentially enabling persistence or privilege escalation.

Option D is correct because it follows the proper incident response workflow for a compromised container: first identify the node hosting the suspicious pod using `kubectl get pod -o wide`, then SSH to that node and use `crictl ps` (the containerd CLI) to list running containers and their IDs, then use `crictl stop` to immediately halt the compromised container. This approach directly isolates the threat at the container runtime level without relying on potentially compromised in-pod tools or deleting the pod (which could be recreated by the Deployment controller).

Option B (aescbc) is correct because Kubernetes supports AES-CBC encryption via the 'aescbc' provider in the EncryptionConfiguration. This provider uses AES in Cipher Block Chaining mode with a 32-byte key for encryption at rest, as specified in the Kubernetes documentation for encrypting etcd data.

Kubesec and Checkov are both tools that perform static analysis on Kubernetes resource definitions to identify misconfigurations and security issues.

The error 'failed to load bootstrap client certificate: open /var/lib/kubelet/pki/kubelet-client-current.pem: no such file or directory' indicates that the kubelet cannot find the bootstrap client certificate file. This file is generated from the bootstrap kubeconfig file during the initial TLS bootstrapping process. If the bootstrap kubeconfig file is missing or misconfigured, the kubelet cannot request or renew its client certificate, leading to this failure.

The --audit-policy-file flag specifies the path to the audit policy file. Without this, audit logging is disabled.

Admission controllers intercept requests to the API server and can enforce security policies.

Using an admission controller like ImagePolicyWebhook or Kyverno can enforce signature verification. Cosign verify is a manual step, not a cluster-wide enforcement.

Falco can detect shell spawning, sensitive file reads, and unexpected outbound connections via syscall monitoring. CPU/memory spikes are not directly detected by Falco as they are not syscall events; they are typically monitored by metrics tools. Pod restart loops are a Kubernetes-level symptom, not a direct syscall event.

The correct approach is to create a ConstraintTemplate that defines the Rego logic for checking the label, and then create a Constraint that uses that template. The Constraint is the actual policy object that specifies the enforcement scope (e.g., all namespaces).

A MutatingWebhookConfiguration can be used to modify pod specs at admission time, for example to remove environment variable references to secrets and replace them with volume mounts. Alternatively, a ValidatingWebhookConfiguration could deny pods that use secrets as env vars. Both are valid, but a mutating webhook can automatically fix the issue.

The event indicates insufficient CPU resources on all nodes to meet the pod's CPU request.

Scanning should be performed after building the image to catch vulnerabilities before pushing to registry. Option B is correct.

Option C is correct because in a Kubernetes Pod security context, the `capabilities` field is a list of capabilities to add or drop. Dropping `ALL` removes all Linux capabilities from the container, which is the most restrictive and secure approach. The correct YAML syntax uses `capabilities:` (plural) with a `drop:` list containing `"ALL"`.

A RuntimeClass resource defines a container runtime (e.g., gVisor) that can be referenced in pod spec via 'runtimeClassName'. This is the standard way to use alternative runtimes in Kubernetes.

The 'apparmor_parser' command is used to load AppArmor profiles into the kernel. Options A and C are not valid AppArmor commands. Option D is used to check status.

When `seccompProfile` is set to `RuntimeDefault` in a container's security context, Kubernetes instructs the container runtime (e.g., containerd, CRI-O) to apply its own default seccomp profile. This profile is typically a restrictive set of syscalls that blocks dangerous or unnecessary system calls while allowing common operations. It is not a custom profile from the node's filesystem, nor does it disable seccomp or set it to unconfined.

When `readOnlyRootFilesystem` is true, the container cannot write to any path on the root filesystem unless a writable volume is mounted. `/tmp` is on the root filesystem by default, so the container needs an emptyDir volume mounted at `/tmp` to write there.

The annotation 'container.apparmor.security.beta.kubernetes.io/<container_name>' is used to specify the AppArmor profile for a container. The other options are either non-existent or used for other purposes (e.g., seccomp).

Option D is correct because Falco is a CNCF runtime security tool that uses eBPF or kernel modules to intercept system calls. By alerting on sensitive syscalls like 'clone' (used to spawn new processes) or 'unshare' (used to create new namespaces), Falco can detect container breakout attempts where an attacker tries to escape the container's isolation. This provides real-time detection of anomalous behavior indicative of a breakout.

Falco uses syscall events. The condition container.id != host and evt.type = execve and proc.name = bash detects a bash exec in a container, which is a common interactive shell.

Creating a forensic snapshot (e.g., using dd or kubectl cp), capturing container logs, and taking a memory dump (e.g., via criu or gcore) preserve evidence. Deleting the pod destroys evidence. Running 'kubectl exec' and modifying files is destructive.

crictl uses a specific container runtime socket (e.g., containerd.sock). If the socket is not configured or the runtime is different, it won't see containers. Option A is unlikely, option B is about kubelet, option D is about image pull.

Audit stages are: RequestReceived, ResponseStarted, ResponseComplete, and Panic. ResponseComplete occurs after the response is sent.

Falco's 'spawned_process' macro or condition evt.type=execve and proc.name in (bash, sh, zsh, etc.) can detect shell execution.

With readOnlyRootFilesystem set to true, the container's filesystem is read-only, so any attempt to write to the root filesystem will fail. If the application writes to /var/log/app.log, the write will fail and the container may crash or log an error. Option A is correct.

The condition checks for a spawned process (proc.spawned) with name bash or sh and that its PID is 1 (indicating it was started by the container entrypoint and not by another process).

Option A is correct because the Kubernetes Dashboard, by default, may allow unauthenticated access if not explicitly configured. Disabling anonymous access ensures that all requests to the Dashboard are authenticated, preventing unauthorized users from viewing or manipulating cluster resources. This is typically done by setting the `--enable-skip-login` flag to false or configuring the Dashboard deployment to require authentication tokens.

Option A is correct because the Kubernetes Dashboard should run with the least privilege necessary. Granting minimal RBAC permissions to the Dashboard's service account follows the principle of least privilege, reducing the attack surface if the Dashboard is compromised. The default installation often creates a service account with excessive permissions, which should be scoped down to only what the Dashboard needs to function.

The MutatingAdmissionWebhook runs first, before ValidatingAdmissionWebhook, as mutations must be applied before validation.

runAsNonRoot, allowPrivilegeEscalation: false, and readOnlyRootFilesystem are standard security hardening measures that reduce the risk of container breakout.

Valid audit levels are None, Metadata, Request, and RequestResponse. Options B and C are valid.

The `--protect-kernel-defaults=true` flag on the kubelet ensures that the kubelet will not start if any kernel tunables (e.g., `vm.overcommit_memory`, `kernel.panic`) differ from their default values. This is a security hardening measure to prevent misconfigured nodes from running with weakened kernel settings, as required by the CIS Kubernetes Benchmark.