CKS System Hardening — Timed 15 Questions

Question 1

A cluster is running Kubernetes 1.24. The security team wants to enforce that all pods run with a read-only root filesystem. Which approach is most effective?

Accepted Answer

Enable PodSecurity admission controller with restricted profile. In Kubernetes 1.24, PodSecurityPolicy (PSP) is deprecated but still functional. The PodSecurity admission controller with the restricted profile is the built-in, forward-looking 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, whereas PSP will be removed in 1.25 and is no longer the recommended approach.

Answer

Use OPA Gatekeeper to deny pods without readOnlyRootFilesystem

Answer

Enable PodSecurityPolicy with readOnlyRootFilesystem: true

Answer

Set --read-only-port=0 in kubelet

Question 2

A developer wants to run a container that needs to modify kernel parameters. What is the secure way to achieve this?

Accepted Answer

Use `sysctls` in the Pod's `securityContext` for safe sysctls like `net.ipv4.tcp_syncookies`. Kubernetes provides a secure mechanism to modify kernel parameters via the `sysctls` field in the Pod's `securityContext`. This approach allows specific sysctls (e.g., `net.ipv4.tcp_syncookies`) to be set without granting full privileged access or dangerous capabilities. Safe sysctls can be set directly; unsafe sysctls must be explicitly enabled by the cluster administrator using the kubelet `allowedUnsafeSysctls` option.

Answer

Run the container with privileged: true

Answer

Add SYS_ADMIN capability to the container

Answer

Modify kubelet's --sysctl-whitelist to include the needed sysctl

Question 3

You are a security engineer for a large e-commerce company. The Kubernetes cluster runs on-premises and hosts critical payment processing applications. Recently, a security scan revealed that several pods are running with privileged escalation enabled, and some have a writable root filesystem. The cluster uses Kubernetes v1.26 with PodSecurity admission controller enabled but currently set to 'privileged' profile for all namespaces. The development teams require flexibility for some legacy applications that need to run with hostNetwork or hostPID. However, the security team wants to enforce a restricted profile for most namespaces while allowing exceptions. The CISO has mandated that no pod should run as root, and all pods must have read-only root filesystem and privilege escalation disabled. Additionally, any pod that requires hostNetwork or hostPID must be explicitly approved and placed in a separate namespace. You need to design a solution that meets these requirements with minimal operational overhead. What is the best course of action?

Accepted Answer

Use PodSecurity admission with 'restricted' profile for most namespaces by labeling them with 'pod-security.kubernetes.io/enforce=restricted', and create a separate namespace with 'baseline' profile for legacy apps that require hostNetwork/hostPID, after reviewing and approving each exception. 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.

Answer

Deploy OPA Gatekeeper and create constraints to enforce read-only root filesystem, no privilege escalation, and non-root user, with exceptions via label selectors

Answer

Keep the current 'privileged' profile and rely on runtime security tools like Falco to detect violations

Answer

Change the PodSecurity profile to 'restricted' cluster-wide and require all legacy apps to be rewritten to not need hostNetwork/hostPID

Question 4

A security engineer is hardening a Kubernetes node and wants to ensure that kubelet does not accept requests from unauthorized sources. Which kubelet configuration change should be made?

Accepted Answer

Set --anonymous-auth=false. Setting `--anonymous-auth=false` on the kubelet disables anonymous requests, meaning the kubelet will reject any request that does not present valid authentication credentials. This is a critical hardening measure to ensure only authenticated and authorized sources (e.g., the API server) can interact with the kubelet’s HTTPS API, preventing unauthorized nodes or attackers from querying or modifying pod/container state.

Answer

Set --anonymous-auth=true

Answer

Set --read-only-port=10255

Answer

Set --authentication-token-webhook=false

Question 5

During a security audit, it is found that containers running in a cluster have CAP_NET_RAW capability by default. The team wants to drop this capability for all containers. Which approach should be taken?

Accepted Answer

