Ensure the kubelet iptables utility chains are enabled

How it is checked

Audit method: Shell command

nodes=$(kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}') || exit 1
[ -n "$nodes" ] || exit 1
ok=1
for n in $nodes; do
  c=$(kubectl get --raw "/api/v1/nodes/$n/proxy/configz") || exit 1
  if ! { ! printf '%s' "$c" | grep -Eq '"makeIPTablesUtilChains":false'; }; then echo "noncompliant: $n"; ok=0; fi
done
if [ "$ok" -eq 1 ]; then echo compliant; fi

Expected output

compliant

How it is fixed

Fix method: Guidance or infrastructure patch

If the audit returns false, the worker node is not keeping kubelet iptables utility chains enabled and should be treated as noncompliant. If the result is null or the field is missing, first confirm the configz response is complete, because Kubernetes identifies that endpoint as the view of the kubelet’s final actuated configuration, and the kubelet configuration schema defines makeIPTablesUtilChains with a default of true. Once the result is validated, remediation in EKS should be performed through the supported node provisioning or node update workflow, not by directly editing the kubelet config file on the host. AWS documents that managed node customization is applied through launch templates and bootstrap logic, and that managed node group updates to a new launch template version replace the nodes to match that configuration.

Check this host

Run this on a machine you are allowed to audit. The scan is read-only.

tmaegis scan --target eks