Kustomize Provider Attempting to Patch Resources During Terraform Plan

[tajpouria]

During terraform plan, the kustomize provider is attempting to execute patch operations against the live Kubernetes cluster instead of just building a diff for planning purposes. This causes permission errors when running terraform with restricted credentials.

Error Message

time=2025-03-13T09:26:34Z level=info msg=╷
Error: github.com/kbst/terraform-provider-kustomize/kustomize.kustomizationResourceDiff: configmaps "config" is forbidden: User "user-read:plan" cannot patch resource "configmaps" in API group "" in the namespace "service-namespace"

with module.resources.kustomization_resource.service_p1["_/ConfigMap/service-namespace/config"],
on service.tf line 234, in resource "kustomization_resource" "service_p1":
234: resource "kustomization_resource" "service_p1" {

Expected Behavior

The terraform plan operation should only calculate the diff between local and remote state without performing any modification operations against the cluster. The plan user shouldn't need write permissions for resources.

Current Behavior

The kustomize provider is attempting to patch resources during plan phase, which requires write permissions to the resources, even though the plan operation should be read-only.

Additional Context

The issue involves RBAC setup where planning uses read-only credentials (user-read user), while apply operations use elevated permissions. The current behavior prevents following this security practice.

Affected Code

resource "kustomization_resource" "service" {
  depends_on = [kustomization_resource.service_p0]
  for_each   = data.kustomization_overlay.service.ids_prio[1]
  manifest   = data.kustomization_overlay.service.manifests[each.value]

  # Wait for deployments to update
  wait = true
  timeouts {
    create = "10m"
    update = "10m"
  }
}

[tajpouria]

I would be happy to help solve this problem if this repo is still active

[pst]

The provider uses a dry-run to determine the diff. I don't think there is a way to achieve what it needs to do without the permissions.

I've done some work to investigate if I can move the provider to server-side-applies entirely in #259, to solve some known issues. But that will also require the permissions already during plan.

I don't think what you are aiming to achieve here is possible, but if you want to give it a try and provide a PR that achieves it in a backwards compatible way I'm willing to consider it.

[patjlm]

Joining the conversation here, so it means we cannot use this provider to create resources in teh same terrafrom script that creates the cluster (or we need 2 applies: one to create teh cluster and one to deploy the resources). Is this correct?

Could there be any way to optionally not connect at all to teh kube API during plan, as this API may not be there yet?

[pst]

Joining the conversation here, so it means we cannot use this provider to create resources in teh same terrafrom script that creates the cluster (or we need 2 applies: one to create teh cluster and one to deploy the resources). Is this correct?

Could there be any way to optionally not connect at all to teh kube API during plan, as this API may not be there yet?

This is a different conversation @patjlm. But what you want to do is possible, you can see a working example of it here: www.kubestack.com

[pst]

I'm closing this issue. The dry-run approach requires these permissions. No resources are changed during plan.