Cluster Hardening practice questions

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

Why it fails: AlwaysPullImages forces kubelet to pull images on every pod start, which affects image provenance rather than API authentication. It has no relationship to anonymous requests to the apiserver or to impersonation permissions. Enabling it would add registry load without addressing either of the two hardening goals in the scenario.

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

Why it fails: AlwaysAllow authorizes every authenticated request, which massively broadens what any valid credential can do and is never an acceptable hardening step. It also has nothing to do with anonymous authentication or impersonation. Enabling it would undermine the isolation the security team is trying to achieve and would likely fail a CIS benchmark check.

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

Why it fails: The requestheader-allowed-names flag lists the common names the apiserver accepts on client certificates presented for the front-proxy. Setting it to a wildcard would let any certificate with a matching CA chain impersonate arbitrary users through the aggregation layer, which widens rather than narrows the attack surface and does not disable anonymous access.

Use a mutating admission webhook to automatically add seccomp profiles

Why it fails: A mutating admission webhook that automatically adds seccomp profiles only modifies the pod spec; it does not reject pods that still violate other restricted constraints such as running as root, adding capabilities, or using privileged containers. Attackers could craft pods that bypass the webhook if it's not configured as the only admission controller, and mutation alone never produces an admission rejection. Therefore, it lacks the enforcement guarantee required to ensure all pods are compliant.

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

Why it fails: The 'baseline' policy is intentionally less restrictive than 'restricted'; it does not mandate a seccomp profile and permits several privileged settings that restricted forbids, like certain capabilities and hostPID sharing. Even with 'enforce' mode blocking violations of baseline, pods would still be allowed without seccomp, failing the security team's requirement. Only the restricted policy imposes the necessary seccomp requirement, so this combination is insufficient.

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

Why it fails: 'warn' mode with the restricted policy generates warning messages for violating pods, but it does not block their creation; a pod that lacks seccomp would still be admitted and run. This mode is designed for user-facing feedback or auditing, not enforcement, and therefore doesn't guarantee compliance. The security team needs enforce mode to actually prevent non-compliant pods from running.

Role with 'list' on pods, RoleBinding in observability

Why it fails: A Role is always namespace-scoped; it can only grant permissions inside the namespace where it is created. Here, the Role is defined in the observability namespace and bound there, so the monitor ServiceAccount can list pods only in that namespace, not across the cluster. If the monitoring requirement spans all namespaces, this configuration fails due to scope limitation, regardless of the correct 'list' verb.

ClusterRole with 'get' on pods, ClusterRoleBinding

Why it fails: The 'get' verb allows retrieving a single pod by name, but it does not permit enumeration or listing of pods. For monitoring use cases that need to discover all pods in the cluster, 'list' (or 'watch') is required. ClusterRoleBinding gives the right scope, but the verb is too restrictive, so this combination cannot fulfill the requirement.

ClusterRole with 'list' on pods, RoleBinding in observability

Why it fails: Even though the ClusterRole itself has cluster-wide scope, a RoleBinding can only grant permissions within the namespace where the binding exists. In this option, the RoleBinding is placed in observability, so the monitor ServiceAccount only receives the 'list' permission for pods in that namespace. Lacking a ClusterRoleBinding, this configuration incorrectly narrows the effective authorization to a single namespace.

fsGroup: 2000

Why it fails: The fsGroup field controls the group ownership assigned to mounted volumes, not the identity of the container's primary process. A pod can still run with UID 0 while fsGroup is set, so it does not satisfy the requirement to prevent root execution. It only affects how files and directories on volumes are group-readable/writable, leaving the process user unchanged.

runAsGroup: 3000

Why it fails: Setting runAsGroup only overrides the primary group ID (GID) of the container's processes; the user ID (UID) remains whatever the image and runAsUser define. If runAsUser is absent, the image's default user is often root (UID 0), so the process still runs as root. Thus runAsGroup alone cannot guarantee a non-root execution context.

