OCI OKE Kubelet Should Authenticate Using SSL/TLS Certificates

Using Console

In OKE this setting is controlled at the node pool level. You can only choose it when creating a node pool; for existing node pools, you effectively remediate by creating a new node pool with kubelet TLS enabled and migrating workloads.Below are the steps in the OCI Console.

1. Create a new node pool with kubelet SSL/TLS auth

Sign in to the OCI Console.
In the left-side menu, go to
Developer Services → Kubernetes Clusters (OKE).
Click on the cluster you want to fix.
Go to the Node Pools tab.
Click Create node pool.
Fill in the basic fields (name, Kubernetes version, subnet, shape, etc.).
Scroll to the Kubelet configuration / security section (name may vary slightly depending on console version), and:
- Locate the setting for Kubelet authentication or Kubelet security.
- Set it to Use SSL/TLS certificates (or equivalent wording such as “Authenticate using certificates”).
Complete any remaining required options (boot volume, number of nodes, placement, etc.).
Click Create and wait for the node pool status to become Active.

This ensures the kubelet on nodes in this pool authenticates using TLS certificates instead of being unauthenticated or using weaker mechanisms.

2. Migrate workloads from old node pool to new one

If you already had a node pool without kubelet TLS auth:

Label or taint nodes in the new node pool as needed (for scheduling control).

Cordon and drain old nodes:

kubectl cordon <old-node-name>
kubectl drain <old-node-name> --ignore-daemonsets --delete-emptydir-data

Repeat for each node in the old node pool.

Verify that Pods are being rescheduled on the new node pool.
Once workloads are stable on the new nodes, in the OCI Console:
- Go back to the Node Pools tab for the cluster.
- Select the old node pool.
- Click Delete and confirm.

3. Use TLS-authenticated node pools for all future changes

For all future node pools:

Always set kubelet authentication to use SSL/TLS certificates during creation.
Standardize this in your infrastructure-as-code (Terraform/Resource Manager) if you use it, so console-created pools match your baseline.

Using CLI

In Oracle Container Engine for Kubernetes (OKE), kubelet SSL/TLS authentication is already enforced and not configurable via OCI CLI. There is no OCI CLI command to “turn it on” because:

Worker nodes in OKE always run kubelet with TLS enabled.
Kubelet authenticates to the API server using client certificates that OKE provisions and manages.
You cannot disable or downgrade this behavior from the OCI side.

If your security scan flags “Kubelet Should Authenticate Using SSL/TLS Certificates” for OKE, remediation is effectively:

Ensure you are using supported OKE node images
- List node pools:
  oci ce node-pool list \ --compartment-id <compartment_ocid> \ --cluster-id <cluster_ocid>
- For each node pool, check nodeImageId is an official Oracle Linux OKE image.

Upgrade / recreate nodes on current OKE images

To roll nodes to the latest image:

oci ce node-pool update \
  --node-pool-id <node_pool_ocid> \
  --node-image-id <latest_oke_image_ocid> \
  --force

Or recreate the node pool with the latest image.

(Optional) Rotate cluster CA and certs if you suspect compromise

oci ce cluster rotate-cluster-ca \
  --cluster-id <cluster_ocid>

(Optional) Verify kubelet is using TLS (per node, via SSH)
- SSH to a worker node and inspect kubelet args:
  ps aux | grep kubelet
- You’ll see flags such as:
  - --tls-cert-file=...
  - --tls-private-key-file=...
  - --client-ca-file=...

Because OKE is a managed service, using supported OKE node images and keeping clusters/node pools up to date is the only “remediation” you can do; kubelet TLS certificate authentication itself is already enforced and cannot be disabled via OCI CLI.

Using Python

For Oracle Container Engine for Kubernetes (OKE), kubelet authentication with the API server using TLS client certificates is managed and enforced by Oracle. You cannot (and do not need to) “turn it on” yourself, and there is no public API/flag to disable it.Most “kubelet should authenticate using SSL/TLS certificates” findings against OKE are scanner false positives, because the scanner is assuming you have access to kubelet flags (like a self-managed cluster) when you actually don’t in OKE.So there are two practical parts to an answer:

What’s actually required/possible for OKE
How to use Python to validate or document compliance (since you can’t change kubelet flags directly)

1. Reality in OKE: Kubelet is already using TLS certs

In OKE:

