> ## Documentation Index
> Fetch the complete documentation index at: https://cloudanix.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# OCI OKE Kubelet Should Authenticate Using SSL/TLS Certificates

### More Info:

Kubelet must require client certificate authentication (x509) for incoming requests. Without TLS-based client auth, control-plane components or attackers within the network can issue privileged kubelet requests.

### Risk Level

High

### Address

Compliance, Security

### Compliance Standards

* CIS OKE

### Triage and Remediation

<Tabs>
  <Tab title="Remediation">
    ### Remediation

    <AccordionGroup>
      <Accordion title="Using Console" defaultOpen="true">
        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

        1. Sign in to the **OCI Console**.
        2. In the left-side menu, go to\
           **Developer Services → Kubernetes Clusters (OKE)**.
        3. Click on the **cluster** you want to fix.
        4. Go to the **Node Pools** tab.
        5. Click **Create node pool**.
        6. Fill in the basic fields (name, Kubernetes version, subnet, shape, etc.).
        7. 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”).
        8. Complete any remaining required options (boot volume, number of nodes, placement, etc.).
        9. 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:

        1. Label or taint nodes in the **new** node pool as needed (for scheduling control).
        2. Cordon and drain old nodes:
           ```bash theme={null}
           kubectl cordon <old-node-name>
           kubectl drain <old-node-name> --ignore-daemonsets --delete-emptydir-data
           ```
           Repeat for each node in the old node pool.
        3. Verify that Pods are being rescheduled on the **new** node pool.
        4. 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.
      </Accordion>

      <Accordion title="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:

        1. **Ensure you are using supported OKE node images**
           * List node pools:
             ```bash theme={null}
             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.

        2. **Upgrade / recreate nodes on current OKE images**
           * To roll nodes to the latest image:
             ```bash theme={null}
             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.

        3. **(Optional) Rotate cluster CA and certs if you suspect compromise**
           ```bash theme={null}
           oci ce cluster rotate-cluster-ca \
             --cluster-id <cluster_ocid>
           ```

        4. **(Optional) Verify kubelet is using TLS (per node, via SSH)**
           * SSH to a worker node and inspect kubelet args:
             ```bash theme={null}
             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.
      </Accordion>

      <Accordion title="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:

        1. What’s actually required/possible for OKE
        2. 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

        ```bash theme={null}
        pip install oci
        ```

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

        ```ini theme={null}
        [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.)

        ```python theme={null}
        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:

        ```python theme={null}
        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:

        ```python theme={null}
        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.
      </Accordion>

      <Accordion title="Using Terraform">
        ```hcl theme={null}
        # 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.
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>