runAsUser: 1000

Why it fails: While runAsUser can set a non-zero UID, it is merely a specific user assignment and does not inherently enforce a non-root policy. If omitted or set to 0, the container runs as root; even a value like 1000 only works if it matches the desired security constraint and the image supports that user. Since the goal is to prevent root, this field must be explicitly combined with runAsNonRoot or set to a non-zero value, making it an indirect and error-prone control.

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

Why it fails: AlwaysDeny is not a valid authorization mode for the kube-apiserver in current Kubernetes versions; it was deprecated and removed. Even if it were accepted, AlwaysDeny would reject every API request, making the control plane unusable. The CIS benchmark and kube-bench require the Node and RBAC authorizers, not a blanket deny. You need to modify the kube-apiserver manifest to set --authorization-mode=Node,RBAC.

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

Why it fails: Configuring --authorization-webhook-config-file delegates authorization to an external webhook service, but the CIS baseline requires the built-in Node and RBAC authorizers to be active as well. The webhook is an additional authorizer for custom policy, not a replacement for the core modes. Removing Node and RBAC in favor of a webhook would break kubelet permissions and standard RBAC enforcement. Restarting with only the webhook config does not satisfy the kube-bench check.

Set --authorization-mode=RBAC only

Why it fails: Setting --authorization-mode=RBAC only omits the Node authorizer, which is specifically required to authorize kubelet API requests like pods, secrets, and nodes. The Node authorizer grants kubelets their narrow per-node permissions, while RBAC governs users, groups, and service accounts. Without Node mode, kubelet requests fall back to RBAC rules, which may not cover all node API paths and can cause authorization failures or require overly broad permissions. The correct flag is --authorization-mode=Node,RBAC.

Remove runAsNonRoot: true

Why it fails: Removing runAsNonRoot: true merely disables the security check, but the underlying container still runs as root (UID 0). This relaxes the workload's security posture and violates Pod Security Standards, which require containers to run as non-root in most production namespaces. The correct action is to make the container actually run as a non-root user, not to bypass the validation.

Add a PodSecurityPolicy that allows root

Why it fails: PodSecurityPolicy is deprecated and scheduled for removal in newer Kubernetes versions, so relying on it is not a forward-looking solution. Moreover, a PSP that allows root does not change the container's effective UID; if runAsNonRoot: true is set, the kubelet or container runtime rejects the pod regardless of any policy. This option fails to address the direct failure and introduces an outdated admission control mechanism.

Use a mutating webhook to change the image

Why it fails: A mutating webhook could modify the image or pod spec at admission time, but it requires deploying and configuring a separate webhook server, which is heavy infrastructure for a single failing pod. It is not an immediate fix, and it introduces unacceptable complexity for what is simply a missing securityContext field. Moreover, the webhook would need to be cluster-wide and might not even be installed, making this approach impractical in most real-world scenarios.

PodSecurityPolicy

Why it fails: PodSecurityPolicy (PSP) is an admission controller that governs pod security contexts — such as privilege escalation, host namespaces, or Linux capabilities. It never touches network packets or low-level traffic routing, so it has no mechanism to block outbound connections. The resource is deprecated and removed in Kubernetes 1.25, and it was never a network policy object. Thus, using PSP to restrict egress is conceptually invalid and technically impossible.

iptables rules on nodes

Why it fails: iptables rules placed on nodes are not a Kubernetes resource; they are operating-system-level firewall entries managed via iptables/ipvs on each host. While on the data path, they lack pod identity awareness and selectors, so many users implement them as static rules that cannot scale or adapt to dynamic pod IPs. Also, the Kubernetes API has no knowledge of these rules, which breaks declarative management and auditability. Therefore, they are an external tool, not a resource, and unsuitable for pod-specific egress control.

NetworkPolicy with ingress rules

