# If proxy kubeconfig file exists, ensure ownership is set to root:root

- Source: https://support.icompaas.com/support/solutions/articles/62000234686-if-proxy-kubeconfig-file-exists-ensure-ownership-is-set-to-root-root
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [CIS Kubernetes Benchmark v1.9.0](https://support.icompaas.com/support/solutions/62000112690) › [CIS Kubernetes Benchmark](https://support.icompaas.com/support/solutions/folders/62000169256)
- Last updated: 2026-05-29
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

### Profile Applicability:

-   **Level 1**  
      
    

### Description:

The kubeconfig file, which contains sensitive credentials and cluster configuration details, should be owned by the root user and group to prevent unauthorized access or tampering. If the proxy kubeconfig file exists, it is important that the ownership is set to root:root to ensure that only the root user can modify or access the file, thereby enhancing security.

### Rationale:

Setting the ownership of the kubeconfig file to root:root ensures that only privileged users (typically the root user) can access or modify the file. This is essential for maintaining the security of the Kubernetes cluster, as it prevents unauthorized users from altering the configuration or accessing sensitive credentials stored within the kubeconfig file.

### Impact:

Pros:  

-   Prevents unauthorized users from modifying or reading the kubeconfig file.  
    
-   Increases security by restricting access to sensitive configuration data.  
    

Cons:  

-   If the ownership is misconfigured, it could prevent legitimate users with proper privileges from accessing the kubeconfig file.  
    

### Default Value:

By default, kubeconfig files should have the ownership set to root:root in secure systems, but this may vary depending on system setup or installation procedures.

### Pre-requisites:

-   The proxy kubeconfig file must exist and be located in a directory accessible by the root user (typically ~/.kube/config or another specified location).
    
-   The file should be properly configured to enable cluster access.  
    

### Test Plan:

#### Using AWS Console:

1.  Sign in to the AWS Management Console.  
    
2.  Navigate to your Kubernetes worker node.  
    
3.  Check if the proxy kubeconfig file exists (commonly located at ~/.kube/config or a custom location).
    

Verify the ownership of the kubeconfig file using the following command:

ls -l ~/.kube/config

4.  Ensure the ownership is set to root:root.  
    

#### Using AWS CLI:

1.  SSH into the Kubernetes node.  
    

Run the following command to check the ownership of the kubeconfig file:

ls -l ~/.kube/config

2.  Verify that the ownership is root:root.  
    

### Implementation Plan

#### Using AWS Console:

1.  Access the Kubernetes node where the proxy kubeconfig file is located.  
    

Verify the file's ownership with the following command:  

ls -l ~/.kube/config

If the ownership is not set to root:root, update the ownership:

sudo chown root:root ~/.kube/config

#### Using AWS CLI:

1.  SSH into the Kubernetes node.  
    

Check the ownership of the proxy kubeconfig file:

ls -l ~/.kube/config

If the ownership is incorrect, set it to root:root:

sudo chown root:root ~/.kube/config

### Backout Plan

#### Using AWS Console:

1.  Navigate to the Kubernetes node.  
    
2.  If necessary, revert the ownership to a more permissive setting (e.g., user-specific ownership).  
    
3.  Verify that the change has been applied and that the kubeconfig file is accessible.  
    

#### Using AWS CLI:

If issues occur, revert the ownership using:

sudo chown <user>:<group> ~/.kube/config

### References:

-   Kubernetes Kubeconfig Documentation  
    Linux chown Command

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