Certified Kubernetes Security Specialist CKS (CKS) — Questions 676–750

The correct YAML is `capabilities: drop: ['ALL']` under securityContext.

Image signing with Cosign and using SHA digests are both methods to verify image integrity. Scanning for CVEs does not verify integrity but finds vulnerabilities. Namespace isolation is not related to image verification.

'kubectl exec' with '-it' and a shell command allows interactive shell access. Option B is for logs, option C is for describing resources, option D is for deleting.

Option D is correct because setting `--anonymous-auth=false` on the kube-apiserver disables anonymous requests, ensuring that all API requests must be authenticated. This directly addresses CIS benchmark recommendations for hardening the API server against unauthorized access by preventing unauthenticated users from reaching the API.

Option A is correct because PodSecurity admission (the replacement for PSP) allows enforcing a 'restricted' policy that mandates a seccomp profile (e.g., RuntimeDefault) at the namespace level. This directly meets the requirement without relying on deprecated PSPs, and the 'enforce' mode ensures pods violating the policy are rejected.

Option B is correct because Kubernetes supports encrypting secrets at rest in etcd via an EncryptionConfiguration object. This configuration specifies which resources (e.g., secrets) should be encrypted and which encryption provider (e.g., AES-CBC, secretbox) to use, ensuring that data stored on disk is protected against unauthorized access to the etcd data directory.

The 'restricted' Pod Security Standard (PSS) requires that all Linux capabilities be dropped except those essential for the container runtime (e.g., CAP_NET_BIND_SERVICE is allowed by default in some runtimes, but the standard explicitly mandates dropping all capabilities). Option A correctly uses `drop: ["ALL"]` to remove every capability, ensuring the container runs with the minimal set required by the runtime, which aligns with the PSS 'restricted' profile. This approach enforces the principle of least privilege by preventing the container from gaining any unnecessary kernel privileges.

Option D is correct because it implements the principle of least privilege by first dropping all capabilities with `drop: ['ALL']` and then explicitly adding back only those capabilities that are strictly necessary for the container to function. This ensures that the container runs with the absolute minimum set of Linux capabilities, reducing the attack surface and adhering to Kubernetes security best practices for system hardening.

The CIS Kubernetes Benchmark recommends enabling TLS for etcd communication to ensure data in transit is encrypted.

A ClusterRoleBinding grants cluster-wide permissions, and the 'cluster-admin' ClusterRole provides superuser access to perform any action on any resource across all namespaces. Binding this to a service account violates the principle of least privilege because the service account gains unrestricted access to the entire cluster, including sensitive system resources, rather than being limited to only the permissions necessary for its function.

Understanding these concepts is important for implementing network security.

The `--audit-policy-file` flag on the kube-apiserver specifies the path to a YAML or JSON file that defines the audit policy configuration. This policy determines which events (e.g., requests to the API server) should be logged and at what level (e.g., Metadata, Request, RequestResponse). It does not directly enable audit logging or set the log file location; it only provides the rules for filtering and structuring audit events.

Option A is correct because the annotation 'seccomp.security.alpha.kubernetes.io/pod' was the original method to apply a seccomp profile to a pod in Kubernetes versions prior to 1.19. This annotation is still valid in older clusters or when using the alpha API, and it directly specifies the seccomp profile path or type for the pod.

Mutual TLS (mTLS) encrypts and authenticates all service-to-service traffic within the cluster, preventing eavesdropping, man-in-the-middle attacks, and unauthorized access. A service mesh like Istio or Linkerd transparently enforces mTLS without requiring application code changes, ensuring that only verified services can communicate. This directly minimizes the attack surface for microservice vulnerabilities by enforcing zero-trust network principles.

crictl logs shows logs, crictl exec runs a command in the container.

Running containers with privileged access increases the attack surface. The other options are recommended hardening measures.

Falco is a CNCF-graduated runtime security tool that uses eBPF or kernel modules to monitor system calls in real time, detecting anomalous behavior such as unexpected process execution or file writes. Deploying Falco is a recommended best practice for runtime security because it provides deep visibility into container activity without requiring application changes, and it can trigger alerts or actions based on customizable rules.

A is correct because ClusterRole is a Kubernetes RBAC resource that defines a set of permissions (rules) that are not namespaced, allowing cluster-wide access. RBAC in Kubernetes uses Role and ClusterRole objects to specify allowed verbs (e.g., get, list, create) on resources (e.g., pods, secrets), and they are bound to subjects via RoleBinding or ClusterRoleBinding.

ImagePolicyWebhook and MutatingAdmissionWebhook are valid admission controllers. PodSecurityPolicy is deprecated, NodeRestriction is not an admission controller, and OPA is a tool not an admission controller itself.

Option D is correct because the ClusterImagePolicy enforces that images must be signed by a specific identity (the GitHub Actions workflow defined in the policy). The image from registry.example.com/myapp:v1 was signed by a different workflow, so the signer identity does not match the policy's required identity. Sigstore keyless signing verifies the OIDC identity embedded in the signature, and if the identity does not match the policy's `issuer` and `subject` patterns, the admission controller denies the pod.