Use a mutating admission webhook to add a finalizer that drops capabilities. A mutating admission webhook can intercept Pod creation requests and modify the security context to drop capabilities like NET_RAW for all containers. This approach enforces the policy cluster-wide without requiring manual changes to each deployment, making it a viable alternative to deprecated PodSecurityPolicy.

Answer

Create a PodSecurityPolicy with requiredDropCapabilities: [NET_RAW] and assign it to a role binding

Answer

Configure kubelet with --allowed-unsafe-sysctls to restrict capabilities

Answer

Modify each deployment to include securityContext.capabilities.drop: [NET_RAW]

Question 6

Refer to the exhibit. The pod fails to start with the error 'container has runAsNonRoot but image will run as root'. Which change would fix the issue?

Accepted Answer

Set runAsNonRoot: false. 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.

Answer

Change runAsUser to 0

Answer

Use a different image that runs as non-root

Answer

Add NET_ADMIN capability

Question 7

A security team wants to ensure that no pod runs with privileged access. They have created a PodSecurityPolicy (PSP) that sets 'privileged: false'. However, a pod with privileged: true still gets created. What is the most likely cause?

Accepted Answer

The user creating the pod does not have a RoleBinding that grants use of the PSP. A is correct because PodSecurityPolicy (PSP) requires the user or service account creating the pod to have a RoleBinding or ClusterRoleBinding that grants the `use` verb on the PSP resource. Without this RBAC authorization, the PSP is not enforced for that user, even if the PSP exists and the admission controller is enabled. The pod with `privileged: true` bypasses the PSP because the creating identity lacks the necessary RBAC permissions to trigger the PSP's validation.

Answer

The pod has a higher priority than the PSP

Answer

The PodSecurityPolicy admission controller is not enabled

Answer

The PodSecurityPolicy is defined after the pod creation

Question 8

A security policy requires that containers should drop all capabilities and only add back the specific capabilities needed. Which YAML snippet correctly implements this for a container?

Accepted Answer

securityContext:
  capabilities:
    drop: ["ALL"]
    add: ["NET_BIND_SERVICE"]. It first drops all capabilities with `drop: ["ALL"]` and then adds back only the specific capability needed (`NET_BIND_SERVICE`). In Kubernetes, the `add` and `drop` fields are processed sequentially: `add` is applied to the default capabilities first, then `drop` removes capabilities. Therefore, if you add before dropping all, as in option D, the added capability is also dropped, resulting in an empty set. The order matters, and only the drop-first-then-add sequence achieves the intended final set of capabilities.

Answer

securityContext:
  capabilities:
    drop: ["ALL"]
    add: ["ALL"]

Answer

securityContext:
  capabilities:
    drop: ["CHOWN","DAC_OVERRIDE"]

Answer

securityContext:
  capabilities:
    add: ["NET_BIND_SERVICE"]
    drop: ["ALL"]

Question 9

You need to apply a Pod Security Standard that prevents containers from running as root and disallows privileged escalation. Which TWO levels enforce these requirements?

Accepted Answer

restricted. The Pod Security Standards (PSS) define three profiles: privileged, baseline, and restricted. The baseline profile disallows privileged escalation by requiring allowPrivilegeEscalation to be false. The restricted profile includes all baseline restrictions and additionally prevents containers from running as root by requiring runAsNonRoot to be true. Thus, baseline enforces the privilege escalation requirement, and restricted enforces both the privilege escalation and root prevention requirements. Consequently, both baseline and restricted are considered to enforce the stated requirements.

Answer

baseline

Answer

privileged

Answer

default

Answer

unrestricted

Question 10

A security engineer needs to apply a custom AppArmor profile to a pod. The profile is named 'k8s-apparmor-example-deny-write' and is loaded on the node. Which annotation should be added to the pod's metadata to enforce this profile?

Accepted Answer

