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
HighAddress
Compliance, SecurityCompliance Standards
- CIS OKE
Triage and Remediation
- Remediation
Remediation
Using Console
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
- Sign in to OCI Console.
- In the left menu: Developer Services → Kubernetes Clusters (OKE).
- Select the Compartment that contains your cluster.
- Click on your cluster name to open its details page.
2. Use the Console Workloads UI to create a DaemonSet
- In the cluster details page, go to the Workloads tab (or Workloads → DaemonSets depending on your UI version).
- Click Create → choose DaemonSet (or Create resource and select DaemonSet).
- Switch to the YAML editor view.
- Paste the following DaemonSet manifest, adjusting the namespace if desired (default is fine):
- Click Create.
- Mount the node’s
/etcdirectory. - Run
chmod 644onkubelet-config.json(common OKE paths checked). - Exit after a short delay.
3. Confirm the permissions
-
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. -
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:- In the Console, go back to Workloads → DaemonSets.
- Click the fix-kubelet-config-perms DaemonSet.
- 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:
Using CLI
Using CLI
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.
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.
Save this as
If you don’t specify
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
1. Identify the OKE node pool and worker nodes
If you already know the node pool OCID, skip to step 2.2. Prepare the chmod command payload
Assuming the file is at/var/lib/kubelet/kubelet-config.json (adjust path if needed):kubelet-perms.json.3. Run the command on each worker node via OCI CLI
For each worker instance OCID:--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_EXECUTIONfor your principal.
4. Verify permissions on each node
You can either:-
Use another instance-agent command:
Then:And inspect the output via:
-
Or SSH into a worker and run:
5. Make it persistent for future nodes (optional but recommended)
If you use custom images or custom node configuration scripts, ensure the image or bootstrap script sets:If you provide your node pool type (managed/unmanaged, image type), I can give you the exact
oci commands tailored to your configuration.Using Python
Using Python
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
- Identify the worker nodes of your OKE cluster / node pool.
- Get their IP addresses (public or private through a bastion).
- SSH to each node.
- Change the file permission to
644: - (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 644onkubelet-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 tochmod 644the hostPath-mounted file on every node at startup.
Using Terraform
Using Terraform
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).
