More Info:
The kubelet configuration file should have permissions of 644 or more restrictive. World-writable kubelet config files can be tampered with by any user on the node and lead to credential or configuration theft.Risk Level
HighAddress
Compliance, SecurityCompliance Standards
- CIS OKE
Triage and Remediation
- Remediation
Remediation
Using Console
Using Console
To fix this in OKE, you need to ensure every worker node sets the kubelet config file permissions at boot. In OKE this is done via the node pool configuration (cloud‑init) from the OCI Console, then by recycling nodes.Below are the steps using only the OCI Console.
i.e., mode
1. Identify the kubelet config file path in your OKE version
For recent OKE versions, kubelet config is typically at one of:/var/lib/kubelet/config.yaml
or/etc/kubernetes/kubelet/kubelet-config.json
- SSH to one worker node (from Bastion or similar).
- Run:
- Note the correct path (use that in the script in step 3).
/var/lib/kubelet/config.yaml. Replace with your actual path if different.2. Open your OKE Cluster and Node Pool in the Console
- In OCI Console, go to Developer Services → Kubernetes Clusters (OKE).
- Click your cluster.
- Go to the Node Pools tab.
- Click the node pool you want to fix (repeat for each pool type if needed).
3. Add a cloud-init script to enforce 644 permissions
You will inject a small script that runs on each node at boot and fixes the permissions.- In the Node Pool details page, click Edit (or Edit Node Pool).
- Find the section for Node Configuration, Custom cloud-init, or Additional configuration (name varies slightly by UI version, but it is where “User data” or “Cloud-init script” goes).
-
In the Cloud-init script (YAML) box, add/append the following:
- If you already have a
#cloud-configblock, just append theruncmdsection or add these commands to the existingruncmdlist. - If your kubelet config file path is different, change
KUBELET_CONFIG_FILEaccordingly.
- If you already have a
- Click Save changes (or Update).
4. Recycle/replace existing worker nodes
Existing VMs won’t retroactively run the new cloud-init. You need to cycle them:Option A – Rolling node termination (recommended)- Still in the Node Pool details page, go to the Nodes list.
- For each node (one or a few at a time to avoid downtime):
- Select the node.
- Click Terminate.
- Ensure the node pool is set to maintain its configured node count (it usually is by default).
- OKE will automatically create replacement nodes, which will run the new cloud-init and set kubelet config to
644.
- Edit the Node Pool and temporarily reduce Number of nodes to 0 and save.
- After all nodes terminate, edit again and set Number of nodes back to the desired value.
- All new nodes will have the correct permissions.
5. Verify permissions
After new nodes are up:- SSH to a new worker node.
- Run:
(or your actual path).
644, owner root:root.Repeat for all node pools if you have multiple pools.Using CLI
Using CLI
For OKE you can’t change kubelet file permissions directly from the control plane; you must fix them on the worker nodes (node pool instances). Using OCI CLI, the cleanest way is via the Oracle Cloud Agent “Run Command” (or via SSH if you prefer). Below are step‑by‑step instructions using OCI CLI.Assumptions (adjust paths as needed for your OKE image/version):
You now have the instance OCIDs of the worker nodes.
If (Names may vary slightly by region/image; enable the Run Command-related plugin used in your tenancy.)
You’ll run this through the “Run Command” feature via OCI CLI.
If your tenancy exposes it via the Os Management / Work Requests interface, the pattern is similar:Use that base64 output in
Expected:
Where Encode and supply in
If you share your exact OKE worker image/version, I can give the precise kubelet config path and an exact
- Kubelet config file path:
/var/lib/kubelet/config.yaml - Desired permissions:
644 - Ownership should remain
root:root
1. Identify your node pool and nodes
2. Make sure Oracle Cloud Agent “Run Command” is enabled
On each instance, the OS Management / Oracle Cloud Agent Management plugin must have the “Run Command” capability enabled.Check per instance (example for one instance):run-command (or similar) plugin is disabled, update:3. Prepare the remediation command
The command you need on each node:4. Run the command on each worker node via OCI CLI
OCI provides a run‑shell‑script style API under Oracle Cloud Agent. In many tenancies this is exposed as:scriptContent above is base64 of the same bash script; you can create this on your own system:scriptContent.Run this for each worker instance in the node pool.5. Verify permissions
Use either:- “Run Command” again with a verification script, or
- SSH (via Bastion / public IP) and check manually.
6. Make it persistent for new nodes in the node pool
To avoid this reappearing when nodes are replaced or scaled:- Edit the node pool metadata (cloud-init) via OCI CLI to add a small post‑boot script:
user_data is a base64-encoded cloud‑init file, for example:user_data.- For existing nodes you already fixed, nothing more is needed; for any new or replaced nodes, the cloud‑init will enforce 644 automatically.
If you share your exact OKE worker image/version, I can give the precise kubelet config path and an exact
oci command variant for your environment.Using Python
Using Python
Below is a practical way to remediate this in Oracle Container Engine for Kubernetes (OKE) using Python:Goal: Ensure kubelet config file(s) on every worker node have permission
Make sure your kubeconfig for OKE is set (e.g. What this does:
You should see permissions
If you share:
644 (rw-r—r—).Typical kubelet config paths on OKE nodes (you may have one or both):/etc/kubernetes/kubelet.conf/var/lib/kubelet/config.yaml
Approach 1: Python + Kubernetes API (recommended; no direct SSH)
We will:- Use the Kubernetes Python client.
- Create and run a privileged DaemonSet that:
- Mounts the host
/filesystem. - Executes
chmod 644on kubelet config files on each node.
- Mounts the host
- Delete the DaemonSet after it finishes.
1. Install dependencies
KUBECONFIG=~/.kube/config or default path).2. Python script to apply a DaemonSet that fixes permissions
- Runs a privileged pod on every node.
- Each pod
chmod 644on kubelet config files if they exist. - Then the script deletes the DaemonSet.
Approach 2: Python + SSH (Paramiko) to each worker node
Use this if you prefer to log in to OKE worker nodes directly (bastion or VCN access required).1. Install Paramiko
2. Python script to fix permissions via SSH
Verification
On any worker node (via SSH or via a debug pod withhostPath), run:644 where the files exist.If you share:
- exact OKE version,
- OS image (Oracle Linux version), I can adjust the file paths and DaemonSet manifest precisely to your environment.
Using Terraform
Using Terraform
node_metadata.user_data will cause existing worker nodes in this node pool to be replaced (a rolling recycle), which can briefly disrupt workloads if you lack sufficient pod disruption budgets or capacity.Verification with terraform plan should show an in-place update to oci_containerengine_node_pool.oke_nodepool with a change to node_config_details[0].node_metadata.user_data, and no other resources changed.