Why it fails: NetworkPolicy with ingress rules restricts only incoming traffic to the selected pods. Although the policy object shares the same schema, an ingress rule has no effect on outbound sessions initiated by pods; egress traffic will still be routed as per the cluster defaults. To control traffic leaving a pod, you must explicitly add an egress section (or use policyTypes: ['Egress']). Thus, ingress rules alone cannot limit egress and are the inverse of the required direction.

The ClusterRole must be bound with a RoleBinding

Why it fails: A ClusterRole does not have to be bound with a RoleBinding; in fact, to grant cluster-wide access, a ClusterRoleBinding is required. Binding a ClusterRole with a RoleBinding would further restrict permissions to a single namespace, which is the opposite of what is needed to allow listing pods in the 'test' namespace.

The user needs a ServiceAccount

Why it fails: ServiceAccounts are identities for pods to authenticate to the Kubernetes API, not for human users. Human users typically authenticate via X.509 certificates or OIDC tokens, and RBAC grants them permissions directly without any ServiceAccount. Requiring a ServiceAccount would not change the binding scope and is unrelated to the access problem.

The pod-reader ClusterRole is missing 'list' verb

Why it fails: The ClusterRole definition explicitly includes the 'list' verb for pods, so a missing verb is not the cause of the failure. If 'list' were absent, the user would get a validation error when attempting to list pods across all namespaces, but the issue here is specifically the binding scope, not the verb set.

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

Why it fails: PSP was removed in Kubernetes 1.25, so on a modern cluster this policy object does not exist; even on older versions PSPs are cluster-scoped authorization rules, not namespace-scoped assignments. You cannot 'assign' a PSP to a namespace — instead you bind it to a ServiceAccount via RBAC, which leaves many pods unaffected if their SA lacks the binding, and seccomp requirements in PSPs are easy to bypass. Relying on PSP is defensively obsolete and not a viable enforcement solution.

Set seccomp profile in the kubelet configuration

Why it fails: The kubelet's `--seccomp-default` flag only instructs the node's runtime to apply the runtime default profile when a container does not specify one; it is a runtime-level default, not an admission policy. It has no awareness of namespaces or pod security constraints, and an explicit `seccompProfile` in the pod spec overrides it, while older runtimes may ignore it entirely. Therefore it never guarantees that a given namespace cannot run without a profile.

Use a mutating admission webhook to add seccomp profile

Why it fails: A mutating admission webhook can inject a seccomp profile into a pod's security context, but it does not validate or reject anything; if the webhook is not registered, fails open, or a pod already sets an unconfined profile, the mutation may simply never occur. The API server never checks the final pod state against seccomp requirements, so a client communicating directly or using a privileged profile can still result in containers without the intended restriction. It is an operational defaulting tool, not an enforcement control.

Use static token file

Why it fails: A static token file stores plaintext bearer tokens in a CSV on the control-plane node. These tokens cannot be individually revoked without rotating the entire file, and they are transmitted as raw credentials, making them vulnerable to interception and theft. Kubernetes has deprecated this mechanism because it offers no per-user expiration, no integration with external identity providers, and no audit trail for token issuance, so it is not a recommended way to restrict cluster access.

Enable NodeRestriction admission plugin

Why it fails: The NodeRestriction admission plugin is an admission controller that limits the kubelet’s ability to create or modify resources, restricting it to nodes and pods bound to its node name. It does not govern how API server clients authenticate or authorize; it only limits what the kubelet can do after it has already been authenticated. Therefore, enabling it does not restrict access for human users, service accounts, or other clients, making it irrelevant to the goal of controlling general cluster access.

Enable anonymous access

Why it fails: Enabling anonymous access allows unauthenticated requests to reach the API server, effectively bypassing the authentication layer. If RBAC policies happen to grant permissions to the `system:anonymous` user or `system:unauthenticated` group, these requests can perform actions without any credentials, which creates a severe security risk. It should only be enabled when intentionally exposing public information, and it is not a mechanism for restricting access; it is the opposite of a secure access control measure.

Configure RBAC for etcd

