CKS Cluster Hardening — Timed 10 Questions

Question 1

A security team wants to ensure that all pods in a namespace run with a restricted seccomp profile. Which Pod Security Standard admission controller mode should be used to enforce this without blocking necessary pods?

Accepted Answer

Enable the PodSecurity admission plugin with the 'restricted' policy and 'enforce' mode. The Pod Security Standards (PSS) define three policies: privileged, baseline, and restricted. The restricted policy enforces the most stringent security controls, including requiring a seccomp profile to be set to 'RuntimeDefault' or 'localhost/*'. Using the PodSecurity admission plugin with 'enforce' mode ensures that any pod failing the restricted policy is immediately rejected, guaranteeing that only compliant pods run in the namespace.

Answer

Use a mutating admission webhook to automatically add seccomp profiles

Answer

Enable the PodSecurity admission plugin with the 'baseline' policy and 'enforce' mode

Answer

Enable the PodSecurity admission plugin with the 'restricted' policy and 'warn' mode

Question 2

A cluster uses RBAC and a ServiceAccount 'monitor' in namespace 'observability'. The account needs to list pods in all namespaces. Which ClusterRole and binding should be created?

Accepted Answer

ClusterRole with 'list' on pods, ClusterRoleBinding. A ServiceAccount that needs to list pods across all namespaces requires a ClusterRole with the 'list' verb on pods, because ClusterRoles are not namespaced and can grant permissions cluster-wide. A ClusterRoleBinding is necessary to bind that ClusterRole to the ServiceAccount, as RoleBindings only apply within a single namespace and cannot grant cluster-scoped permissions.

Answer

Role with 'list' on pods, RoleBinding in observability

Answer

ClusterRole with 'get' on pods, ClusterRoleBinding

Answer

ClusterRole with 'list' on pods, RoleBinding in observability

Question 3

An administrator wants to prevent pods from running as root. Which SecurityContext field should be set at the pod level?

Accepted Answer

runAsNonRoot: true. Option D is correct because setting `runAsNonRoot: true` at the pod-level SecurityContext enforces that all containers in the pod must run with a non-root user (UID > 0). If a container image specifies a user with UID 0 (root) or does not specify a user, the container will fail to start, preventing privilege escalation from root access.

Answer

fsGroup: 2000

Answer

runAsGroup: 3000

Answer

runAsUser: 1000

Question 4

A company uses kube-bench to scan their cluster. The report shows a warning: 'Ensure that the --authorization-mode argument is set to Node,RBAC'. What is the best way to fix this?

Accepted Answer

Edit the kube-apiserver manifest to add --authorization-mode=Node,RBAC. Option D is correct because kube-bench checks that the API server's `--authorization-mode` includes both `Node` and `RBAC` in that order. The `Node` authorizer must come first to handle node-specific requests efficiently, followed by `RBAC` for user and service account authorization. Editing the kube-apiserver manifest (typically `/etc/kubernetes/manifests/kube-apiserver.yaml`) to add `--authorization-mode=Node,RBAC` ensures the static pod is automatically restarted by the kubelet with the correct configuration.

Answer

Add --authorization-mode=AlwaysDeny to the API server

Answer

Restart the API server with --authorization-webhook-config-file

Answer

Set --authorization-mode=RBAC only

Question 5

A pod is failing to start with: 'Error: container has runAsNonRoot and image will run as root'. The pod spec sets securityContext.runAsNonRoot: true. The container image is 'nginx:latest' which runs as root. Which change allows the pod to run while maintaining security?

Accepted Answer

Set runAsUser: 1000 in the container securityContext. Option C is correct because setting `runAsUser: 1000` in the container's securityContext overrides the default user (root) in the image, ensuring the container process runs as a non-root user (UID 1000). This satisfies the `runAsNonRoot: true` constraint at the pod level, which requires that the container's user ID is non-zero, while still maintaining security by not running as root.

Answer

Remove runAsNonRoot: true

Answer

Add a PodSecurityPolicy that allows root

Answer

Use a mutating webhook to change the image

Question 6

Which Kubernetes resource should be used to restrict egress traffic from pods?

Accepted Answer

NetworkPolicy with egress rules. NetworkPolicy with egress rules is the correct Kubernetes-native resource to restrict outbound traffic from pods. It uses label selectors, IP blocks, and port specifications to define which external destinations pods can reach, enforcing zero-trust network segmentation at the pod level.

Answer

PodSecurityPolicy

Answer

iptables rules on nodes

Answer

NetworkPolicy with ingress rules

Question 7

A developer created a ClusterRole 'pod-reader' with rules to get, list, and watch pods. They bound it to a user via ClusterRoleBinding. The user reports they cannot list pods in namespace 'test'. What is the most likely cause?

Accepted Answer

The ClusterRoleBinding might have a namespace set. Option C is correct because a ClusterRoleBinding is cluster-scoped and does not have a namespace field, but if a RoleBinding is used instead, it can restrict permissions to a specific namespace. The most likely cause is that the user inadvertently created a RoleBinding in the 'test' namespace (or the ClusterRoleBinding was misconfigured with a namespace selector), which would limit the binding's effect to that namespace. Since the user cannot list pods in 'test', the binding likely has a namespace constraint, preventing the cluster-wide permissions from applying.

Answer

The ClusterRole must be bound with a RoleBinding

Answer

The user needs a ServiceAccount

Answer

The pod-reader ClusterRole is missing 'list' verb

Question 8

A cluster has a PodSecurityPolicy that requires 'RunAsAny' for the user. An administrator wants to enforce that all pods in namespace 'production' must run with a specific seccomp profile. Which approach is recommended given PSP is deprecated?

Accepted Answer

Enable PodSecurity admission with 'restricted' policy in enforce mode. Option A is correct because PodSecurity admission (the replacement for PSP) allows enforcing a 'restricted' policy that mandates a seccomp profile (e.g., RuntimeDefault) at the namespace level. This directly meets the requirement without relying on deprecated PSPs, and the 'enforce' mode ensures pods violating the policy are rejected.

Answer

Create a new PSP with seccomp profile and assign it to the namespace

Answer

Set seccomp profile in the kubelet configuration

Answer

Use a mutating admission webhook to add seccomp profile

Question 9

Which TWO of the following are valid ways to restrict access to the Kubernetes API server?

Accepted Answer

Use webhook token authentication. Webhook token authentication (Option B) is a valid method to restrict API server access because it delegates token validation to an external service via a webhook, allowing custom authentication logic. This is a supported authentication strategy in Kubernetes, enabling fine-grained control over who can access the API server.

Answer

Use static token file

Answer

Enable NodeRestriction admission plugin

Answer

Enable anonymous access

Question 10

Which THREE of the following are required to secure etcd in a Kubernetes cluster?

Accepted Answer

Require client certificate authentication. Option C is correct because etcd requires client certificate authentication to verify the identity of clients (such as kube-apiserver) connecting to it. Without mutual TLS (mTLS), an attacker could impersonate a legitimate client and read or modify cluster state, including secrets and configuration data.

Answer

Configure RBAC for etcd

Answer

Allow anonymous access for monitoring