Ensure the kubelet client certificate rotation is enabled

Méthode de vérification

Méthode d'audit: Commande shell

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

Sortie attendue

compliant

Méthode de correction

Méthode de correction: Recommandation ou correctif d'infrastructure

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.

Vérifier cet hôte

Exécutez cette commande sur une machine que vous êtes autorisé à auditer. L'analyse est en lecture seule.

tmaegis scan --target oke