CKS Cluster Hardening — 10 Questions

Question 1

You are reducing the attack surface of the kube-apiserver on a kubeadm cluster. The security team wants to disable anonymous authentication and restrict which users can be impersonated. Which TWO actions achieve these goals? (Choose two.)

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Set --anonymous-auth=false on the kube-apiserver and restart the static pod.. Anonymous authentication is turned off with the anonymous-auth flag on the apiserver, which removes the unauthenticated identity from request handling. Impersonation is governed by RBAC verbs on the impersonate subresource, so restricting those grants to a small set of ClusterRoles and auditing their use limits identity pivoting. The other options either broaden authorization, widen front-proxy trust, or address image pulling, none of which map to the two stated goals.

Answer

Enable the AlwaysPullImages admission plugin so anonymous image pulls are blocked.

Answer

Set --authorization-mode=AlwaysAllow to simplify authorization while anonymous access is disabled.

Answer

Set --requestheader-allowed-names to the wildcard so aggregation clients can present any common name.

Question 2

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 3

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 4

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

Accepted Answer

runAsNonRoot: true. 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 5

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

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

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 8

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

Accepted Answer

The ClusterRole was bound with a namespace-scoped RoleBinding in 'default' instead of a ClusterRoleBinding. The ClusterRole was bound with a namespace-scoped RoleBinding (created in the 'default' namespace) rather than a cluster-scoped ClusterRoleBinding. A RoleBinding can reference a ClusterRole, but it only grants those permissions inside the RoleBinding's own namespace — which is why access works in 'default' but not in 'test'. Binding the ClusterRole with a ClusterRoleBinding would grant pod access in every namespace. Option A is wrong because a ClusterRoleBinding (not a RoleBinding) is what grants cluster-wide access. Option B is wrong because human users do not need ServiceAccounts. Option D is wrong because the scenario states the ClusterRole includes the 'list' verb.

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 9

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

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