Ensure the kubelet client certificate rotation is 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 '"rotateCertificates":true'; }; 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 configured to rotate its kubelet client certificate and should be treated as noncompliant. If the field is not present, interpret that conservatively as rotation not enabled unless your OKE platform explicitly manages certificate rotation for you. Oracle OKE documentation shows worker nodes using kubelet client certificates trusted by the cluster CA and supports managed node customization through cloud-init initialization scripts and kubelet extra args. Oracle also documents that worker node property changes can be applied through new or replacement managed nodes. Remediation of new cluster When creating a new OKE cluster or node pool, the goal is to ensure worker nodes start with kubelet client certificate rotation enabled if the nodes may remain in service long enough for certificate expiry to matter.

Check this host

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

tmaegis scan --target oke