CKS System Hardening Practice Test 9 — 15 Questions

Question 1

To reduce the attack surface, a security best practice is to drop all capabilities from a container and add only those required. Which securityContext field is used to drop all capabilities?

Accepted Answer

capabilities.drop: ["ALL"]. In Kubernetes, the `capabilities.drop` field in the securityContext is used to explicitly remove Linux capabilities from a container. Setting `capabilities.drop: ["ALL"]` drops all capabilities, effectively reducing the attack surface by ensuring the container starts with no privileges, and then specific capabilities can be added back via `capabilities.add` if needed.

Answer

capabilities.disable: ["ALL"]

Answer

capabilities.remove: ["ALL"]

Answer

privileged: false

Question 2

An administrator needs to enforce the restricted Pod Security Standard on a namespace 'secure-ns'. Which kubectl command should they use?

Accepted Answer

kubectl label namespace secure-ns pod-security.kubernetes.io/enforce=restricted. The Pod Security Standards (PSS) are enforced via labels on namespaces, using the key `pod-security.kubernetes.io/enforce` with the value `restricted`. This instructs the built-in Pod Security Admission controller to reject any pod that violates the restricted profile in the `secure-ns` namespace.

Answer

kubectl label namespace secure-ns security=restricted

Answer

kubectl create podsecuritypolicy restricted -n secure-ns

Answer

kubectl annotate namespace secure-ns pod-security.kubernetes.io/enforce=restricted

Question 3

Which of the following seccomp profile types should be used to apply the container runtime's default seccomp profile?

Accepted Answer

RuntimeDefault. The `RuntimeDefault` seccomp profile type instructs the container runtime (e.g., containerd, CRI-O) to apply its own built-in default seccomp profile. This profile is defined by the runtime and typically blocks around 44 system calls that are considered dangerous or unnecessary for containers, providing a secure baseline without requiring a custom profile.

Answer

Unconfined

Answer

Default

Answer

Localhost

Question 4

A pod is running with securityContext.seccompProfile.type: Unconfined. Which statement is true?

Accepted Answer

The container can make any system call.. When `securityContext.seccompProfile.type` is set to `Unconfined`, the container is allowed to make any system call without restriction. Seccomp (secure computing mode) is a Linux kernel feature that filters syscalls; `Unconfined` explicitly disables this filter, granting the container full syscall access. This is the most permissive seccomp profile and is the default if no profile is specified in older Kubernetes versions.

Answer

The container is limited to a set of allowed syscalls as defined by the runtime.

Answer

Seccomp is not supported on this node.

Answer

The container is running with the host's seccomp profile.

Question 5

An AppArmor profile is loaded in 'complain' mode. What happens when a pod with that profile attempts an action that violates the profile?

Accepted Answer

The action is allowed but a log entry is created.. In AppArmor, 'complain' mode (also known as 'learning' mode) allows all actions, including those that violate the profile, but logs the violation to the system audit log (typically via auditd or syslog). This is distinct from 'enforce' mode, which blocks violating actions. Therefore, when a pod runs with a profile in complain mode, prohibited actions are permitted and recorded.

Answer

The pod is terminated.

Answer

The action is allowed and no log is generated.

Answer

The action is blocked and an audit log is generated.

Question 6

Which of the following is NOT a recommended method to reduce the attack surface on Kubernetes nodes?

Accepted Answer

Running containers with privileged: true. Setting `privileged: true` in a container's security context grants it elevated capabilities equivalent to running as root on the host, including access to all kernel namespaces and devices. This directly increases the attack surface by allowing the container to perform host-level operations, such as loading kernel modules or modifying network settings, which violates the principle of least privilege. The CKS exam emphasizes that privileged containers should be avoided unless absolutely necessary, and they are never a recommended method for reducing the attack surface.

Answer

Using read-only root filesystems

Answer

Running containers as non-root

Answer

Disabling unnecessary system services on nodes

Question 7

Which TWO of the following are valid methods to apply a seccomp profile to a container? (Select 2 correct answers)

Accepted Answer

Using the seccomp.security.alpha.kubernetes.io/pod annotation. The `seccomp.security.alpha.kubernetes.io/pod` annotation was the original method to apply a seccomp profile to a pod in Kubernetes versions prior to v1.19. This annotation allows you to specify a seccomp profile path (e.g., 'localhost/my-profile') or a runtime default ('runtime/default') directly on the pod, which then applies to all containers in the pod. Option E is correct because `securityContext.seccompProfile.type` is the current, stable API field (GA since v1.19) that sets the seccomp profile at the container or pod level, accepting values like 'RuntimeDefault', 'Localhost', or 'Unconfined'.

Answer

Setting securityContext.seLinuxOptions.type

Answer

Using the container.apparmor.security.beta.kubernetes.io annotation

Answer

Using the seccomp.security.beta.kubernetes.io/pod annotation

Question 8

Which THREE of the following actions help reduce the attack surface of containers? (Select 3 correct answers)

Accepted Answer

Set securityContext.runAsNonRoot: true. Setting `securityContext.runAsNonRoot: true` forces the container to run with a user ID that is not 0 (root). This prevents an attacker who gains code execution inside the container from having root privileges, which would otherwise allow them to escape the container, modify system binaries, or perform privileged operations. It is a fundamental principle of least privilege and directly reduces the attack surface by limiting the damage a compromised container can do.

