| name | cis-oke-v170-3.1.1 |
| description | Ensure that the kubelet-config.json file permissions are set to 644 or more restrictive (Automated) |
| category | cis-oke |
| version | 1.7.0 |
| author | cyberstrike-official |
| tags | ["cis","oke","kubernetes","oci","worker-node","config-files"] |
| cis_id | 3.1.1 |
| cis_benchmark | CIS Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) Benchmark v1.7.0 |
| tech_stack | ["kubernetes","oci","oke"] |
| cwe_ids | [] |
| chains_with | [] |
| prerequisites | [] |
| severity_boost | {} |
CIS OKE Benchmark v1.7.0 - Control 3.1.1
Profile Applicability
Description
If kubelet is running, and if it is using a file-based kubelet-config.json file, ensure that the proxy kubelet-config.json file has permissions of 644 or more restrictive.
Rationale
The kubelet kubelet-config.json 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 kubelet-config.json file.
Impact
None.
Audit Procedure
Method 1
SSH to the worker nodes. To check to see if the Kubelet Service is running:
sudo systemctl status kubelet
The output should return Active: active (running) since...
Run the following command on each node to find the appropriate kubelet-config.json file:
ps -ef | grep kubelet
The output of the above command should return something similar to --kubeconfig /etc/kubernetes/kubelet-config.json which is the location of the kubelet-config.json file.
Run this command to obtain the kubelet-config.json file permissions:
stat -c %a /etc/kubernetes/kubelet-config.json
The output of the above command gives you the kubelet-config.json 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.
Here's an example of a simple pod definition that mounts the root of the host to /host within the pod:
apiVersion: v1
kind: Pod
metadata:
[, ]