Kubelet communicates with the managed API server using TLS client certificates issued by the OKE control plane.
You do not have:
- Direct control of kubelet startup flags (--anonymous-auth, --client-ca-file, etc.)
- Access to the API server or kubelet systemd units to modify TLS configuration

So there is no “remediation” step where you can use Python to flip kubelet from non‑TLS to TLS. It is already TLS, and the platform does not expose a non‑TLS option.What you can do programmatically is:

Confirm you are running a supported, current OKE version.
Show evidence that:
- Node kubeconfigs are TLS-based.
- Kubernetes version is one where OKE uses mTLS between kubelet and apiserver (all generally supported versions).
Optionally, rotate worker node pools to the latest platform image and Kubernetes version to align with Oracle’s secure defaults.

2. Using Python (OCI SDK) to validate and harden OKE configuration

Step 1 – Install and configure the OCI Python SDK

pip install oci

Make sure you have ~/.oci/config set up with a profile that has permissions on OKE:

[DEFAULT]
user=ocid1.user.oc1..aaaa...
fingerprint=xx:xx:xx:xx:...
key_file=/path/to/oci_api_key.pem
tenancy=ocid1.tenancy.oc1..aaaa...
region=us-ashburn-1

Step 2 – List clusters and get cluster details (Kubernetes versions etc.)

import oci

config = oci.config.from_file()
ce_client = oci.container_engine.ContainerEngineClient(config)

compartment_id = "ocid1.compartment.oc1..aaaa..."  # your compartment OCID

# List clusters
clusters = oci.pagination.list_call_get_all_results(
    ce_client.list_clusters,
    compartment_id=compartment_id
).data

for c in clusters:
    print(f"Cluster: {c.name}, OCID: {c.id}, K8s version: {c.kubernetes_version}")

    cluster_details = ce_client.get_cluster(c.id).data
    print("  Endpoint:", cluster_details.endpoint_config.kubernetes)
    print("  CA cert length:", len(cluster_details.endpoint_config.ca_certificate))

The endpoint_config.ca_certificate proves the cluster is using TLS with a CA; kubelets in OKE use TLS client certs signed by this CA to call the API server (managed behavior).

Step 3 – Ensure clusters/node pools are on current versions (best-practice hardening)

If your scanner is strict, part of remediation can be:

Upgrade the cluster control plane to a supported, current version
Upgrade all node pools to the same or newer version and current platform images

Using Python:

from oci.container_engine.models import UpdateClusterDetails, UpdateNodePoolDetails

cluster_id = "<your-cluster-ocid>"
new_k8s_version = "v1.29.1"  # example; must be one of ce_client.get_cluster_options().data.kubernetes_versions

# 1) Upgrade cluster version
update_cluster_details = UpdateClusterDetails(
    kubernetes_version=new_k8s_version
)

update_op = ce_client.update_cluster(cluster_id, update_cluster_details)
print("Cluster update work request:", update_op.headers['opc-work-request-id'])

# 2) Upgrade node pool versions and images
node_pools = oci.pagination.list_call_get_all_results(
    ce_client.list_node_pools,
    compartment_id=compartment_id,
    cluster_id=cluster_id
).data

for np in node_pools:
    print(f"Node pool: {np.name}, OCID: {np.id}, K8s version: {np.kubernetes_version}")

    update_np_details = UpdateNodePoolDetails(
        kubernetes_version=new_k8s_version,
        node_shape=np.node_shape,            # keep existing
        node_shape_config=np.node_shape_config,
        node_config_details=np.node_config_details,
        node_source_details=np.node_source_details  # optionally switch to latest platform image
    )
    update_np_op = ce_client.update_node_pool(np.id, update_np_details)
    print("  Node pool update work request:", update_np_op.headers['opc-work-request-id'])

Upgrading ensures all kubelet nodes run with Oracle’s newest secure configs and images (including TLS/mTLS defaults).

Step 4 – (Optional) Script evidence for an auditor

If your goal is to prove kubelet uses TLS rather than “fix” it, you can script:

Fetch cluster endpoint CA.
Obtain a node’s kubeconfig from OKE (for private access) – it will contain certificate-authority-data and TLS configuration.
Save these as artifacts to show “kubelet/APIServer communication is TLS-based, and we cannot disable it.”

Example to dump the cluster CA cert:

cluster = ce_client.get_cluster(cluster_id).data
ca_pem = cluster.endpoint_config.ca_certificate

