Certified Kubernetes Security Specialist CKS (CKS) — Questions 901–975

In complain mode, AppArmor allows all actions but logs violations. It is used for testing and learning without enforcement.

Option E is correct because it implements a complete chain of custody for container images. In-toto generates signed attestations that record every step of the CI/CD pipeline (e.g., source code checkout, build, test), and an admission webhook like Kyverno verifies these attestations before allowing a pod to run. This ensures that only images that passed the exact, attested pipeline are deployed, providing the strongest guarantee against unauthorized or tampered images.

Option D is correct because a Role is namespaced and can only grant permissions within a specific namespace, which is 'production' in this case. A RoleBinding then binds that Role to a user, group, or service account within the same namespace, ensuring the permissions are scoped correctly. This combination restricts secret read access exclusively to the 'production' namespace, meeting the requirement precisely.

Option B is correct because setting `automountServiceAccountToken: false` in the pod spec explicitly disables the automatic mounting of the service account token into the pod. This is the most direct and granular way to prevent the token from being available inside the container, which is a key hardening step to reduce the attack surface if the pod does not need to interact with the Kubernetes API.

The securityContext must include capabilities.drop with ALL and allowPrivilegeEscalation set to false. Option B has both.

Option C is correct because the `--kubeconfig` flag on the kubelet specifies the path to a kubeconfig file that contains the credentials and server address for the API server. When this flag is set, the kubelet uses TLS to authenticate and encrypt all communication with the API server, as the kubeconfig file typically references an HTTPS endpoint and includes client certificates or tokens. Without this flag, the kubelet may fall back to insecure or unencrypted connections, violating the requirement for encrypted communication.

kubectl exec with -- ps aux runs the ps command inside the container, capturing processes without altering the container state.

Option B is correct. gVisor (runsc) provides a sandboxed kernel for containers. Kata Containers also provides sandboxing but uses a lightweight VM. Docker and containerd are general-purpose runtimes.

Option B is correct because setting `automountServiceAccountToken: false` in the service account definition prevents the automatic mounting of the service account token into any pod that uses that service account. This is a declarative, scalable approach to disable token mounting for all pods associated with that service account, aligning with the principle of least privilege.

crictl ps lists containers managed by the CRI runtime. It's analogous to 'docker ps'.

Setting readOnlyRootFilesystem: true and mounting an emptyDir volume for writes allows immutability with a writable scratch space.

The manifest defines an audit policy rule with `level: Metadata` for the Secrets API (group: "", resources: ["secrets"]). The Metadata level logs only the metadata of the request—such as user, timestamp, and resource—without logging the request body or response body. Therefore, the correct audit level for requests to the Secrets API is Metadata.

Falco defines priorities: EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, NOTICE, INFO, DEBUG. 'HIGH', 'MEDIUM', 'LOW' are not standard Falco priorities.

Option C is correct because the `--anonymous-auth=false` flag explicitly disables anonymous authentication on the kube-apiserver. By default, anonymous requests are allowed (the flag defaults to `true`), which can permit unauthenticated users to access the API server. Setting this flag to `false` ensures that all requests must present valid credentials, aligning with the principle of least privilege and hardening the cluster against unauthorized access.

The valid audit stages are RequestReceived, ResponseStarted, ResponseComplete, and Panic. Options B and D are correct.

Options A, C, and D are best practices for node hardening. Option B is not a best practice because installing unnecessary packages increases attack surface. Option E is not a standard practice; SSH might be needed for admin access but should be restricted, not necessarily removed entirely.

Option D is correct because setting `automountServiceAccountToken: false` in the service account definition prevents pods that use that service account from automatically mounting the service account token. This is the recommended way to disable automatic token mounting at the service account level, as per Kubernetes security best practices.

Disabling swap is a prerequisite for Kubernetes nodes to ensure kubelet works correctly with memory management and resource isolation. Running 'swapoff -a' disables all active swap devices immediately, and removing the swap entry from /etc/fstab prevents swap from being re-enabled after a reboot. This is the standard and complete method recommended by Kubernetes documentation for system hardening.

Option A is correct because using a ClusterIP service restricts the Dashboard to internal cluster access only. Access is then granted exclusively through `kubectl proxy`, which creates a local proxy server that authenticates the user via their kubeconfig context, ensuring that only authenticated and authorized users can reach the Dashboard without exposing it to the network.

Option D is correct because the `--audit-log-path` flag is required to enable audit logging in the Kubernetes API server. Without specifying a log path, the API server will not write audit events to a file, even if an audit policy is defined. The `--audit-policy-file` flag (Option A) defines the rules for what to audit, but audit logging itself is only activated when a log destination is provided via `--audit-log-path`.

The policy enforces that all Pods must have 'runAsNonRoot: true' in their security context. If a Pod does not have this setting, it will be rejected (enforce mode).

