CKS System Hardening Practice Test 3 — 15 Questions

Question 1

Which annotation is used to apply an AppArmor profile named 'custom-profile' to a container named 'app' in a pod?

Accepted Answer

container.apparmor.security.beta.kubernetes.io/app: localhost/custom-profile. The annotation for applying an AppArmor profile to a specific container in a pod follows the format `container.apparmor.security.beta.kubernetes.io/: localhost/`. This annotation targets the container named 'app' with the profile 'custom-profile', which is loaded locally on the node.

Answer

apparmor.security.beta.kubernetes.io/container.app: localhost/custom-profile

Answer

security.beta.kubernetes.io/apparmor: localhost/custom-profile

Answer

pod.apparmor.security.beta.kubernetes.io/app: localhost/custom-profile

Question 2

You are creating a custom seccomp profile for a container that runs a binary requiring the 'write' syscall only. You place the profile JSON file at '/var/lib/kubelet/seccomp/profiles/write-only.json'. In the pod spec, which seccomp configuration correctly uses this profile?

Accepted Answer

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: profiles/write-only.json. When using a custom seccomp profile with type 'Localhost', the 'localhostProfile' field must specify a path relative to the kubelet's seccomp root directory (default: /var/lib/kubelet/seccomp). The path 'profiles/write-only.json' is relative and resolves to /var/lib/kubelet/seccomp/profiles/write-only.json, matching the file location. The 'type' field must be 'Localhost' to reference a local profile file.

Answer

securityContext:
  seccompProfile:
    type: RuntimeDefault
    localhostProfile: profiles/write-only.json

Answer

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: /var/lib/kubelet/seccomp/profiles/write-only.json

Answer

securityContext:
  seccompProfile:
    type: Localhost
    profile: write-only.json

Question 3

Which Linux capability must be added to a container to allow it to change the system time (e.g., using the 'date' command)?

Accepted Answer

CAP_SYS_TIME. The `CAP_SYS_TIME` capability is specifically required for a container to modify the system clock, including using the `date` command to set the time. Without this capability, the container's process will receive an EPERM error when attempting to change the system time, as the kernel enforces this restriction at the system call level (e.g., `settimeofday`, `clock_settime`).

Answer

CAP_SYS_NICE

Answer

CAP_SYS_RESOURCE

Answer

CAP_SYS_ADMIN

Question 4

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 5

A pod is scheduled on a node that has the AppArmor profile 'my-profile' loaded in complain mode. The pod annotation specifies 'localhost/my-profile' but the container is running without the profile being enforced. What is the most likely cause?

Accepted Answer

The profile is in complain mode, not enforce mode. AppArmor profiles can operate in either 'enforce' or 'complain' mode. When a profile is loaded in complain mode, violations are logged but not blocked, so the container runs without enforcement. The pod annotation 'localhost/my-profile' correctly references the profile, but the profile itself is not set to enforce mode, which is why the container is running without the profile being enforced.

Answer

The pod must run as privileged to use AppArmor

Answer

The annotation is missing the 'localhost/' prefix

Answer

The profile is not loaded on the node

Question 6

Which of the following is correct about dropping the 'NET_RAW' capability?

Accepted Answer

It prevents the container from creating raw sockets, which can be used for packet crafting attacks. The `NET_RAW` capability controls access to raw and packet sockets (AF_PACKET, SOCK_RAW). Dropping it prevents the container from creating raw sockets, which are often used for crafting custom packets, performing ARP spoofing, or launching other network-layer attacks. This is a key hardening measure to reduce the container's ability to manipulate network traffic at the low level.

Answer

It prevents the container from binding to a privileged port (<1024)

Answer

It prevents the container from using the 'ping' command

Answer

It prevents the container from making any network connections

Question 7

What is the default seccomp profile applied when a pod's security context has 'seccompProfile.type: RuntimeDefault'?

Accepted Answer

The container runtime's default seccomp profile, which blocks around 40 syscalls. When `seccompProfile.type: RuntimeDefault` is set in a pod's security context, the container runtime (e.g., containerd or CRI-O) applies its own default seccomp profile. This runtime default profile is a curated allowlist that blocks approximately 40 syscalls known to be dangerous or unnecessary for containers, providing a balance between security and compatibility. It is not the Docker default (which blocks ~300 syscalls) but a more permissive profile tailored to the runtime's container model.

Answer

The profile defined in /var/lib/kubelet/seccomp/default.json

Answer

Unconfined (no seccomp)

Answer

The Docker default profile, which blocks around 300 syscalls

Question 8

A pod spec includes 'hostPID: true' and 'hostNetwork: true'. What security concern does this raise?

Accepted Answer

The container can see all host processes and access the host network namespace, increasing the risk of privilege escalation. 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.

Answer

The container can use the host's GPU and other devices

Answer

The container can read and write to the host filesystem

Answer

The container cannot use a securityContext

Question 9

Which of the following is NOT a valid seccomp profile type in Kubernetes?

Accepted Answer

SeccompDefault. SeccompDefault is not a valid seccomp profile type in Kubernetes. The valid profile types are Unconfined, RuntimeDefault, and Localhost. SeccompDefault is a feature gate (introduced in Kubernetes 1.22) that, when enabled, tells the kubelet to use the RuntimeDefault seccomp profile by default for pods, but it is not itself a profile type.

Answer

Unconfined

Answer

RuntimeDefault

Answer

Localhost

Question 10

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 11

A security auditor recommends limiting the use of host namespaces in pods. Which THREE of the following fields, if set to true, expose the host namespace to a container?

Accepted Answer

hostPID. Setting `hostPID: true` in a Pod spec allows the container to share the host's process ID namespace. This means the container can see and interact with all processes running on the host node, which breaks process isolation and can lead to privilege escalation or information leakage.

Answer

hostFS

Answer

hostUsers

Question 12

Which TWO of the following are valid modes for an AppArmor profile?

Accepted Answer

complain. AppArmor profiles operate in two primary 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 and refine profiles. In enforce mode, violations are both logged and blocked, actively restricting the application's behavior according to the profile.

Answer

unconfined

Answer

permissive

Answer

audit

Question 13

An administrator wants to enforce that no container in a specific namespace runs with the privileged security context. They decide to use Pod Security Standards. Which Pod Security Standard level should be applied to the namespace?

Accepted Answer

restricted. The restricted Pod Security Standard (PSS) level is the correct choice because it enforces the most stringent set of security controls, including the prohibition of privileged containers. This level denies any pod that requests `privileged: true` or uses other privileged capabilities, ensuring that no container in the namespace can run with elevated host access. The baseline level is less restrictive and allows some privileged configurations, while the privileged level imposes no restrictions at all.

Answer

baseline

Answer

custom

Answer

privileged

Question 14

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 15

Which command loads an AppArmor profile from a file into the kernel?

Accepted Answer

apparmor_parser -r /path/to/profile. 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.

Answer

aa-enforce /path/to/profile

Answer

aa-status

Answer

modprobe apparmor