Answer

Set hostNetwork: true for better network performance

Answer

Enable audit logging for all API requests

Question 9

Which TWO of the following are valid AppArmor profile modes? (Select 2 correct answers)

Accepted Answer

enforce. AppArmor profile modes determine how the Mandatory Access Control (MAC) policy is applied. 'Enforce' (option A) actively enforces the profile's rules, blocking any actions that violate the policy and logging the denial. 'Complain' (option E) logs policy violations without blocking them, allowing for testing and debugging of profiles before switching to enforce mode.

Answer

disabled

Answer

audit

Answer

unconfined

Question 10

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

Accepted Answer

Increase the memory limit in the pod's container resource specification. The pod is in CrashLoopBackOff due to OOMKilled, meaning the container is being terminated by the Linux kernel's Out-Of-Memory (OOM) killer because it exceeds its memory limit. Increasing the memory limit in the container's resource specification allows the container to allocate more memory without being killed, directly addressing the root cause.

Answer

Delete the namespace and redeploy all workloads

Answer

Delete and recreate the pod to clear the crash loop

Answer

Increase the CPU request for the container

Question 11

Which annotation is used to apply an AppArmor profile to a pod in Kubernetes?

Accepted Answer

container.apparmor.security.beta.kubernetes.io/. The annotation `container.apparmor.security.beta.kubernetes.io/` is the standard annotation used to apply an AppArmor profile to a specific container within a pod. The `` placeholder must be replaced with the actual container name, and the annotation value specifies the profile (e.g., `localhost/profile-name` or `runtime/default`). This annotation is in the `security.beta.kubernetes.io` API group, reflecting its beta status in Kubernetes.

Answer

seccomp.security.alpha.kubernetes.io/pod

Answer

apparmor.security.beta.kubernetes.io/profile

Answer

container.apparmor.kubernetes.io/<container_name>

Question 12

An administrator creates a custom seccomp profile and wants to apply it to a pod. The profile file is named 'audit.json' and is placed in the default seccomp directory on the node. Which securityContext field should be used?

Accepted Answer

securityContext.seccompProfile.type: Localhost and securityContext.seccompProfile.localhostProfile: audit.json. In Kubernetes, when using a custom seccomp profile stored on the node's default seccomp directory, the `securityContext.seccompProfile.type` must be set to `Localhost` and the profile filename is specified via the `localhostProfile` field. This field expects the filename (e.g., `audit.json`) relative to the node's default seccomp path (`/var/lib/kubelet/seccomp`). The `type: Localhost` instructs kubelet to load the profile from the node's filesystem.

Answer

securityContext.seccompProfile.type: Localhost and securityContext.seccompProfile.file: audit.json

Answer

securityContext.seccompProfile.type: Localhost and securityContext.seccompProfile.profile: audit.json

Answer

seccomp.security.alpha.kubernetes.io/pod: localhost/audit.json

Question 13

A security team wants to enforce that no container in the 'restricted' namespace runs with added Linux capabilities beyond the default set (according to the restricted Pod Security Standard). Which PodSecurityConfiguration should be applied to the namespace?

Accepted Answer

apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
  enforce: "restricted"
  enforce-version: "latest". The 'restricted' Pod Security Standard (PSS) is the most stringent profile, which enforces that no container runs with added Linux capabilities beyond the default set (e.g., dropping all capabilities except those required by the runtime). The 'enforce' mode blocks non-compliant pods from being created, and 'enforce-version: latest' applies the most current version of the restricted profile, ensuring that any new restrictions are automatically enforced.

Answer

apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
  warn: "restricted"
  warn-version: "latest"

Answer

apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
  enforce: "privileged"
  enforce-version: "latest"

Answer

apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
  enforce: "baseline"
  enforce-version: "latest"

Question 14

You need to apply a seccomp profile to all containers in a pod. The profile is named 'custom-profile.json' and is stored on each node at /var/lib/kubelet/seccomp/. Complete the following YAML snippet:

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: ???
```
What should replace ???

Accepted Answer

custom-profile.json. When using a seccomp profile of type Localhost in Kubernetes, the `localhostProfile` field must specify only the filename of the profile (e.g., `custom-profile.json`). The kubelet automatically prepends the default seccomp profile path (`/var/lib/kubelet/seccomp/`) to the filename, so providing the full path would be incorrect.

Answer

localhost/custom-profile.json

Answer

profile: custom-profile.json

Answer

/var/lib/kubelet/seccomp/custom-profile.json

Question 15

An administrator wants to ensure that containers in a pod cannot run with any Linux capabilities except the minimal required for the container runtime. The pod is subject to the 'restricted' Pod Security Standard. Which capability configuration should be set in the pod's security context?

Accepted Answer

capabilities:
  drop: ["ALL"]. 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.

Answer

capabilities:
  drop: ["NET_RAW", "CHOWN"]

Answer

capabilities:
  add: ["NET_BIND_SERVICE"]

Answer

capabilities:
  add: ["ALL"]