Certified Kubernetes Security Specialist CKS (CKS) — Questions 301–375

The annotation 'container.apparmor.security.beta.kubernetes.io/<container_name>' is used to specify the AppArmor profile for a container. Option A is correct because it uses the proper prefix and container name placeholder.

These components are critical for securing Kubernetes clusters.

The 'condition' field in a Falco rule defines the syscall filter expression that triggers the alert.

Option D (secretbox) is correct because it is a valid encryption provider for etcd data at rest in Kubernetes, using XSalsa20 and Poly1305 for authenticated encryption. It is one of the supported providers alongside aescbc, and is specifically designed for encryption at rest within etcd.

Setting `--insecure-port=0` disables the unencrypted HTTP port (default 8080), which eliminates the risk of unauthenticated access to the API server. Ensuring `--secure-port=6443` is configured enforces TLS-encrypted communication on the standard secure port, which is the only recommended and secure method for production clusters.

The 'readOnlyRootFilesystem' field, when true, mounts the container's root filesystem as read-only, preventing writes.

The Privileged Pod Security Standard (PSS) level is the most permissive, allowing unrestricted access to host-level resources, including hostNetwork, hostPID, and hostIPC. These settings grant the pod direct access to the host's network namespace, process table, and inter-process communication mechanisms, which are explicitly prohibited in the Baseline and Restricted levels. The Privileged level is designed for system-level workloads that require such elevated permissions, such as CNI plugins or monitoring agents.

Option A is correct because the `--anonymous-auth` flag on the kube-apiserver binary controls whether anonymous requests are allowed. Running `ps aux | grep kube-apiserver | grep anonymous-auth` directly inspects the running process arguments to see if the flag is set to `true` (enabled) or `false` (disabled). This is the most direct way to check the runtime configuration of the API server.

Option C is correct because the Kubernetes upgrade process mandates upgrading the control plane first, as it is the authoritative source for cluster state and API operations. Worker nodes can then be upgraded to match the control plane version, ensuring compatibility and minimizing downtime by allowing workloads to continue running during the node upgrade phase.

AppArmor has three modes: enforce (profiles are enforced), complain (violations are logged but not blocked), and unconfined (no AppArmor). Options A and C are correct. 'audit' is not a mode; 'disable' is not a mode.

You should rebuild the image using updated base images that include security patches. Option C is correct.

Option A is correct because enabling audit logging in kube-apiserver requires both `--audit-log-path` to specify the output file and `--audit-policy-file` to define the audit policy rules. Without the policy file, the API server will not know which events to log, and without the log path, no audit logs will be written.

Option B is correct because `kube-bench` uses the `--targets` flag to specify which CIS benchmark targets to scan, and for control plane nodes, the correct target is `master` (not `controlplane`). This is because the CIS Kubernetes Benchmark historically refers to the control plane node as the 'master' node, and `kube-bench` follows that naming convention.

The kube-apiserver uses --encryption-provider-config to load the EncryptionConfiguration YAML file that defines how etcd data is encrypted.

The 'apparmor_parser' command is used to load AppArmor profiles into the kernel. Option A is correct. Options B, C, and D are not valid commands for loading AppArmor profiles.

The EncryptionConfiguration only encrypts newly created secrets. Existing secrets must be re-created (e.g., by replacing them) to be encrypted. The kube-apiserver does not automatically rewrite existing resources.

The correct resource is an EncryptionConfiguration object, which is a Kubernetes API resource that defines how to encrypt secrets at rest in etcd. It specifies providers (such as aesgcm, secretbox, or kms) and their order of precedence for encrypting and decrypting data. This configuration is passed to the kube-apiserver via the --encryption-provider-config flag.

Rebuilding the image with updated packages and fixes is the appropriate action to remediate the vulnerabilities found by the scan.

To capture both request and response for successful requests, you want events after the response is complete. The 'ResponseComplete' stage fires after the response is sent. 'RequestResponse' is not a stage; it's a level.

As of Kubernetes 1.29, the default seccomp profile for containers is RuntimeDefault, which uses the container runtime's default profile.

Option D is correct because in Kubernetes, the correct field to add a specific Linux capability to a container is `capabilities.add`, and the correct YAML key is `add`, not `cap_add`. The `cap_add` key is used in Docker Compose, not in Kubernetes pod or container security contexts. The `NET_ADMIN` capability allows the container to perform network administration tasks such as interface configuration, firewall management, and routing table manipulation.

