Ensure that the kubeconfig file permissions are set to 644 or more restrictive (Automated)
Scanned 9/3/2026
Install to Claude Code
npx -y skills add CyberStrikeus/CyberStrike --skill cis-eks-v170-3.1.1 --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Cis Eks V170 3.1.1?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/cyberstrikeus-cis-eks-v170-3-1-1)More formats (shields.io, HTML) on the badges page.
---
name: cis-eks-v170-3.1.1
description: "Ensure that the kubeconfig file permissions are set to 644 or more restrictive (Automated)"
category: cis-eks
version: "1.7.0"
author: cyberstrike-official
tags: [cis, eks, kubernetes, aws, worker-node, configuration-files, file-permissions]
cis_id: "3.1.1"
cis_benchmark: "CIS Amazon Elastic Kubernetes Service (EKS) Benchmark v1.7.0"
tech_stack: [kubernetes, aws, eks]
cwe_ids: []
chains_with: []
prerequisites: []
severity_boost: {}
---
# 3.1.1 Ensure that the kubeconfig file permissions are set to 644 or more restrictive (Automated)
## Profile Applicability
- Level 1
## Description
If kubelet is running, and if it is configured by a kubeconfig file, ensure that the proxy kubeconfig file has permissions of 644 or more restrictive.
## Rationale
The kubelet kubeconfig file controls various parameters of the kubelet service in the worker node. You should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system.
It is possible to run kubelet with the kubeconfig parameters configured as a Kubernetes ConfigMap instead of a file. In this case, there is no proxy kubeconfig file.
Ensuring that the kubeconfig file permissions are set to 644 or more restrictive significantly strengthens the security posture of the Kubernetes environment by preventing unauthorized modifications. This restricts write access to the kubeconfig file, ensuring only administrators can alter crucial kubelet configurations, thereby reducing the risk of malicious alterations that could compromise the cluster's integrity.
However, this configuration may slightly impact usability, as it limits the ability for non-administrative users to make quick adjustments to the kubelet settings. Administrators will need to balance security needs with operational flexibility, potentially requiring adjustments to workflows for managing kubelet configurations.
## Audit Procedure
**Method 1 - SSH to the worker nodes:**
To check to see if the Kubelet Service is running:
```bash
sudo systemctl status kubelet
```
The output should return `Active: active (running) since..`.
Run the following command on each node to find the appropriate kubeconfig file:
```bash
ps -ef | grep kubelet
```
The output of the above command should return something similar to `--kubeconfig /var/lib/kubelet/kubeconfig` which is the location of the kubeconfig file.
Run this command to obtain the kubeconfig file permissions:
```bash
stat -c %a /var/lib/kubelet/kubeconfig
```
The output of the above command gives you the kubeconfig file's permissions. Verify that if a file is specified and it exists, the permissions are `644` or more restrictive.
**Method 2 - Create and Run a Privileged Pod:**
You will need to run a pod that is privileged enough to access the host's file system. This can be achieved by deploying a pod that uses the hostPath volume to mount the node's file system into the pod.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: file-check
spec:
volumes:
- name: host-root
hostPath:
path: /
type: Directory
containers:
- name: nsenter
image: busybox
command: ["sleep", "3600"]
volumeMounts:
- name: host-root
mountPath: /host
securityContext:
privileged: true
```
Save this to a file (e.g., file-check-pod.yaml) and create the pod:
```bash
kubectl apply -f file-check-pod.yaml
```
Once the pod is running, you can exec into it to check file permissions on the node:
```bash
kubectl exec -it file-check -- sh
```
Now you are in a shell inside the pod, but you can access the node's file system through the /host directory and check the permission level of the file:
```bash
ls -l /host/var/lib/kubelet/kubeconfig
```
Verify that if a file is specified and it exists, the permissions are `644` or more restrictive.
## Remediation
Run the below command (based on the file location on your system) on the each worker node. For example,
```bash
chmod 644 <kubeconfig file>
```
## Default Value
See the AWS EKS documentation for the default value.
## References
1. [https://kubernetes.io/docs/admin/kube-proxy/](https://kubernetes.io/docs/admin/kube-proxy/)
## CIS Controls
| Controls Version | Control | IG 1 | IG 2 | IG 3 |
| ---------------- | --------------------------------------- | ---- | ---- | ---- |
| v8 | 3.3 Configure Data Access Control Lists | X | X | X |
| v7 | 5.2 Maintain Secure Images | | X | X |
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!