CKS System Hardening Practice Test 7 — 15 Questions

Question 1

Which command loads an AppArmor profile into the kernel?

Accepted Answer

apparmor_parser -r /path/to/profile. The `apparmor_parser` command is the standard tool for loading AppArmor profiles into the Linux kernel. The `-r` flag (replace) loads or reloads the specified profile file, merging it into the kernel's security policy. This is the correct method because AppArmor profiles are text files that must be parsed and loaded by the kernel's LSM (Linux Security Module) subsystem via this utility.

Answer

apparmor_load /path/to/profile

Answer

aa-load /path/to/profile

Answer

aa-status /path/to/profile

Question 2

A pod is created with the following security context:
securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: profiles/audit.json
Where must the 'audit.json' file be placed on the node?

Accepted Answer

/var/lib/kubelet/seccomp/profiles/audit.json. When a pod uses a `seccompProfile` of type `Localhost` with `localhostProfile: profiles/audit.json`, the file path is relative to the kubelet's seccomp root directory, which defaults to `/var/lib/kubelet/seccomp`. Therefore, the complete path on the node must be `/var/lib/kubelet/seccomp/profiles/audit.json`. This is the only location where the kubelet will look for the seccomp profile when `type: Localhost` is specified.

Answer

/etc/kubernetes/seccomp/profiles/audit.json

Answer

/var/lib/kubelet/audit.json

Answer

/var/lib/containerd/seccomp/audit.json

Question 3

A container runs as non-root and needs to perform operations that require CAP_SYS_PTRACE. Which YAML snippet correctly adds only this capability while following the principle of least privilege?

Accepted Answer

securityContext:
  capabilities:
    drop: ['ALL']
    add: ['SYS_PTRACE']. It first drops all capabilities with `drop: ['ALL']` and then explicitly adds only `SYS_PTRACE`, ensuring the container runs with the minimum privileges required. This follows the principle of least privilege by removing any inherited or default capabilities before granting only the needed one. In Kubernetes, capabilities are Linux kernel capabilities; dropping all and adding only what is necessary is the recommended security practice.

Answer

securityContext:
  capabilities:
    add: ['SYS_PTRACE']

Answer

securityContext:
  capabilities:
    drop: ['ALL']

Answer

securityContext:
  privileged: true

Question 4

Which Pod Security Standard level allows the use of hostNetwork, hostPID, and hostIPC?

Accepted Answer

Privileged. 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.

Answer

None of the above

Answer

Baseline

Answer

Restricted

Question 5

An administrator runs 'kubectl run test-pod --image=nginx --dry-run=client -o yaml > pod.yaml', then adds 'hostPID: true' and 'hostNetwork: true' to the pod's spec. After applying with 'kubectl apply -f pod.yaml', the pod is created but immediately goes into 'CrashLoopBackOff'. What is the likely cause?

Accepted Answer

The pod lacks the necessary Linux capabilities. The pod is created because hostPID and hostNetwork are allowed by default. nginx has CAP_NET_BIND_SERVICE by default, so it can bind to port 80. CrashLoopBackOff is likely due to port 80 already in use on the host or another runtime issue.

Answer

The container is missing a memory limit and gets OOMKilled

Answer

The namespace has a PodSecurity enforce level that restricts hostPID and hostNetwork

Answer

The 'hostPID' and 'hostNetwork' fields cannot be combined

Question 6

Which of the following is the correct way to disable swap on a Kubernetes node to improve security?

Accepted Answer

Run 'swapoff -a' and remove swap entry from /etc/fstab. 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.

Answer

Set kernel parameter 'vm.swappiness=0'

Answer

Run 'systemctl stop swap'

Answer

Run 'kubelet --disable-swap'

Question 7

A custom seccomp profile is created at /var/lib/kubelet/seccomp/custom-profile.json. Which YAML snippet applies this profile to a container?