allowPrivilegeEscalation: false directly prevents processes from gaining more privileges than their parent. Dropping all capabilities reduces attack surface but does not itself prevent privilege escalation. runAsNonRoot ensures the container does not run as root but does not prevent escalation if the container could still gain capabilities.

Option A is correct because the CIS Kubernetes Benchmark recommends enabling TLS for both client-to-server and peer communication in etcd to ensure data in transit is encrypted and authenticated. This prevents man-in-the-middle attacks and unauthorized access to the etcd cluster, which stores all cluster state and secrets.

Option A is correct because etcd supports mutual TLS (mTLS) authentication, which requires clients to present a valid TLS certificate signed by a trusted CA. By configuring etcd with `--client-cert-auth=true` and providing the API server's client certificate, you ensure that only the API server (or any client with a valid certificate) can communicate with etcd. This is the recommended Kubernetes approach to restrict access to etcd, as it cryptographically verifies the identity of the client.

Option A is correct because seccomp (secure computing mode) can filter system calls at the kernel level, and by configuring containerd to use a default seccomp profile that blocks syscalls related to unprivileged user namespaces (e.g., `clone` with `CLONE_NEWUSER`) and kernel module loading (e.g., `init_module`, `finit_module`), you prevent container escapes from performing privileged host operations. This approach is runtime-level, applies globally without modifying pod specs, and minimizes performance impact since seccomp uses a BPF-based filter that adds negligible overhead.

Kata Containers run inside a lightweight VM with its own kernel. Network configuration can be complex, and if the CNI plugin is not properly configured for Kata, the network may not be ready.

The ImagePolicyWebhook admission controller allows integration with external image verification services like Cosign to enforce image signing policies. The other options are not specifically for image signing.

Best practices for secrets include mounting as volumes (avoiding environment variables) and using external secret management solutions for enhanced security features.

To enable encryption of secrets at rest in Kubernetes, you must create an EncryptionConfiguration resource. This resource defines which encryption providers (e.g., AES-CBC, secretbox) to use and how to encrypt resources stored in etcd. The kube-apiserver reads this configuration via the --encryption-provider-config flag and applies it to all resources in the specified resource group, such as secrets.

The kube-bench test ID 1.2.1 checks the kube-apiserver configuration for the `--anonymous-auth` flag. The API server is a static pod managed by the kubelet, and its configuration is defined in the manifest file `/etc/kubernetes/manifests/kube-apiserver.yaml`. To fix the failure, you must edit this file to set `--anonymous-auth=false`.

Option B is correct because etcd supports mutual TLS (mTLS) authentication, where the client (e.g., kube-apiserver) presents a client certificate signed by the etcd CA. This ensures that only authenticated clients can communicate with etcd, effectively restricting access. Option C is correct because etcd has its own Role-Based Access Control (RBAC) system, which can be enabled to restrict read/write operations to specific users or roles, providing fine-grained access control.

NetworkPolicy must be created and applied, then tested by deploying pods and checking connectivity. The policy is enforced immediately.

Option A is correct because the kubelet's `--anonymous-auth` flag controls whether requests to the kubelet API that are not rejected by other authentication modules are treated as anonymous requests. Setting `--anonymous-auth=false` disables anonymous access, requiring all requests to present valid credentials. This directly addresses the kube-bench warning about anonymous authentication being enabled, which is a security concern as it allows unauthenticated access to the kubelet's API.

Option C is correct because etcd uses the Raft consensus protocol for distributed coordination, and enabling TLS with peer certificates ensures that all communication between etcd members (nodes) is encrypted and authenticated. This prevents man-in-the-middle attacks and unauthorized nodes from joining the cluster, which is a core security requirement for the control plane's data store.

Cosign sign is the correct command to sign an image. Option A is correct.

OPA/Gatekeeper, Kyverno, and ImagePolicyWebhook are all tools that can enforce image policies such as allowed registries, signatures, or other criteria.

The Pod Security Standards (PSS) define three policies: privileged, baseline, and restricted. The restricted policy enforces the most stringent security controls, including requiring a seccomp profile to be set to 'RuntimeDefault' or 'localhost/*'. Using the PodSecurity admission plugin with 'enforce' mode ensures that any pod failing the restricted policy is immediately rejected, guaranteeing that only compliant pods run in the namespace.

The NodeRestriction admission plugin ensures that kubelets can only modify Node and Pod objects that are bound to their own node. It enforces that a kubelet cannot update or delete pods it does not own, preventing a compromised or misconfigured kubelet from interfering with workloads on other nodes.

Options A, C, and D are recommended security practices. Option B increases attack surface, and option E is about monitoring, not reducing attack surface.