Why it fails: Kubernetes RBAC applies to the Kubernetes API server, not directly to etcd, which is a separate datastore. etcd does offer its own user/role object model, but in standard cluster deployments access is enforced through mutual TLS client certificate authentication, not RBAC. Configuring RBAC is therefore not one of the required controls to secure etcd itself.

Allow anonymous access for monitoring

Why it fails: Allowing anonymous access to etcd means any unauthenticated client can read or modify the entire cluster state, including secrets, without presenting credentials. This completely undermines the confidentiality and integrity of the datastore. Monitoring should be performed using authenticated read-only accounts or dedicated agent certificates, never by permitting anonymous connections, making this practice inherently insecure.

Always use the latest tag

Why it fails: Using the `latest` tag means the same tag may refer to a different image digest tomorrow; a rebuild or an upstream push silently changes what your cluster runs. This breaks reproducibility, makes rollbacks harder, and can pull in newly introduced vulnerabilities or incompatible versions. For auditability and supply-chain security, always reference images by an exact digest (e.g., `image@sha256:...`) or at least a fully versioned and internally managed tag.

Run containers as root

Why it fails: Running as root (UID 0) inside a container is dangerous because kernel vulnerabilities or misconfigurations can allow a container process to perform actions with host root privileges. Even without an escape, root can modify binaries, install tools, or tamper with runtime metadata inside the container. The pod security context should set `runAsNonRoot: true` or a numeric non-zero UID, and the container image should declare a dedicated user.

Run containers in privileged mode

Why it fails: Privileged mode essentially disables the container runtime’s isolation: it grants all Linux capabilities, allows access to host devices, and typically disables restrictions like seccomp and AppArmor. A single vulnerability in a privileged container can give an attacker direct access to the host kernel, device files, and cgroups, effectively yielding host root. It should never be used unless absolutely required, and alternatives like specific capability drops or device annotations should be applied.

Run kube-bench on the cluster

Why it fails: kube-bench is a compliance assessment tool that runs a series of automated checks against a cluster to verify adherence to the CIS Kubernetes Benchmark. It inspects configuration files, API server flags, and node settings, generating a report of pass/fail findings, but it does not register as an admission controller or otherwise intercept API requests. Consequently, kube-bench can only highlight weaknesses after the fact and cannot prevent a non-compliant pod from being created, so it is not an enforcement mechanism.

Manual review of all pod specs

Why it fails: Manual review of every pod spec relies on human inspection of manifests or live resources, which is not only unscalable but also fails to provide a technical control that blocks non-compliant pods at creation time. In a dynamic cluster with continuous deployments, automated workloads, or many developers, manual review is error-prone and cannot intercept API requests before a pod is scheduled. Since it lacks integration with the admission control flow, this approach is neither reliable nor enforceable, making it an invalid method for enforcing pod security.

Enable Pod Security Admission with the 'baseline' policy in enforce mode for acme-corp namespace, and add a mutating webhook to set readOnlyRootFilesystem

Why it fails: Pod Security Admission (PSA) with the 'baseline' policy in enforce mode restricts a limited set of dangerous features but does not enforce readOnlyRootFilesystem, and it also does not limit allowed capabilities to only NET_BIND_SERVICE — it merely blocks a handful of dangerous capabilities. Adding a mutating webhook to inject readOnlyRootFilesystem would mean maintaining a separate cluster-critical component, introducing possible bypasses or ordering issues with PSA, and still leaves the capability set too broad. This approach is complex and does not fully express the required security controls, making it inferior to a policy engine like Gatekeeper.

Use Pod Security Admission with the 'privileged' policy and rely on the legacy container's securityContext

Why it fails: Pod Security Admission with the 'privileged' policy is the most permissive profile — it explicitly permits privileged containers, host namespaces, host networking, and any Linux capabilities, so it does not provide any baseline tenant isolation. Relying on individual container securityContext settings is unenforceable at the admission level; a developer could omit those settings and the pod would run with the full privileges of the policy. This setup essentially delegates security to human error and is the opposite of the least-privilege requirements in the question.