Accepted Answer

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: custom-profile.json. When using a custom seccomp profile stored on the node, the `type: Localhost` field must be set, and the `localhostProfile` field specifies the filename (relative to the kubelet's seccomp root directory, which defaults to `/var/lib/kubelet/seccomp`). This configuration tells the container runtime to load the profile from the node's filesystem at the path `/var/lib/kubelet/seccomp/custom-profile.json`.

Answer

securityContext:
  seccompProfile:
    type: Unconfined

Answer

securityContext:
  seccompProfile:
    type: RuntimeDefault
    localhostProfile: custom-profile.json

Answer

securityContext:
  seccomp:
    profile: custom-profile.json

Question 8

An admin wants to check which AppArmor profiles are loaded. Which command should they run?

Accepted Answer

aa-status. The `aa-status` command is the standard tool for displaying the status of AppArmor, including which profiles are loaded, their enforcement mode (enforce/complain), and process confinement. It queries the AppArmor security module directly via the kernel interface, making it the correct and most comprehensive command for this task.

Answer

apparmor list

Answer

seccomp-status

Answer

ls /sys/kernel/security/apparmor/profiles

Question 9

Which THREE of the following are best practices for reducing the attack surface of a Kubernetes node?

Accepted Answer

Run containers with non-root user and drop all capabilities. Running containers with a non-root user (via `securityContext.runAsNonRoot: true` or `runAsUser`) and dropping all capabilities (via `securityContext.capabilities.drop: ['ALL']`) enforces the principle of least privilege. This prevents attackers who compromise the container from gaining root privileges or using kernel capabilities like `CAP_SYS_ADMIN` to escape the container, directly reducing the node's attack surface.

Answer

Install all available security patches and packages

Answer

Remove SSH access from all nodes

Question 10

Which command is used to load an AppArmor profile into the kernel?

Accepted Answer

apparmor_parser. The `apparmor_parser` command is used to load AppArmor profiles into the kernel by parsing the profile file and adding it to the kernel's security module. This is the standard utility for loading, reloading, and removing AppArmor profiles, making option B correct.

Answer

aa-status

Answer

aa-load

Answer

aa-enforce

Question 11

A pod spec includes the following securityContext:

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: custom-profile.json

Where should the custom seccomp profile 'custom-profile.json' be placed on the node?

Accepted Answer

/var/lib/kubelet/seccomp/. When a pod's securityContext specifies a seccomp profile of type Localhost, the custom profile file must be placed on the node's filesystem under the default seccomp profile directory used by kubelet, which is /var/lib/kubelet/seccomp/. The kubelet reads profiles from this directory, and the localhostProfile field (e.g., custom-profile.json) is resolved relative to this path. Option D is correct because it matches the default kubelet seccomp profile path.

Answer

/etc/seccomp/

Answer

/etc/kubernetes/seccomp/

Answer

/var/lib/kubelet/seccomp/profiles/

Question 12

A cluster administrator wants to prevent all containers in a namespace from running with the NET_RAW capability. They plan to use a PodSecurityPolicy (PSP) but PSP is deprecated. Which approach should they use instead?

Accepted Answer

Apply a PodSecurity admission label with 'pod-security.kubernetes.io/enforce: baseline'. The 'baseline' PodSecurity standard enforces the minimum restrictions that prevent privilege escalation, including dropping the NET_RAW capability by default. The 'baseline' profile is designed to be applied to namespaces where most workloads run, and it automatically adds NET_RAW to the required drop capabilities list, which directly addresses the administrator's goal without the overhead of the more restrictive 'restricted' profile.

Answer

Apply a PodSecurity admission label with 'pod-security.kubernetes.io/enforce: privileged'

Answer

Apply a PodSecurity admission label with 'pod-security.kubernetes.io/enforce: restricted'

Answer

Use a PodSecurityPolicy with 'requiredDropCapabilities: [NET_RAW]'

Question 13

A container is running with the following securityContext:

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

Which capabilities will the container have?

Accepted Answer

Only NET_BIND_SERVICE. The securityContext first drops all capabilities with `drop: ["ALL"]`, which removes every capability from the container's bounding set. Then `add: ["NET_BIND_SERVICE"]` adds back only that single capability. Therefore, the final effective set is exactly `NET_BIND_SERVICE`, making option B correct.

Answer

All capabilities except NET_BIND_SERVICE

Answer

No capabilities

Answer

All default capabilities plus NET_BIND_SERVICE

Question 14

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 15

A security auditor reports that a container can sniff network traffic on the host. Which field in the pod spec should be checked and set to false to prevent this?

Accepted Answer

hostNetwork: false. Setting `hostNetwork: true` in the pod spec allows the container to share the host's network namespace, enabling it to bind to host ports and, critically, to sniff all network traffic on the host network interface (e.g., using `tcpdump` or raw sockets). Setting `hostNetwork: false` (the default) isolates the container in its own network namespace, preventing it from accessing host-level network traffic. This is a fundamental Kubernetes security control to enforce network isolation.

Answer

hostNetwork: true

Answer

hostIPC: true

Answer

hostPID: true