Skip to main content

More Info:

The kubelet-config.json file should have permissions of 644 or more restrictive. Loose permissions allow unprivileged users to read or modify kubelet configuration on the node.

Risk Level

High

Address

Compliance, Security

Compliance Standards

  • CIS OKE

Triage and Remediation

Remediation

Using Console

In OKE you can’t click a “fix permissions” button in the OCI Console, but you can remediate this cluster‑wide using the Console to deploy a DaemonSet that corrects the file permissions on every worker node.Below are step‑by‑step instructions using only the OCI Console (plus the built‑in editor).

1. Open your OKE cluster in the OCI Console

  1. Sign in to OCI Console.
  2. In the left menu: Developer Services → Kubernetes Clusters (OKE).
  3. Select the Compartment that contains your cluster.
  4. Click on your cluster name to open its details page.

2. Use the Console Workloads UI to create a DaemonSet

  1. In the cluster details page, go to the Workloads tab (or Workloads → DaemonSets depending on your UI version).
  2. Click Create → choose DaemonSet (or Create resource and select DaemonSet).
  3. Switch to the YAML editor view.
  4. Paste the following DaemonSet manifest, adjusting the namespace if desired (default is fine):
  1. Click Create.
This will schedule one privileged pod on each node. Each pod will:
  • Mount the node’s /etc directory.
  • Run chmod 644 on kubelet-config.json (common OKE paths checked).
  • Exit after a short delay.

3. Confirm the permissions

  1. In the Console, go to the Workloads → Pods view (or DaemonSets → Pods) and wait until all fix-kubelet-config-perms-* pods show as Running and then Completed or Terminated.
  2. Use Cloud Shell or your own kubectl (with the cluster’s kubeconfig) to open a debug pod and check one node:

4. Clean up the DaemonSet

Once you’ve verified the permissions:
  1. In the Console, go back to Workloads → DaemonSets.
  2. Click the fix-kubelet-config-perms DaemonSet.
  3. Click Delete to remove it (the permissions it set on the nodes will remain).

5. Make it persistent for future nodes (optional)

To ensure new worker nodes also get 0644:
  • Update your node pool to use a custom cloud‑init / user‑data script that runs:
You configure that in the node pool’s Node configurationAdvanced options / Custom bootstrap script section in the OCI Console.
To remediate this using OCI CLI, you’ll typically do it non-interactively via the Compute Instance Agent “run-command” feature on each worker node in the OKE node pool.Below are the minimal steps.

1. Identify the OKE node pool and worker nodes

If you already know the node pool OCID, skip to step 2.
From the node pool details, note the instancePoolId or instance IDs depending on node pool type.If it’s a Compute Instance Pool:
This returns the worker instance OCIDs.

2. Prepare the chmod command payload

Assuming the file is at /var/lib/kubelet/kubelet-config.json (adjust path if needed):
Save this as kubelet-perms.json.

3. Run the command on each worker node via OCI CLI

For each worker instance OCID:
If you don’t specify --endpoint-id, the default instance agent endpoint is used. Ensure:
  • Compute Instance Agent is enabled on the worker image.
  • IAM policy allows INSTANCE_AGENT_COMMAND_EXECUTION for your principal.
Example IAM policy (for reference):

4. Verify permissions on each node

You can either:
  1. Use another instance-agent command:
    Then:
    And inspect the output via:
  2. Or SSH into a worker and run:
Expected:

If you use custom images or custom node configuration scripts, ensure the image or bootstrap script sets:
For example, in a cloud-init or node boot script referenced by the node pool.
If you provide your node pool type (managed/unmanaged, image type), I can give you the exact oci commands tailored to your configuration.
Below is one practical way to remediate this in OKE using Python: connect (via SSH) to each worker node and correct the file’s permissions.Assumptions (adjust as needed):
  • File path: /etc/oci/kubelet/kubelet-config.json
  • You have SSH access to worker nodes (via a bastion or public IP).
  • You have OCI API credentials (config file ~/.oci/config) and know the OCID of the OKE cluster or node pool.

1. High-level remediation steps

  1. Identify the worker nodes of your OKE cluster / node pool.
  2. Get their IP addresses (public or private through a bastion).
  3. SSH to each node.
  4. Change the file permission to 644:
  5. (Optional but recommended) Enforce this automatically using:
    • A DaemonSet, or
    • A custom image / cloud-init script for future nodes.

2. Python example using OCI SDK + SSH (paramiko)

Install requirements:

2.1. Script to:

  • List instances for a given node pool
  • SSH to each node
  • Run chmod 644 on kubelet-config.json

3. Optional: Make the fix persistent

For long-term compliance:
  • Cloud-init / custom image:
    Bake into your node image or cloud-init:
  • DaemonSet:
    Create a privileged DaemonSet that runs a small container to chmod 644 the hostPath-mounted file on every node at startup.
If you tell me your exact file path (from the scanner output) and your connectivity pattern (public IP vs bastion), I can tailor the script further.
This uses node_metadata.user_data cloud-init to enforce 0644 on kubelet-config.json on every node in the pool; updating this usually causes the existing worker VMs to be recreated, so plan for a rolling disruption.To verify, terraform plan should show an in-place update to oci_containerengine_node_pool.OKE_NODEPOOL with a change in the node_metadata.user_data field (and no other unrelated changes).