Create a new PSP that allows NET_BIND_SERVICE and requires readOnlyRootFilesystem, then bind it to the acme-corp namespace via RoleBinding

Why it fails: Creating a new PodSecurityPolicy is not the best approach because PSPs are deprecated in Kubernetes v1.24 and are scheduled for removal in v1.25. Relying on a deprecated feature for a new tenant's configuration, especially when the cluster plans to migrate to Pod Security Admission, contradicts Kubernetes best practices. PSPs were previously the standard mechanism for enforcing granular pod security constraints, such as `readOnlyRootFilesystem` and specific capabilities like `NET_BIND_SERVICE`, and could be effectively scoped to namespaces via RoleBindings in older Kubernetes versions.

1. Add audit flags to API server, 2. Create audit policy file, 3. Mount policy file to API server, 4. Restart API server, 5. Verify audit logs

Why it fails: This order is incorrect because audit flags reference the policy file path, but the file does not exist yet. Adding flags before creating and mounting the policy file will cause the API server to fail to start or ignore the flags.

1. Create audit policy file, 2. Add audit flags to API server, 3. Mount policy file to API server, 4. Restart API server, 5. Verify audit logs

Why it fails: This order is incorrect because adding audit flags before mounting the policy file means the API server cannot access the policy file at startup, leading to errors or the flags being ignored. The mount must precede the flag addition.

1. Create audit policy file, 2. Mount policy file to API server, 3. Restart API server, 4. Add audit flags to API server, 5. Verify audit logs

Why it fails: The restart occurs before the audit flags are added, so the API server never loads the audit configuration during that restart. Since kube-apiserver reads command-line flags (e.g., --audit-policy-file, --audit-log-path) only at process startup, adding them afterward leaves the running process unaware of them and requires a second restart to take effect. Even though the policy file is already mounted, without the flags the API server will not enable audit logging. Therefore, the correct order must place the flag addition before the restart, after the policy file is mounted and accessible.

Pod Security Admission: Controls network traffic between pods

Why it fails: This statement is factually wrong because Pod Security Admission has no data-plane role; it is entirely an admission-time gate on the API server. PSA only inspects the pod spec for security context compliance before creation and issues an admission response—allow or deny—based on the Pod Security Standards. Network traffic between pods is controlled by Network Policies, which are enforced by the CNI plugin after pods are running, so this option confuses admission-time policy with runtime traffic filtering.

Network Policies: Enforces pod security standards

Why it fails: Network Policies do not enforce pod security standards; they only govern which workloads can communicate over the network by matching selectors, ports, and IP blocks. They cannot evaluate or enforce security contexts such as privileged containers, hostPID, or allowed capabilities—those are validated by Pod Security Admission at pod creation time. This answer is wrong because it attributes a control-plane admission responsibility to a data-plane traffic filter, mixing two distinct layers of Kubernetes security.

Set authentication.webhook.enabled=true and authorization.mode=Node in the kubelet config file.

Why it fails: Enabling webhook authentication for the kubelet allows it to use the API server for authentication, but setting authorization mode to Node restricts authorization to node-level checks. This mode only allows the kubelet to authorize requests from its own node, which may not cover all necessary access patterns and does not address anonymous access. It is not a recommended configuration for secure cluster hardening.

Set authentication.x509.clientCAFile to a valid CA and authorization.mode=AlwaysAllow in the kubelet config file.

Why it fails: Configuring a client CA file enables certificate-based authentication, but setting authorization mode to AlwaysAllow means any authenticated request is automatically authorized without further checks. An attacker with a valid client certificate could perform any action on the kubelet API. This does not enforce proper authorization and leaves the kubelet vulnerable to privilege escalation, so it fails to meet the hardening requirement.

Set authentication.anonymous.enabled=true and authorization.mode=AlwaysAllow in the kubelet config file.

