CKS System Hardening — Timed 20 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

Question 16

Which of the following Pod specification settings prevents a container from using the host network namespace?

Accepted Answer

hostNetwork: false. Setting `hostNetwork: false` in the Pod's securityContext explicitly prevents the container from using the host's network namespace. When `hostNetwork` is `false` (the default), the container gets its own network stack with its own loopback interface and IP address, isolating it from the host's network interfaces and routing table. This is a fundamental Pod-level security setting to enforce network isolation.

Answer

hostIPC: false

Answer

hostNetwork: true

Answer

hostPID: false

Question 17

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 18

Which TWO of the following are valid methods to apply a seccomp profile to a pod in Kubernetes?

Accepted Answer

Setting 'securityContext.seccompProfile.type' in the pod spec. Option A is correct because Kubernetes supports the native seccomp field 'securityContext.seccompProfile.type' (with values such as RuntimeDefault, Localhost, or Unconfined) directly in the pod or container security context, which is the modern, stable way to apply a seccomp profile. Option E is correct because the legacy annotation 'seccomp.security.alpha.kubernetes.io/pod' was the original mechanism for applying a seccomp profile to an entire pod before the securityContext field existed, and it is still recognized for backward compatibility. Option B is incorrect because 'container.apparmor.security.beta.kubernetes.io/<container>' applies an AppArmor profile, not a seccomp profile. Option C is incorrect because PodSecurityPolicy (deprecated and removed in Kubernetes 1.25) controlled seccomp via its own allowed/required annotations and fields, not by embedding a seccomp profile definition itself. Option D is incorrect because the seccompProfile field belongs under 'securityContext' (pod-level) or a container's securityContext, but the option's phrasing of including it under 'spec.securityContext' as a distinct method is not a valid separate mechanism from A.

Answer

Adding annotation 'container.apparmor.security.beta.kubernetes.io/<container>'

Answer

Including 'seccomp' profile in PodSecurityPolicy

Answer

Including 'seccompProfile' under 'spec.securityContext' at the pod level

Question 19

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 20

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]'