Certified Kubernetes Security Specialist CKS (CKS) — Questions 151–225

PeerAuthentication enforces mTLS on the server side, and DestinationRule configures the client side. Both are used together for comprehensive mTLS enforcement.

Falco installation, configuration, deployment as DaemonSet, monitoring alerts, and tuning are the key steps.

Option C is correct because the best practice is to apply the principle of least privilege: instead of deleting the service account or disabling its token, you should modify the ClusterRoleBinding to bind the service account to a ClusterRole with only the permissions it actually needs. This retains the service account's functionality while removing excessive cluster-admin privileges, which grant unrestricted access to all cluster resources.

Option C is correct because the principle of least privilege dictates that a service account should only have the permissions necessary for its function. The cluster-admin role grants superuser access across the entire cluster, which is excessive for a monitoring service account. Replacing it with a custom Role that includes only the required API operations (e.g., get, list, watch on pods and nodes) reduces the attack surface and aligns with Kubernetes security best practices.

An ImagePolicyWebhook admission controller can be used to evaluate container images against a policy, such as requiring scan results to be free of specified vulnerabilities. Options A, B, and D are not designed for this purpose.

The correct command to load an AppArmor profile from a file is `apparmor_parser my-profile`. The `apparmor_parser` tool is used to load, replace, or remove AppArmor profiles into the kernel. When invoked without flags, it loads the profile from the specified file into the kernel's AppArmor security module, enforcing the defined access controls.

Option C is correct because etcd requires client certificate authentication to verify the identity of clients (such as kube-apiserver) connecting to it. Without mutual TLS (mTLS), an attacker could impersonate a legitimate client and read or modify cluster state, including secrets and configuration data.

Kyverno policies can validate, mutate, or generate resources. To enforce a condition (e.g., image registry), use the 'validate' action. If the condition fails, the resource is rejected.

Option A is correct because `aa-status` is the standard AppArmor utility that displays the status of AppArmor, including which profiles are loaded and their enforcement mode (enforce, complain, or unconfined). Running this command on the node will show whether 'k8s-apparmor-profile' is loaded and set to enforce mode, which directly answers the verification requirement.

The kube-apiserver is the only Kubernetes control plane component that directly communicates with etcd. To encrypt this communication, TLS certificates must be configured on both the kube-apiserver (as the client) and etcd (as the server). The kube-apiserver presents its client certificate to etcd, and etcd presents its server certificate to the kube-apiserver, establishing a mutually authenticated TLS session.

Scanning images for vulnerabilities, generating SBOMs, and signing images are all key supply chain security practices.

Option C is correct because to enable audit logging in the Kubernetes API server, you must specify both an audit policy file (using --audit-policy-file) to define which events should be logged and at what level, and a log file path (using --audit-log-path) to specify where the audit logs should be written. Without the policy file, the API server does not know which requests to audit; without the log path, the audit events have no output destination.

Kyverno is a Kubernetes-native policy engine that can validate, mutate, and generate resources using admission controller webhooks. It can enforce that certain labels exist on resources.

Isolating via egress denial, collecting logs/exec output, and taking a memory dump for forensic analysis are appropriate. Restarting pods may destroy evidence, and deleting the namespace is too drastic.

Option A is correct because kube-bench runs as a Kubernetes Job, and the standard way to execute it against a cluster node is to apply a Job YAML manifest that runs the aquasec/kube-bench image. This Job performs CIS Benchmark checks on the node where it is scheduled, and the results are output to the Job's logs. The `kubectl apply -f job.yaml` command deploys the pre-configured Job, which is the recommended method for running kube-bench in a cluster context.

Falco uses system calls to monitor file writes. The 'write' syscall is used when a process writes data to a file. 'open' and 'openat' are used to open files, but the actual write event is captured by 'write'. 'chmod' changes permissions.