PSPs require enabling the admission controller, creating the policy, granting access via RBAC, and binding to subjects. Testing confirms enforcement.

The `--protect-kernel-defaults` flag is a kubelet option that, when set to `true`, enforces kernel tunable protections by checking that sysctl settings like `vm.overcommit_memory`, `vm.panic_on_oom`, and `kernel.panic` match the kubelet's expected safe defaults. This is a critical hardening measure to prevent container breakout scenarios where a compromised pod could weaken host kernel parameters.

Option A is correct because the `automountServiceAccountToken` field in a ServiceAccount manifest, when set to `false`, prevents pods using that ServiceAccount from automatically mounting the service account token as a volume. This is a security hardening measure to reduce the attack surface in case a pod is compromised, as the token could be used to authenticate to the Kubernetes API server.

An SBOM lists all software components in an artifact, enabling vulnerability tracking and compliance. Option B is correct.

The `apparmor_parser` command loads AppArmor profiles into the kernel. The `-r` flag replaces an existing profile with the one from the specified file, ensuring the kernel enforces the updated rules. This is the standard method to load or reload AppArmor profiles from a profile file.

The correct Rego policy checks that the container's securityContext has `seccompProfile.type: RuntimeDefault`. Option A does this correctly.

The --audit-policy-file flag tells the API server to use a specific audit policy file. The other options are incorrect: --audit-log-path is for the log file location, --audit-webhook-config-file is for webhook configuration, and --authorization-mode is for authorization.

The kubectl logs command fetches logs from a pod, but audit logs are stored on the API server. To view audit logs, you typically read the audit log file (e.g., /var/log/audit/audit.log on the master node) or use a log aggregation tool. kubectl get events shows Kubernetes events, not audit logs.

Option A is correct because the Kubernetes Dashboard should be accessed using a dedicated service account with minimal permissions via RBAC. This follows the principle of least privilege, ensuring the dashboard only has the permissions necessary for its function, reducing the attack surface. By default, the dashboard's service account has minimal permissions, but binding it to a role with excessive privileges (like cluster-admin) would be a security risk.

ResponseComplete is the stage after the response has been sent.

Setting `hostPID: true` allows the container to see all processes running on the host, which can leak sensitive information and enable process injection. Setting `hostNetwork: true` gives the container direct access to the host's network namespace, bypassing network policies and potentially allowing the container to bind to privileged ports or sniff traffic. Together, these settings significantly increase the attack surface and risk of privilege escalation or host compromise.

The ImagePolicyWebhook admission controller is specifically designed to verify image signatures and policies via an external webhook.

Option B is correct because mounting the Secret as a read-only volume prevents runtime modification, and using a dedicated service account with RBAC ensures only the specific microservice can access the Secret. This follows the principle of least privilege and minimizes exposure, as the credentials are never injected as environment variables (which can be leaked via /proc or logs) and are only available to the intended pod.

Istio’s sidecar injector is a mutating webhook that modifies pod specs to add the Envoy proxy sidecar.

Cosign sign with --key env://[VAR] reads the key from an environment variable.

The `--anonymous-auth=false` flag explicitly disables anonymous authentication on the Kubernetes API server. When set to false, the API server will reject requests from unauthenticated users (those not presenting valid credentials), enforcing that all requests must be authenticated. This is a critical security hardening step to prevent anonymous access to the cluster's control plane.

To enable encryption at rest for Kubernetes secrets, you must create an EncryptionConfiguration resource. This object defines which encryption providers (e.g., aesgcm, aescbc, secretbox, or identity) should be used to encrypt secrets stored in etcd. The API server reads this configuration from a file specified via the --encryption-provider-config flag, allowing you to control encryption at the provider level.

SBOM is a Software Bill of Materials, a detailed list of components, dependencies, and metadata used in a software artifact.

Option D (aescbc) is correct because AES-CBC with a 256-bit key is the recommended and strongest encryption provider for encrypting secrets at rest in etcd, as specified in the Kubernetes documentation. It provides robust encryption using the Advanced Encryption Standard in Cipher Block Chaining mode, which is widely accepted for data-at-rest encryption in production environments.

Option C is correct because the Kubernetes Dashboard should be secured using Role-Based Access Control (RBAC) with minimal privileges. This follows the principle of least privilege, ensuring that users or service accounts accessing the Dashboard have only the permissions necessary for their tasks, reducing the attack surface and potential blast radius in case of compromise.

The image field in the container spec can include a digest after the tag, e.g., 'nginx@sha256:abc123...'. The other options are not related to image specification.