Audit logging requires a policy file, mounting it, adding flags, restarting, and verifying logs.

Option D is correct because the Pod Security Standards (PSS) baseline policy explicitly allows adding the NET_ADMIN capability. The baseline policy restricts certain capabilities but does not prohibit adding NET_ADMIN; it only restricts capabilities that could lead to host-level privilege escalation. Dropping ALL capabilities first and then adding NET_ADMIN is a valid pattern that satisfies the baseline policy's requirements.

kubectl logs with --tail=-1 fetches all lines from the logs.

Option C is correct because etcd stores sensitive cluster data (secrets, config maps, state). Restricting network access to only the API server and kubelets via firewall rules (e.g., iptables or cloud security groups) minimizes the attack surface and prevents unauthorized nodes or external actors from reaching the etcd data store. This aligns with the principle of least privilege for control plane components.

kubectl auth can-i is used to verify if a user (including service accounts) has permission to perform a specific action. A 'no' response indicates that the action is denied by RBAC.

Option C is correct because `kubectl node-shell` provides a shell into the node's filesystem, allowing you to run `aa-status` directly on the node to check the AppArmor status. This is the standard method to verify AppArmor profiles and their enforcement state on a Kubernetes node, as AppArmor operates at the host kernel level and is not managed via the Kubernetes API.

Option C is correct because setting `automountServiceAccountToken: false` on the default service account prevents any pod that uses it from automatically mounting the service account token. This reduces the attack surface: if a container is compromised, the attacker cannot use the token to authenticate to the Kubernetes API server. This is a fundamental hardening measure for service accounts that do not require API access.

Audit policies are defined with a 'level' per rule or default. To have different levels for requests and responses, you must use different stages. Option B correctly sets the default stage for 'RequestReceived' to Metadata and for 'ResponseComplete' to Request.

Audit stages are: RequestReceived, ResponseStarted, ResponseComplete, Panic. 'RequestProcessing' and 'ResponseBuffered' are not valid stages.

Option B is correct because the CIS Kubernetes Benchmark recommends disabling anonymous authentication to ensure that all requests to the kube-apiserver are authenticated. This prevents unauthenticated users from accessing the API server, which is a critical security control. Option D is correct because enabling audit logging is a recommended control to record all API requests, providing an audit trail for security monitoring and incident response.

Option C is correct because the kube-apiserver uses the `--anonymous-auth` flag to control whether anonymous requests are allowed. Setting `--anonymous-auth=false` disables anonymous authentication, meaning the API server will reject requests that do not present valid credentials. This is a critical hardening step to ensure only authenticated users can access the cluster.

These tools are widely used in the Kubernetes security ecosystem.

An audit policy rule with resources: groups: [""]; resources: ["secrets"]; level: RequestResponse will log all requests to secrets at the RequestResponse level (metadata + request + response).

Option D is correct because setting `hostPID: false` explicitly disables the container's access to the host's process ID namespace, which reduces the attack surface by preventing the container from seeing or interacting with host processes. In Kubernetes, when `hostPID` is set to `true`, the container shares the host's PID namespace, allowing it to potentially escalate privileges or interfere with other workloads. Disabling this setting (i.e., `false`) is a recommended security best practice to enforce process isolation.

The most secure approach is to use 'kubectl proxy' because it creates a local HTTP proxy between your workstation and the Kubernetes API server, authenticating your requests using your kubeconfig credentials. This ensures the Dashboard is never exposed to the network, eliminating any attack surface from external or internal cluster access. All traffic is tunneled through the API server, which enforces RBAC and audit logging.

Kubesec uses a scoring system where -1 indicates a failed scan due to an error or misconfiguration in the file.

setuid and setgid syscalls are used to change user/group identity, which can be used for privilege escalation. Falco can monitor these syscalls to detect unauthorized attempts.

Upgrade involves upgrading kubeadm, draining, applying upgrade, upgrading worker nodes, and verifying.

Option A is correct because the API server is deployed as a static pod in a typical Kubernetes cluster, with its manifest located at /etc/kubernetes/manifests/kube-apiserver.yaml. To enable encryption at rest, you must add the `--encryption-provider-config` flag to this manifest, pointing to the EncryptionConfiguration YAML file. The kubelet automatically detects the change and restarts the API server pod to apply the new encryption configuration.

The NodeRestriction admission plugin limits the kubelet's permissions to only modify labels, annotations, and status on its own Node object, preventing a compromised or misconfigured node from altering other Node objects or escalating privileges. This is a critical hardening measure for cluster setup, as it enforces the principle of least privilege on kubelet API access.

A NetworkPolicy with podSelector matching the pod and no ingress or egress rules blocks all traffic by default when policyIsolation is enabled (which is the default).

Valid audit stages are RequestReceived, ResponseStarted, ResponseComplete, and Panic. Option D (RequestProcessing) is not a valid stage. Option E (ResponseDelay) is not.

`crictl ps` lists containers, similar to `docker ps`. `crictl pods` lists pods (sandboxes). `crictl images` lists images. `crictl stats` displays resource usage.

