# Ensure that the --rotate-certificates Argument is Not Present or is Set to True (Automated) - Source: https://support.icompaas.com/support/solutions/articles/62000234187-ensure-that-the-rotate-certificates-argument-is-not-present-or-is-set-to-true-automated- - Section: [Solutions](https://support.icompaas.com/support/solutions) › [CIS Amazon EKS](https://support.icompaas.com/support/solutions/62000112685) › [CIS Amazon Elastic Kubernetes Service (EKS) Benchmark](https://support.icompaas.com/support/solutions/folders/62000169234) - Last updated: 2026-05-29 - Publisher: iCompaas, Inc. (https://www.icompaas.com) **Profile Applicability:** **• Level 1** **Description:** Enable kubelet client certificate rotation by ensuring the --rotate-certificates argument is either not present or set to true. **Rationale:** The --rotate-certificates setting allows the kubelet to rotate its client certificates automatically by creating new Certificate Signing Requests (CSRs) as its existing credentials expire. This automatic rotation prevents downtime due to expired certificates and ensures the availability of the cluster while maintaining the security properties of the CIA triad (Confidentiality, Integrity, and Availability). **Impact:  Pros:** - Ensures continuous availability of the kubelet by preventing expired certificates from causing downtime. - Provides automated certificate rotation, reducing manual overhead. **Cons:** - If using external certificate authorities (e.g., Vault), the rotation feature may not work and must be handled separately. **Default Value:** Refer to the Amazon EKS documentation for the default value, as it might vary by Kubernetes version and distribution. **Pre-requisites:** - SSH or Session Manager access to worker nodes. - Permissions to modify Kubelet configuration files or systemd service arguments. - Kubernetes access to verify changes via /configz or deploy privileged pods. **Remediation** **Test Plan:** **Using AWS Console:** 1. SSH into each worker node and run the following command to find the Kubelet process: ps -ef | grep kubelet 2. If the --rotate-certificates argument is present, verify that it is set to true. 3. If the --rotate-certificates argument is not found, locate the Kubelet configuration file by checking the --config argument: \--config /etc/kubernetes/kubelet/kubelet-config.json 4. Open the Kubelet configuration file: cat /etc/kubernetes/kubelet/kubelet-config.json 5. Verify that the RotateCertificate argument is either not present or set to true. **Using AWS CLI:** 1. Get the list of nodes in your cluster: kubectl get nodes 2. Start a proxy to the Kubernetes API: kubectl proxy --port=8001 3. In a new terminal, for each node, run: export NODE\_NAME=my-node-name curl -sSL "http://localhost:8001/api/v1/nodes/${NODE\_NAME}/proxy/configz" 4. Verify that the RotateCertificate setting is either not present or set to true in the returned JSON. ### **Implementation Plan** **Using AWS Console:** 1. SSH into the worker node and run ps -ef | grep kubelet to find the Kubelet process. 2. Open the Kubelet configuration file: sudo less /path/to/kubelet-config.json 3. Modify or add the following entry to enable certificate rotation: "RotateCertificate": true 4. Save the file. 5. Ensure that the Kubelet service file at /etc/systemd/system/kubelet.service.d/10-kubelet-args.conf does not override this setting with --rotate-certificates=false. 6. Reload systemd and restart the Kubelet service: systemctl daemon-reload  systemctl restart kubelet.service  systemctl status kubelet -l **Using AWS CLI:** 1. Edit the Kubelet configuration file to set RotateCertificate to true. 2. If using systemd, add the following argument to the Kubelet service file: \--rotate-certificates=true 3. Reload systemd and restart the Kubelet service: systemctl daemon-reload systemctl restart kubelet.service systemctl status kubelet -l ### **Backout Plan** **Using AWS Console:** 1. If issues arise, revert the Kubelet configuration file to its previous state without the RotateCertificate setting or set it to false. 2. Restart the Kubelet service after rolling back the changes. **Using AWS CLI:** 1. Revert the changes made to the Kubelet configuration file or systemd service file. 2. Restart the Kubelet service: systemctl daemon-reload systemctl restart kubelet.service ### **References:** 1. [Kubelet Documentation](https://kubernetes.io/docs/admin/kubelet/) 2. [Kubernetes Feature Gates](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) 3. [Reconfigure a Node's Kubelet](https://kubernetes.io/docs/tasks/administer-cluster/reconfigure-kubelet/) 4. [Kubelet Configuration - Rotate Certificates](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tlsbootstrapping/#kubelet-configuration) ### **CIS Controls:**

Version

Control ID

Control Description

v8

3.10

Encrypt sensitive data in transit, including using TLS for connections.

v7

14.4

Encrypt all sensitive information in transit.

## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.