with open("cluster_ca.pem", "w") as f:
    f.write(ca_pem)

print("Wrote cluster CA cert to cluster_ca.pem")

Key Point

For OCI OKE:

There is no Python/SDK-based remediation for “kubelet should authenticate using SSL/TLS certificates” because OKE already enforces TLS client certificate authentication for kubelet ↔ API server, and does not expose insecure modes.
The proper response is to:
- Treat this as a false positive in your scanner for managed OKE.
- Use Python/SDK to keep clusters/node pools current and to generate evidence (CA cert, kubeconfig TLS fields) demonstrating compliance.

Using Terraform

# This setting is not exposed on the OCI OKE node pool resource.
# The oci_containerengine_node_pool / oci-containers-oke-nodepool API
# does NOT provide any arguments to configure kubelet TLS client
# certificate authentication flags (e.g., --client-ca-file,
# --anonymous-auth, or webhook auth/z) via Terraform.

# There is no valid Terraform attribute you can add here that will
# change kubelet’s client certificate authentication behavior:

resource "oci_containerengine_node_pool" "example" {
  compartment_id = "OCID_OF_COMPARTMENT"
  cluster_id     = "OCID_OF_OKE_CLUSTER"
  name           = "NODE_POOL_NAME"

  kubernetes_version = "KUBERNETES_VERSION"

  node_shape = "NODE_SHAPE"

  node_config_details {
    size = 3

    placement_configs {
      availability_domain = "AVAILABILITY_DOMAIN"
      subnet_id           = "OCID_OF_SUBNET"
    }
  }

  # No kubelet TLS / x509 client-auth configuration is available here.
}

This particular finding cannot be remediated on an Oracle-managed OKE node pool via Terraform, because the OCI Container Engine for Kubernetes APIs do not expose kubelet authentication flags on oci_containerengine_node_pool.To change kubelet TLS client authentication you would need either:

Self-managed worker nodes (not OKE-managed) where you own the kubelet systemd/flags and certificates, or
Oracle to change the managed control plane / node configuration (not customer-configurable today).

Verification in Terraform: terraform plan will show no changes related to kubelet TLS / client certificate authentication, because there is no argument to manage. Any remediation for this control must be assessed and implemented outside of Terraform using the OCI Console and/or custom node bootstrap scripts on self-managed nodes.

OCI Misconfigurations

OCI OKE Kubelet Should Authenticate Using SSL/TLS Certificates

More Info:

Risk Level

Address

Compliance Standards

Triage and Remediation

Remediation

1. Create a new node pool with kubelet SSL/TLS auth

2. Migrate workloads from old node pool to new one

3. Use TLS-authenticated node pools for all future changes

1. Reality in OKE: Kubelet is already using TLS certs

2. Using Python (OCI SDK) to validate and harden OKE configuration

Step 1 – Install and configure the OCI Python SDK

Step 2 – List clusters and get cluster details (Kubernetes versions etc.)

Step 3 – Ensure clusters/node pools are on current versions (best-practice hardening)

Step 4 – (Optional) Script evidence for an auditor

Key Point

​More Info:

​Risk Level

​Address

​Compliance Standards

​Triage and Remediation

​Remediation

​1. Create a new node pool with kubelet SSL/TLS auth

​2. Migrate workloads from old node pool to new one

​3. Use TLS-authenticated node pools for all future changes

​1. Reality in OKE: Kubelet is already using TLS certs

​2. Using Python (OCI SDK) to validate and harden OKE configuration

​Step 1 – Install and configure the OCI Python SDK

​Step 2 – List clusters and get cluster details (Kubernetes versions etc.)

​Step 3 – Ensure clusters/node pools are on current versions (best-practice hardening)

​Step 4 – (Optional) Script evidence for an auditor

​Key Point

More Info:

Risk Level

Address

Compliance Standards

Triage and Remediation

Remediation

1. Create a new node pool with kubelet SSL/TLS auth

2. Migrate workloads from old node pool to new one

3. Use TLS-authenticated node pools for all future changes

1. Reality in OKE: Kubelet is already using TLS certs

2. Using Python (OCI SDK) to validate and harden OKE configuration

Step 1 – Install and configure the OCI Python SDK

Step 2 – List clusters and get cluster details (Kubernetes versions etc.)

Step 3 – Ensure clusters/node pools are on current versions (best-practice hardening)

Step 4 – (Optional) Script evidence for an auditor

Key Point