Why it fails: Enabling anonymous authentication allows unauthenticated requests to reach the kubelet API, which is the exact vulnerability the penetration test found. Using AlwaysAllow for authorization bypasses any access control, so any anonymous user could execute commands or read pod details. This combination completely fails to harden the kubelet and would leave the cluster open to attacks, not secure it.

Add an RBAC rule to deny all actions for system:anonymous.

Why it fails: RBAC is additive; there are no deny rules. You cannot explicitly deny actions via RBAC. The only way to revoke permissions is to remove the binding or role that grants them. Adding a deny rule is not possible and would not work. This option reflects a misunderstanding of RBAC's allow-only model and fails to remediate the security issue.

Enable the NodeRestriction admission controller to limit anonymous access.

Why it fails: NodeRestriction limits the permissions of kubelets, not anonymous users. It does not affect ClusterRoleBindings for system:anonymous. Enabling it would not remove the dangerous binding and would leave the cluster vulnerable to unauthenticated administrative access. This action is irrelevant to the identified RBAC misconfiguration and fails to address the immediate threat.

Modify the ClusterRoleBinding to bind to a specific user instead of system:anonymous.

Why it fails: While changing the subject of the binding would revoke anonymous access, it might inadvertently grant cluster-admin to another user, which could still be a security risk if not carefully chosen. The immediate concern is the anonymous binding; deleting it is simpler and safer. Modifying could leave a misconfiguration if the new subject is not properly vetted, so it is not the best immediate action.

Add a NetworkPolicy to the kube-system namespace that denies ingress to TCP port 10255 on all pods.

Why it fails: NetworkPolicy applies to pod network traffic selected by pod labels, not to host-network listeners like the kubelet. The kubelet binds on the node's network namespace, so a NetworkPolicy targeting pods in kube-system will never match traffic destined to the node IP on 10255. The port would remain reachable from any host that can route to the node.

Change the kube-apiserver --kubelet-preferred-address-types flag to InternalIP so the read-only port is bypassed.

Why it fails: That flag only influences which node address apiserver uses when proxying logs, exec, and metrics to kubelet. It does not open or close the kubelet's own listeners, so the unauthenticated read-only port continues accepting connections. The exposure comes from kubelet configuration, not from how apiserver reaches kubelet.

Rotate the kubelet client certificate and enable NodeRestriction so the read-only port requires authentication.

Why it fails: NodeRestriction is an admission plugin that limits what a kubelet's credentials can modify through the API server; it has no effect on the kubelet's local HTTP listeners. Rotating client certificates strengthens kubelet-to-apiserver authentication but does nothing to secure port 10255, which by design serves unauthenticated data. The listener must be disabled in kubelet configuration.

Apply a PodSecurity admission label of restricted to every namespace so hostPath volumes are rejected.

Why it fails: The restricted Pod Security Standard does forbid hostPath volumes, but it also enforces many other constraints such as non-root execution, dropped capabilities, and seccomp profiles. Applying it cluster-wide would break the existing workloads that merely rely on CSI storage, which is exactly what the scenario says must keep working. A narrower control is required.

Add a NetworkPolicy with an empty podSelector in each namespace to prevent pods from reading host filesystem paths.

Why it fails: NetworkPolicy governs ingress and egress traffic between pods and external endpoints; it has no visibility into filesystem mounts. A hostPath mount is established by the kubelet at container creation, before any network policy applies. Using NetworkPolicy here would leave the hostPath exposure completely unaddressed while adding unrelated traffic restrictions.

Set --allow-privileged=false on the kubelet of every node so hostPath mounts are refused at runtime.

Why it fails: The allow-privileged flag on kubelet governs whether privileged containers and certain host namespaces are permitted; it does not govern hostPath volume mounts. A pod can still mount /etc via hostPath even when privileged mode is disabled, so this flag fails to address the reported risk and would also block legitimate privileged workloads unrelated to the finding.