The node logs explicitly state 'AppArmor not available', which indicates that the AppArmor kernel security module is either not loaded or not enabled on the node's operating system. Without AppArmor support in the kernel, the kubelet cannot enforce the profile specified in the pod annotation, causing the pod to remain in 'Pending' state. This is a prerequisite condition for AppArmor profiles to work in Kubernetes.

The 'runAsNonRoot' field in the security context enforces that the container cannot run as root. Option B is correct.

Option D is correct because signing container images with a private key and verifying the signature before deployment ensures image integrity and authenticity, directly mitigating supply chain attacks where an attacker could tamper with images in transit or at rest. This control, often implemented using tools like Notary or Cosign (part of the Sigstore project), provides cryptographic proof that the image was produced by a trusted source and has not been altered. Without signature verification, even a vulnerability-scanned image could be replaced with a malicious one, bypassing other controls.

Option C is correct because the PodSecurityPolicy (PSP) admission controller must be explicitly enabled in the kube-apiserver's `--enable-admission-plugins` flag. Without it, PSP resources are stored in etcd but never enforced, allowing any pod to run with root privileges regardless of PSP definitions.

'cosign verify-attestation' verifies the attestation against a public key.

Syft is a tool specifically designed for generating SBOMs from container images and filesystems.

AppArmor has three modes: enforce, complain, and unconfined. The question asks for two valid modes, so 'enforce' and 'complain' are correct. 'Unconfined' is also valid but is a mode that disables AppArmor for a profile. Since the question asks for two, we can pick enforce and complain. 'Disabled' is not a valid mode, and 'audit' is not a mode.

Option A is correct because the `securityContext.seccompProfile.type` field in the pod spec is the current, stable method to apply a seccomp profile to a pod in Kubernetes (since v1.19). This field directly specifies the seccomp profile type (e.g., `RuntimeDefault`, `Localhost`, or `Unconfined`) at the container or pod level, and is the recommended approach in modern clusters.

`ImagePullBackoff` indicates that the kubelet is unable to pull the image. Using `latest` tag can lead to pull failures if the tag is not found or if there is a registry issue, but more commonly, it's due to authentication or network issues. However, the most likely cause among the options is that the image requires authentication and no image pull secrets are configured.

The ImagePolicyWebhook admission controller allows a cluster to enforce a policy that only approved container images can run by sending image admission requests to an external webhook backend. This webhook can validate images against an allowlist, a trusted registry, or a custom policy engine, and it returns an admission decision (allow or deny) before the pod is created. This directly meets the requirement of restricting which container images are permitted in the cluster.

The condition checks for an open system call on the file /etc/shadow.

Option A is correct because using iptables to restrict access to port 10250 to only the cluster's internal CIDR (e.g., 10.0.0.0/8) directly addresses the audit finding by blocking unauthenticated public access while allowing necessary kubelet API communication from within the cluster. This approach does not disrupt running workloads, as it only modifies firewall rules without restarting kubelet or changing its configuration. It leverages the existing network infrastructure (iptables) and is consistent with the principle of least privilege for an untrusted internal network.

Unconfined means no seccomp filtering is applied, so the container can make any syscall. Option B is correct.

Option A is correct because the annotation format for applying an AppArmor profile to a container in a pod is `container.apparmor.security.beta.kubernetes.io/<container_name>`. The value `localhost/k8s-apparmor-example` specifies that the profile named `k8s-apparmor-example` is loaded locally on the node. This annotation enforces the profile on the container named 'nginx'.

Setting 'hostNetwork: true' gives the container access to the host's network stack, allowing it to sniff traffic. Setting it to false prevents this.

The `aa-status` command displays the current status of AppArmor, including all loaded profiles, their enforcement mode (enforce/complain), and which processes are confined by them. This is the standard tool for listing active AppArmor profiles on a system.

The taint on the control-plane node prevents pods without tolerations from being scheduled. The pod must either tolerate the taint or be scheduled to a worker node that does not have this taint.