The Kubernetes Dashboard is a powerful administrative tool that should never be exposed to the public internet. Deleting the dashboard deployment and using `kubectl proxy` to access it locally is the recommended action because it eliminates the attack surface entirely and ensures that access is restricted to the machine running the kubectl command, leveraging the API server's built-in authentication and authorization.

Option B is correct because the AppArmor profile annotation for a container must follow the format `container.apparmor.security.beta.kubernetes.io/<container_name>: localhost/<profile_name>`. This annotation is in the `security.beta.kubernetes.io` API group (beta, not alpha) and targets the specific container by name. The value must include the `localhost/` prefix to indicate a profile loaded on the node, not a built-in or default profile.

Audit logging is enabled by specifying --audit-policy-file pointing to a policy file. The policy file defines the level. The flag itself is --audit-policy-file.

ImagePolicyWebhook is the admission controller that can be configured to validate images against an external webhook, typically used for image signature verification.

Option B is correct because regular auditing of ClusterRoleBindings and RoleBindings helps identify over-privileged subjects, such as service accounts or users with excessive permissions, which is a key hardening practice. This aligns with the principle of least privilege and is recommended by Kubernetes security best practices to reduce the attack surface.

Syft generates SBOMs, and Trivy can also generate SBOMs (in addition to vulnerability scanning). Cosign is for signing, Kubesec is for manifest analysis, and Checkov is for infrastructure-as-code scanning.

The 'kubectl create secret generic' command with '--from-file' flag creates a secret from a file. The syntax is 'kubectl create secret generic <name> --from-file=<key>=<source>' or just '--from-file=<source>' where the key defaults to the filename.

Option A is correct because kubeadm enforces a strict version skew policy: the kubelet version must not be newer than the control plane version, and downgrading the control plane (e.g., from v1.28 to v1.27) is not supported. Attempting a downgrade can lead to API version mismatches, schema incompatibilities, and cluster instability. In production, you must plan upgrades carefully and never downgrade the control plane components.

Option B is correct because the PodSecurity admission controller uses the label `pod-security.kubernetes.io/enforce` to enforce the specified Pod Security Standard (e.g., `baseline`) at the namespace level. Pods that violate the enforced level are rejected by the admission controller. The `enforce` label triggers the admission webhook to block non-compliant pods, which matches the requirement to reject violations.

The correct answer is B (PodSecurity) because the PodSecurity admission plugin (replacing the deprecated PodSecurityPolicy) enforces a restricted security context on pods, preventing them from automatically mounting the default service account token. By default, Kubernetes mounts a service account token into every pod, which can be exploited if an attacker gains access to a pod. Enabling PodSecurity with a policy that restricts automounting of service account tokens addresses the kube-bench finding.

The error 'container has runAsNonRoot but image will run as root' occurs because the Pod's security context sets `runAsNonRoot: true`, but the container image is configured to run as root (UID 0). Setting `runAsNonRoot: false` removes the enforcement, allowing the container to run as root as the image expects. This directly resolves the conflict between the security context constraint and the image's default user.

The NodeRestriction admission plugin ensures that kubelets can only modify their own Node API objects and pods bound to them. When enabled, it prevents a kubelet from modifying nodes it is not assigned to, enforcing the principle of least privilege and limiting the blast radius of a compromised kubelet.

The 'system:node' ClusterRoleBinding is a legacy binding that grants the 'system:node' cluster role to all nodes, effectively bypassing the Node Authorizer and NodeRestriction admission plugin. The CIS Benchmark for Kubernetes (section 5.1.1) recommends deleting this binding because it allows nodes to have broad, unrestricted access to the API server, which undermines the principle of least privilege. Instead, the Node Authorizer and NodeRestriction plugin should be used to enforce fine-grained, node-specific permissions based on the node's identity and the pods it runs.

Using minimal base images reduces the attack surface. Distroless images contain only the application and its runtime dependencies, reducing vulnerabilities.

Option B is correct because a NetworkPolicy with an empty `ingress` array (i.e., `ingress: []`) explicitly denies all inbound traffic to the selected pods. This ensures that the kubernetes-dashboard pod in the kube-system namespace is not publicly accessible, as no ingress rules are defined to allow any source. By default, if no NetworkPolicy selects a pod, all traffic is allowed; applying this policy changes the default to deny for ingress.

The Restricted Pod Security Standard enforces runAsNonRoot: true, which is the requirement. Using enforce mode ensures that any pod violating this policy is rejected at admission.

Option B is correct because enabling TLS with peer and client certificates encrypts all communication between etcd members and between etcd and the Kubernetes API server, preventing man-in-the-middle attacks and unauthorized access. This is a fundamental security requirement for etcd in production clusters, as etcd stores all cluster state and secrets.