container.apparmor.security.beta.kubernetes.io/container-name: "localhost/k8s-apparmor-example-deny-write". The AppArmor annotation for a container follows the format `container.apparmor.security.beta.kubernetes.io/<container-name>` and the profile name must be prefixed with `localhost/` when referencing a profile loaded on the node. The annotation value `"localhost/k8s-apparmor-example-deny-write"` correctly specifies the node-local profile.

Answer

apparmor.security.beta.kubernetes.io/container-name: "k8s-apparmor-example-deny-write"

Answer

container.apparmor.security.beta.kubernetes.io/pod-name: "k8s-apparmor-example-deny-write"

Answer

container.apparmor.security.beta.kubernetes.io/container-name: "k8s-apparmor-example-deny-write"

Question 11

Which kubectl command is used to check the AppArmor status on a Kubernetes node?

Accepted Answer

kubectl node-shell <node> -- aa-status. `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.

Answer

kubectl describe node <node> | grep AppArmor

Answer

kubectl get apparmor

Answer

kubectl exec <pod> -- aa-status

Question 12

Which Linux capability should be dropped to prevent a container from gaining new privileges via setuid binaries?

Accepted Answer

CAP_SETUID. CAP_SETUID (option C) is the Linux capability that controls whether a process can make arbitrary changes to process UIDs (setuid/setgid). Dropping this capability prevents a container from using setuid binaries (e.g., `su`, `sudo`) to escalate privileges, because the kernel will deny any attempt to change the effective UID. This directly addresses the requirement to prevent gaining new privileges via setuid binaries.

Answer

CAP_NET_RAW

Answer

CAP_DAC_OVERRIDE

Answer

CAP_SYS_ADMIN

Question 13

Which of the following is the correct way to drop all capabilities from a container in a pod specification?

Accepted Answer

securityContext:
  capabilities:
    drop: ALL. In Kubernetes, to drop all capabilities from a container, you must set `capabilities.drop` to `ALL` under the `securityContext`. The `capabilities` field is a standard part of the container's security context, and `drop` is the correct key to specify capabilities to remove. Using `ALL` (uppercase) ensures all capabilities defined by the Linux kernel (e.g., CAP_NET_RAW, CAP_SYS_ADMIN) are dropped, which is a best practice for minimizing privilege escalation risks.

Answer

securityContext:
  dropCapabilities: ALL

Answer

securityContext:
  capabilities:
    drop: ["all"]

Answer

securityContext:
  capabilities:
    remove: ALL

Question 14

A cluster has PodSecurity admission enabled. A developer creates a pod with the following security context: 'securityContext: { capabilities: { drop: ["ALL"], add: ["NET_ADMIN"] } }'. The namespace is labeled 'pod-security.kubernetes.io/enforce: baseline'. Will the pod be allowed?

Accepted Answer

Yes, because the baseline policy allows adding NET_ADMIN. 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.

Answer

No, because baseline requires dropping ALL first

Answer

Yes, because the pod drops all capabilities before adding specific ones

Answer

No, because dropping ALL capabilities is not allowed by baseline

Question 15

A pod is in a Pending state with the event: 'failed to generate spec: failed to validate seccomp profile: seccomp profile not found'. The profile is stored at /var/lib/kubelet/seccomp/custom.json on the node. Which of the following is the MOST likely cause?

Accepted Answer

The localhostProfile field contains an absolute path instead of a relative one. The error 'seccomp profile not found' indicates the kubelet cannot locate the profile file. In Kubernetes, when using a seccomp profile stored on the node, the `localhostProfile` field must specify a relative path from the kubelet's seccomp root directory (default `/var/lib/kubelet/seccomp`). An absolute path like `/var/lib/kubelet/seccomp/custom.json` causes the kubelet to look for the file at that exact absolute path, but the seccomp validation logic expects a relative path and prepends the root, leading to a 'not found' error.

Answer

The profile name is misspelled in the pod specification

Answer

The node does not have seccomp enabled in the kubelet

Answer

The seccomp profile JSON is malformed