# Ensure that the kubelet configuration file ownership is set to root:root

- Source: https://support.icompaas.com/support/solutions/articles/62000234174-ensure-that-the-kubelet-configuration-file-ownership-is-set-to-root-root-
- 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:** Ensure that if the kubelet refers to a configuration file via the --config argument, the file is owned by root:root. This ensures only privileged users can modify it, preserving the security of node-level configuration.

**Rationale:** The kubelet reads key operational and security parameters from a config file. Ensuring this file is owned by root:root prevents unauthorized changes, which could otherwise compromise cluster stability and security.

**Impact:**

-   Secures critical configuration against unauthorized modifications.
    
-   Enforces file-level ownership best practices.
    
-   Ensures compliance with least privilege principles.
    

**Default Value:** Default ownership may vary depending on the AMI or base image. Refer to AWS EKS documentation for specifics.

**Pre-requisites:**

-   SSH or Session Manager access to worker nodes.
    
-   Permissions to inspect and modify file ownership.
    
-   Kubernetes access to deploy privileged pods.
    

### **Remediation**

**Test Plan:**

**Using AWS Console:**

1.  Navigate to Amazon EC2 > Instances.
    
2.  Select and connect to a worker node using Session Manager or EC2 Instance Connect.
    
3.  Confirm kubelet is running:
    
    -   sudo systemctl status kubelet
        
4.  Identify the kubelet configuration file:
    
    -   ps -ef | grep kubelet
        
5.  Check ownership of the file:
    
    -   stat -c %U:%G /etc/kubernetes/kubelet/config.json
        
6.  Verify that ownership is set to root:root.
    

**Using AWS CLI:**

1.  Deploy a privileged pod to access the host filesystem.
    
2.  Enter the pod and check ownership of the configuration file.
    

kubectl apply -f file-check-pod.yaml
kubectl exec -it file-check -- sh
ls -l /host/etc/kubernetes/kubelet/config.json

### **Implementation Plan**

**Using AWS Console:**

1.  Use Session Manager or EC2 Connect to access the worker node.
    
2.  Identify the kubelet config file path via --config.
    
3.  Use the chown command to set the correct ownership.
    

**Using AWS CLI:**

1.  SSH into the worker node or use Systems Manager.
    
2.  Run the following command:
    

chown root:root /etc/kubernetes/kubelet/config.json

### **Backout Plan**

**Using AWS Console:**

1.  Access the instance using Session Manager.
    
2.  Revert ownership to the previously set user/group if needed.
    

**Using AWS CLI:**

1.  Restore original ownership settings if required:  
    
    chown <previous\_user>:<previous\_group> /etc/kubernetes/kubelet/config.json
    

### **References:**

1.  [Kubernetes - Kubelet Config Reference](https://kubernetes.io/docs/admin/kube-proxy/)

## 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.