Accessing the Kubernetes Dashboard via 'kubectl proxy' is recommended because it creates a local HTTP proxy between your workstation and the API server, ensuring the Dashboard is never exposed to external networks. This approach leverages the API server's authentication and authorization mechanisms, avoiding the need to open network ports or expose the Dashboard directly, which aligns with the principle of least privilege and reduces the attack surface.

The NodeRestriction admission plugin limits the Node and Pod objects a kubelet can modify. When enabled, each kubelet can only create/modify pods bound to its own node, and only pods that have been scheduled by the API server (i.e., have a non-empty `spec.nodeName` set by the scheduler). This prevents a compromised kubelet from creating arbitrary pods or modifying pods on other nodes, enforcing that only the API server schedules pods.

Option C is correct because the CIS Benchmark for Kubernetes requires disabling anonymous authentication on the kubelet by setting `--anonymous-auth=false`. This ensures that all requests to the kubelet are authenticated, preventing unauthenticated access to the kubelet API, which could allow an attacker to execute commands or retrieve sensitive node information.

Using a SHA digest ensures the image is immutable and exactly the same version each time. Option C is correct.

The correct approach is to set 'allowPrivilegeEscalation: false' and 'capabilities.drop: ["ALL"]' under the container's securityContext. This ensures no privilege escalation and drops all capabilities.

The write will fail because the root filesystem is read-only.

The correct options are A and B. runAsNonRoot: true ensures the container runs as a non-root user; readOnlyRootFilesystem: true makes the root filesystem read-only. Option C is unrelated, D disables privilege escalation but does not enforce non-root/read-only root, and E is a deprecated field.

Securing etcd involves TLS configuration, restarting, health verification, and network restriction.

The 'RuntimeDefault' type tells the runtime to use its default seccomp profile.

In OPA/Gatekeeper, a ConstraintTemplate defines the Rego logic (policy), and a Constraint instantiates that policy with specific parameters and scope. Pod Security Policies are deprecated; PodSecurity admission is a separate mechanism. ValidatingWebhookConfiguration is auto-managed by Gatekeeper.

crictl and ctr are CLI tools for interacting with CRI-compatible container runtimes. kubectl and docker are not available on nodes by default; docker is not always the runtime.

ResponseStarted captures the stage after the request is processed but before the response body is sent.

The correct command is 'kubectl logs -f my-pod'. The -f flag streams logs in real time.

The NodeRestriction admission plugin limits the kubelet's ability to modify its own Node object, ensuring it can only label, taint, or update status on its assigned Node. This prevents a compromised kubelet from impersonating other nodes or escalating privileges. It is the correct plugin for enforcing node-scoped kubelet permissions.

To deny all egress traffic, a NetworkPolicy must have podSelector matching the pod and an empty egress rules list (or a rule with no to). Option B matches the pod and has no egress rules, defaulting to deny.

Falco uses conditions like 'evt.type=open' and 'fd.name=/etc/shadow' to detect file access. The open syscall is used for opening files.

Scanning images for vulnerabilities in a CI pipeline before deployment is a best practice because it catches known CVEs early, preventing vulnerable images from reaching production. Tools like Trivy, Clair, or Grype integrate into CI/CD to enforce policy gates, ensuring only compliant images proceed.

Option A is correct because the CIS Kubernetes Benchmark recommends enabling audit logging on the API server to record all requests and responses, which is essential for security monitoring, forensics, and compliance. Option B is correct because disabling anonymous authentication on the API server prevents unauthenticated requests from being processed, reducing the attack surface. The benchmark specifically advises setting `--anonymous-auth=false` on the API server to enforce authentication for all requests.

Option A is correct because disabling hostPID and hostNetwork prevents containers from accessing the host's process namespace and network stack, which would otherwise allow privilege escalation or network sniffing. This aligns with the principle of least privilege and reduces the node's attack surface by isolating container workloads from the host OS.

kubectl get endpoints lists the endpoints for a service, showing the IPs and ports of the pods backing the service. If endpoints are missing, the service won't route traffic.

Using a digest (SHA256) ensures that the image identifier is unique to the content, making it immutable. Tags like 'v1.0' can be overwritten.

The `hostNetwork` field in the Pod Security Context, when set to `true`, allows the container to use the host's network namespace directly, bypassing the pod's own network stack. Setting it to `false` (the default) ensures the container uses an isolated network namespace, preventing direct access to host network interfaces, iptables rules, and network services. This is the correct field to disable to meet the requirement of preventing container access to the host's network.

Option A is correct because vulnerability scanning tools like Trivy or Grype are essential for identifying known CVEs in container images before deployment. Integrating these tools into the CI/CD pipeline ensures that only images with an acceptable vulnerability posture are built and pushed to the registry, forming a foundational security gate in the software supply chain.

The CIS Kubernetes Benchmark recommends enabling audit logging to record all API server requests, which is essential for security monitoring and forensic analysis. It also recommends disabling anonymous authentication to ensure that all requests are authenticated, preventing unauthenticated access to the cluster.