Setting hostPID to true allows a container to share the host's process ID namespace, enabling it to see all host processes and potentially access sensitive information or perform privilege escalation. Avoiding this setting reduces the attack surface by preventing containers from interacting with host-level processes, which is a key principle of namespace isolation in Kubernetes.

OPA/Gatekeeper can create a Constraint that validates image registry. Option A is correct.

The CIS Kubernetes Benchmark recommends disabling anonymous authentication on the kubelet to ensure that all requests are authenticated. Setting `--anonymous-auth=false` forces the kubelet to reject requests from unauthenticated users, reducing the attack surface and preventing unauthorized access to the kubelet API.

'kubectl exec' can be used for forensics by executing commands inside a container. NetworkPolicy can isolate compromised pods. 'kubectl delete pod' removes evidence. 'crictl images' lists images, not running containers. 'kubectl logs --previous' shows logs of crashed pods but is not a response technique.

Option C is correct because the NodeRestriction admission controller limits the Node and Pod objects a kubelet can modify, preventing a compromised node from escalating privileges or tampering with other workloads. This is a key Kubernetes-native control to harden the kubelet's authorization scope.

The CIS benchmark for Kubernetes recommends disabling anonymous authentication on the kubelet to ensure that all requests to the kubelet API are authenticated. Setting `--anonymous-auth=false` forces the kubelet to reject requests from unauthenticated users, preventing potential unauthorized access to node-level operations such as pod logs, exec, and port-forwarding.

RBAC is a valid method to secure etcd because etcd supports role-based access control for its API, allowing you to define roles and permissions that restrict which users or processes can read or write keys. By enabling RBAC on etcd, you can limit access to sensitive cluster data, such as secrets and configuration, to only authorized components like the Kubernetes API server.

The kubelet's `--anonymous-auth` flag controls whether anonymous requests to the kubelet API are permitted. Setting `--anonymous-auth=false` explicitly denies all anonymous requests, ensuring that only authenticated users can interact with the kubelet. This is a critical hardening step to prevent unauthenticated access to node-level operations.

The NodeRestriction admission controller only limits node self-updates to kubelet nodes, preventing them from modifying their own labels, taints, or other node objects. It does not block pods with `hostNetwork: true`. The error is most likely caused by a missing PodSecurityPolicy or Pod Security Admission (PSA) that denies pods with `hostNetwork: true`, as these are the mechanisms that enforce host namespace restrictions.

ValidatingWebhookConfiguration and MutatingWebhookConfiguration are cluster-scoped resources that can be listed with kubectl get.

