Skip to main content

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

High

Address

Compliance, Security

Compliance Standards

  • CIS OKE

Triage and Remediation

Remediation

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.

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
If you’re unsure:
  1. SSH to one worker node (from Bastion or similar).
  2. Run:
  3. Note the correct path (use that in the script in step 3).
Assume below the file is /var/lib/kubelet/config.yaml. Replace with your actual path if different.

2. Open your OKE Cluster and Node Pool in the Console

  1. In OCI Console, go to Developer ServicesKubernetes Clusters (OKE).
  2. Click your cluster.
  3. Go to the Node Pools tab.
  4. 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.
  1. In the Node Pool details page, click Edit (or Edit Node Pool).
  2. 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).
  3. In the Cloud-init script (YAML) box, add/append the following:
    • If you already have a #cloud-config block, just append the runcmd section or add these commands to the existing runcmd list.
    • If your kubelet config file path is different, change KUBELET_CONFIG_FILE accordingly.
  4. Click Save changes (or Update).
This ensures all new nodes from this pool will apply the correct permissions automatically.

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)
  1. Still in the Node Pool details page, go to the Nodes list.
  2. For each node (one or a few at a time to avoid downtime):
    • Select the node.
    • Click Terminate.
  3. Ensure the node pool is set to maintain its configured node count (it usually is by default).
  4. OKE will automatically create replacement nodes, which will run the new cloud-init and set kubelet config to 644.
Option B – Scale down then up (more disruptive)
  1. Edit the Node Pool and temporarily reduce Number of nodes to 0 and save.
  2. After all nodes terminate, edit again and set Number of nodes back to the desired value.
  3. All new nodes will have the correct permissions.

5. Verify permissions

After new nodes are up:
  1. SSH to a new worker node.
  2. Run:
    (or your actual path).
You should see:
i.e., mode 644, owner root:root.Repeat for all node pools if you have multiple pools.
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):
  • Kubelet config file path: /var/lib/kubelet/config.yaml
  • Desired permissions: 644
  • Ownership should remain root:root

1. Identify your node pool and nodes

You now have the instance OCIDs of the worker 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):
If run-command (or similar) plugin is disabled, update:
(Names may vary slightly by region/image; enable the Run Command-related plugin used in your tenancy.)

3. Prepare the remediation command

The command you need on each node:
You’ll run this through the “Run Command” feature via OCI CLI.

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:
If your tenancy exposes it via the Os Management / Work Requests interface, the pattern is similar:
scriptContent above is base64 of the same bash script; you can create this on your own system:
Use that base64 output in 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.
Example via SSH:
Expected:

6. Make it persistent for new nodes in the node pool

To avoid this reappearing when nodes are replaced or scaled:
  1. Edit the node pool metadata (cloud-init) via OCI CLI to add a small post‑boot script:
Where user_data is a base64-encoded cloud‑init file, for example:
Encode and supply in user_data.
  1. 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.
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 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

We will:
  1. Use the Kubernetes Python client.
  2. Create and run a privileged DaemonSet that:
    • Mounts the host / filesystem.
    • Executes chmod 644 on kubelet config files on each node.
  3. Delete the DaemonSet after it finishes.

1. Install dependencies

Make sure your kubeconfig for OKE is set (e.g. KUBECONFIG=~/.kube/config or default path).

2. Python script to apply a DaemonSet that fixes permissions

What this does:
  • Runs a privileged pod on every node.
  • Each pod chmod 644 on 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 with hostPath), run:
You should see permissions 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.
Changing 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.