The `oci_containerengine_cluster_kube_config` data source makes `POST` requests and breaks `plan` when "read-only" credentials are used

[lopter]

Hello,

I think this is an issue in oci-go-sdk, but I believe it needs to be tracked here, it can be used as a reference to open an issue there.

We use oracle-terraform-modules/terraform-oci-oke with two set of credentials: plan and apply credentials. The plan credentials can only read resources while the apply can manage them.

This bug means this data block in module-cluster.tf in terraform-oci-oke fails, which cascades into cluster_ca_cert being "none", the cloud-init config to be improperly computed creating undesired changes on the oci_containerengine_node_pool as well as the cluster_ca_cert output to be missing.

I'd be interested to know if there is a way to create an exception in the policy for our plan credentials for that specific call as a workaround.

Details from the debug log:

INFO 2025/11/22 03:50:57.538508 client.go:553: Dump Request POST /20180222/clusters/[redacted]/kubeconfig/content HTTP/1.1
Host: containerengine.us-phoenix-1.oci.oraclecloud.com
User-Agent: Oracle-GoSDK/65.104.0 (go/go1.25.3; linux/amd64; terraform/2.36.1; terraform-cli/1.11.0-beta1) Oracle-TerraformProvider/7.25.0
Content-Length: 31
Accept: */*
Authorization: [REDACTED]
Content-Type: application/json
Date: Sat, 22 Nov 2025 03:50:57 GMT
Opc-Client-Info: Oracle-GoSDK/65.104.0
Opc-Client-Retries: true
Opc-Request-Id: 010c1051dfb0a0dfa98e362e5d1db576
X-Content-Sha256: hXBVwINTczakBYvsF5pdxr8dmJTp4D/StbwftMOpPa4=
Accept-Encoding: gzip

INFO 2025/11/22 03:50:57.538563 log.go:229: Dump Request Body: 
{"endpoint":"PRIVATE_ENDPOINT"}
INFO 2025/11/22 03:50:57.538686 client.go:559: Dump Response HTTP/1.1 404 Not Found
Content-Length: 111
Content-Type: application/json
Date: Sat, 22 Nov 2025 03:50:57 GMT
Opc-Request-Id: 010c1051dfb0a0dfa98e362e5d1db576/42FB92035083494D21332169504858B6/4CB19BA87233B16A856D8D897060D733
Strict-Transport-Security: max-age=31536000; includeSubDomains;

{
  "code" : "NotAuthorizedOrNotFound",
  "message" : "Authorization failed or requested resource not found."
}

cc @hyder

[tf-oci-pub]

Thank you for reporting the issue. We have raised an internal ticket to track this. Our service engineers will get back to you.

[billf]

the oci_containerengine_cluster_kube_config data source is calling a 'Create*` endpoint in its Get() implementation.

i cannot imagine doing write-operations in data-sources (generally) nor in the 'R' of 'CRUD' (specifically) are allowed in the terraform model.

it would definitely be unsupported in any CI/CD workflows that allow 'plans' to be executed by one environment & apply operations to be made from a more privileged environment.

[hyder]

Hi,

Do you have a ticket with oci-go-sdk we can use to track?

[lopter]

Hi,

Do you have a ticket with oci-go-sdk we can use to track?

Not yet, maybe we can use @billf's comment as a basis for such ticket?

[billf]

the primary issue resides in this repository.

• this terraform provider is not implementing the terraform provider contract correctly.

  • https://registry.terraform.io/providers/oracle/oci/latest/docs/data-sources/containerengine_cluster_kube_config is documented as both "details about a specific Cluster Kube Config resource" and "Create the Kubeconfig YAML for a cluster."
  • "creating" yaml content attribute from the details, if it did not already exist, would be fine if the endpoint temporally rendered it each time.
  • creating it as a side-effect is not ok.

    Data sources are intended to have no side-effects.
    -- https://developer.hashicorp.com/terraform/plugin/framework/data-sources

  • the provider calls a "create" endpoint in the read path ((*ContainerengineClusterKubeConfigDataSourceCrud).Get()) of a data source.

• the OCI OKE terraform module could be more defensive

  • uses the read-only operation data "oci_containerengine_clusters" in the compartment with a filter of [ACTIVE, UPDATING] as signal
  • if the endpoint is available as oci_containerengine_clusters.existing_clusters[private_endpoint] it uses what should be a read-only operation of oci_containerengine_cluster_kube_config{cluster_id, PRIVATE_ENDPOINT} which fails.
  • when it fails, the string value "none" shows up in places that may expect e.g. base64 encoded values
  • an issue in https://github.com/oracle-terraform-modules/terraform-oci-oke could be opened pointing at this one to track the failure modes (endpoint exists but isn't writable, endpoint doesn't exist, "none" being used in an output expecting encoded data)

oci-go-sdk use of POST in a Create call is, itself, not a problem.

[robo-cap]

When you plan to export the variable cluster_ca_cert from the oke terraform module, what is the value you use for var.output_detail ?

It should be true.

output "cluster_ca_cert" {
  description = "OKE cluster CA certificate"
  value       = var.output_detail && length(local.cluster_ca_cert) > 0 ? local.cluster_ca_cert : null
}

Also, in order to get the ca_cert, we are using this api call: https://docs.oracle.com/en-us/iaas/api/#/en/containerengine/20180222/Cluster/CreateKubeconfig

The user needs to have permissions to use the kubernetes cluster. https://docs.oracle.com/en-us/iaas/Content/Identity/Reference/contengpolicyreference.htm

This permission level should not allow a user to execute API calls against the OKE control plan.

[lopter]

Hello @robo-cap, we have output_detail set to true and our policies are correct wrt to permissions.

[robo-cap]

You are saying you still get a 404 when the user who executes the plan has the permission to use the clusters?

From your text I see you say: The plan credentials can only read resources.

[lopter]

I tried to be careful in the wording of my original post, and the user that does the plan has read permissions. The user that applies the plan has manage permissions.

This felt like the correct permission model to us, but as you rightfully pointed out, now I see that use is another verb.

Moving along this line of thought, I guess we could add something like:

Allow group <group_name> to use clusters in tenancy

To our policy statements as (what feels like) a workaround.

Thank you for your attention to this so far.