Option A is correct because using a read-only root filesystem for containers (e.g., setting `readOnlyRootFilesystem: true` in the container's security context) prevents attackers from writing malicious binaries or modifying system files inside the container, even if they gain code execution. This reduces the attack surface by limiting the container's ability to persist changes or escalate privileges through file system manipulation.

Option C is correct because in Kubernetes 1.24, PodSecurityPolicy (PSP) has been removed, and the PodSecurity admission controller with the restricted profile is the built-in replacement that enforces a read-only root filesystem for all pods. The restricted profile sets `securityContext.readOnlyRootFilesystem: true` by default, ensuring compliance without external tools.

Accessing the Kubernetes Dashboard via `kubectl proxy` is recommended because it creates an authenticated HTTP proxy between your local machine and the Kubernetes API server. This ensures that all traffic to the Dashboard is tunneled through the API server's authentication and authorization mechanisms, preventing direct exposure of the Dashboard to the network and reducing the attack surface.

Falco rule priorities are: EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, NOTICE, INFO, DEBUG. WARNING is used for potentially malicious activities that warrant investigation.

runAsNonRoot: true requires that the image's default user is not root (UID 0). Even though runAsUser overrides the user, the validation checks the image's USER directive first.

Option A is correct because CVE-2019-11245 affects kubelet container runtime exec probes in Kubernetes versions prior to 1.14, where containers could restart unexpectedly due to a race condition. Upgrading to 1.14 or later patches this vulnerability. Option C is correct because setting --anonymous-auth=false on the kubelet disables unauthenticated access to the kubelet API, which is a common finding from kube-hunter when default kubeadm settings leave anonymous authentication enabled.

Option B is correct because a custom seccomp (secure computing mode) profile can restrict the system calls (syscalls) a container is allowed to make. By blocking the specific vulnerable syscall exploited by CVE-2024-1234, you can prevent the vulnerability from being triggered at runtime without rebuilding the image. This is a temporary, Kubernetes-native mitigation that directly addresses the attack vector at the syscall level.

Cosign is for signing and verifying images. Notary is a signing framework. Trivy scans for vulnerabilities, Syft generates SBOMs, and kubesec analyzes manifests.

Setting `automountServiceAccountToken: false` in a Pod spec prevents the automatic mounting of the Kubernetes service account token (a JWT) into the Pod's filesystem at `/var/run/secrets/kubernetes.io/serviceaccount/token`. This is a security hardening measure to reduce the attack surface for compromised containers, as the token can be used to authenticate to the Kubernetes API server. By default, Kubernetes mounts this token into every Pod, so explicitly disabling it is necessary when the Pod does not require API access.

cosign verify is the correct command to verify an image signature. The other options are for signing or other operations.

Option A is correct because the baseline Pod Security Standard (PSS) restricts only privileged capabilities but allows adding specific capabilities like NET_ADMIN via the `capabilities.add` field in the securityContext. The baseline profile permits most capabilities except those that are explicitly restricted (e.g., CAP_SYS_ADMIN), so adding NET_ADMIN directly is compliant without needing to drop all capabilities first.

Cosign verify can be used with a public key or with keyless verification using Fulcio. The command 'cosign verify' is not correct; it must specify the key or use keyless.

The `--anonymous-auth` flag on the kube-apiserver controls whether anonymous requests are allowed. Setting `--anonymous-auth=false` explicitly disables anonymous authentication, meaning requests without valid credentials will be rejected with a 401 Unauthorized response. This is the correct parameter to harden the API server against unauthenticated access.

Option D is correct because when `seccompProfile.type: RuntimeDefault` is set in a pod's security context, the container runtime (e.g., containerd or CRI-O) applies its own default seccomp profile. This runtime default profile is a curated allowlist that blocks approximately 40 syscalls known to be dangerous or unnecessary for containers, providing a balance between security and compatibility. It is not the Docker default (which blocks ~300 syscalls) but a more permissive profile tailored to the runtime's container model.

Option B is correct because `resources` is a valid field in an EncryptionConfiguration YAML that specifies which Kubernetes resources (e.g., secrets) should be encrypted. The EncryptionConfiguration object defines how to encrypt data at rest in etcd, and the `resources` field lists the resource types to encrypt, such as `secrets`. Without this field, the encryption configuration would not know which resources to apply encryption to.

Option A shows the correct syntax for mounting a secret as a volume. Option B uses ConfigMap, C has wrong field name, D uses env var.

The 'open_read' macro matches open syscalls with read access. The 'fd.name' field matches the file path. Combining them detects reads to /etc/shadow.

Scanning images for vulnerabilities, signing images, and enforcing policies with admission controllers are key practices. Running containers as root is insecure. Using mutable tags (like latest) is discouraged.

They provide stronger isolation than default runc, have performance overhead, and are selected via RuntimeClass. They do not share the host kernel directly; Kata uses a lightweight VM, gVisor uses a user-space kernel.

Audit levels are None, Metadata, Request, RequestResponse. 'Full' is not valid; 'Response' is not a level; 'Log' is not a level.

The baseline policy does not allow privileged containers. The admission controller will reject the pod creation.

Option D is correct. Using distroless or Alpine base images reduces the attack surface by minimizing packages and vulnerabilities. Options A, B, and C are insecure practices.