The `--protect-kernel-defaults` flag on the kubelet ensures that the node's kernel parameters are set to secure defaults, preventing container escapes or privilege escalations that could exploit weak kernel settings. This flag enforces the kubelet's built-in kernel validator, which checks that critical sysctls (e.g., `net.ipv4.ip_forward`, `kernel.panic`) are set to safe values, and fails to start if they are not. It is a key hardening measure for cluster nodes, directly addressing kernel-level security.

Cosign is a tool for signing container images, and deploying a validating webhook (e.g., the cosigned admission controller) enforces that only images with valid signatures are admitted. This directly meets the requirement to deploy only signed and scanned images, as the webhook verifies the signature before the pod is created.

ClusterRoleBinding is the correct resource because it binds a ClusterRole (which defines cluster-wide permissions) to a user, granting permissions across all namespaces. A ClusterRole itself only defines the rules; the binding is what actually grants those permissions to a specific subject. Therefore, to grant cluster-wide permissions to a user, you need a ClusterRoleBinding referencing a ClusterRole.

Cosign is a standalone CLI tool, not a kubectl command. Option B correctly uses the cosign binary.

OPA Gatekeeper allows enforcing custom policies via ConstraintTemplates and Constraints. It can deny pods that violate the policies.

The 'readOnlyRootFilesystem' field in the security context of a container, when set to true, ensures the root filesystem is read-only. This is a common security hardening measure.

Option D is correct because the annotation `kubernetes.io/enforce-mountable-secrets: "true"` on a service account prevents pods that use that service account from automatically mounting its token. This annotation enforces that the token is only mounted if explicitly requested via `automountServiceAccountToken: true` in the pod spec or service account. It is a Kubernetes-specific annotation that directly controls token mounting behavior at the service account level.

Falco uses the 'open' or 'openat' syscall with the 'fd.name' field to check file paths. Option C correctly checks for open and openat syscalls and matches the filename.

Using specific base image tags, running as non-root, and minimizing layers are best practices. Using latest tag and installing unnecessary packages are not.

A ClusterRoleBinding grants permissions cluster-wide, meaning the service account 'sa-admin' in namespace 'ns1' can access resources in all namespaces, not just its own. This violates the principle of least privilege by providing excessive access beyond the intended scope.

Option A is correct because setting --anonymous-auth=false disables anonymous requests to the kubelet API, which is a CIS Benchmark recommendation to prevent unauthenticated access. Option D is correct because --protect-kernel-defaults=true ensures the kubelet checks and enforces kernel hardening parameters (e.g., sysctl settings) at startup, reducing the attack surface.

RequestResponse logs request metadata and the request and response body.

Option D is correct because the kube-apiserver requires the `--encryption-provider-config` flag to specify the path to the EncryptionConfiguration YAML file. This flag tells the API server which encryption providers (e.g., `aescbc`, `secretbox`) to use for encrypting secrets at rest in etcd. Without this flag, the EncryptionConfiguration file is ignored and secrets remain unencrypted.

NetworkPolicy with egress rules is the correct Kubernetes-native resource to restrict outbound traffic from pods. It uses label selectors, IP blocks, and port specifications to define which external destinations pods can reach, enforcing zero-trust network segmentation at the pod level.

Falco has a macro called 'sensitive_file_names' that includes files like /etc/shadow, /etc/passwd, etc. The rule likely uses that macro to match on open syscalls targeting those files.

Kyverno can validate pod security contexts to ensure runAsNonRoot is set. Option D is correct.

Option A is correct because Kubernetes NetworkPolicies can restrict ingress traffic to the Dashboard pod, ensuring only authorized sources can reach it. Additionally, enabling authentication (e.g., using the built-in token-based login or OIDC) prevents unauthenticated access, which is critical since the Dashboard has powerful cluster management capabilities.

Option A (aescbc) is correct because AES-CBC is a symmetric encryption algorithm that Kubernetes supports natively in EncryptionConfiguration for encrypting Secrets at rest. It uses a 32-byte key for AES-256 encryption and is the most commonly used provider for this purpose.

An SBOM provides a list of all components in a software artifact, which helps in identifying vulnerabilities and ensuring license compliance.

AppArmor has two primary profile modes: 'complain' (also known as 'learning' mode) and 'enforce' (also known as 'confined' mode). In complain mode, policy violations are logged but not blocked, allowing administrators to test profiles. In enforce mode, violations are both logged and blocked, actively enforcing the security policy.

The `imageRegistry` field in Kyverno allows you to specify a regular expression to match allowed image registries.

Trivy is a popular open-source vulnerability scanner for container images, filesystems, and Git repos. It can be easily integrated into CI/CD pipelines.

The NodeRestriction admission plugin ensures that kubelets can only modify the Node and Pod objects they are assigned to. It enforces that a kubelet with a specific node identity can only label, taint, or update its own Node object and can only create/modify Pods that are bound to that node. This prevents a compromised or misconfigured kubelet from tampering with other nodes or pods in the cluster.