Feature Request: Support `spec.resources` in Kustomization CRD

[lictw]

Description
Currently, the kustomize-controller can automatically generate a kustomization.yaml if it's missing in the spec.path. However, it lacks the ability to explicitly define a list of resources via the CRD.

While Flux is often presented as a "transport," in reality, it is already a powerful manifest generator: it allows overriding namespaces, names, patches, images, and variables. If Flux can manage "what to change" (patches), it should be able to manage "what to include" (resources).

The "Components" Precedent
Flux already supports spec.components, which allows injecting a list of files/directories. Since the controller already implements logic for injecting a list of components into the transient kustomization.yaml, forbidding the same for resources is an artificial and inconsistent limitation.

Proposed Change
Add a spec.resources field (list of strings) to the Kustomization CRD.

Expected Behavior

1. Context: spec.path serves as the root (work directory).
2. Explicit Selection: If spec.resources is defined, the controller uses this list and disables the default automatic recursive discovery (the "include all files" behavior).
3. Merging: If a physical kustomization.yaml exists in spec.path, spec.resources should be appended/merged (following the same merging logic already used for spec.components).

Why this is needed?

• Reducing Git Boilerplate: Currently, users are forced to create "garbage" one-liner overlays in Git just to have different resource lists for the same source.
• Consistency: If we can dynamically inject components and patches via CRD, we must be able to define the base resource list.
• Logical Alignment: If spec.path is the "context," then spec.resources is the natural way to define the entry points within that context.

Example

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: example
spec:
  interval: 5m
  path: ...
  resources: 
    - https://raw.githubusercontent.com/...
  components: # already work, why doesn't the resource list?
    - components/ingress

[matheuscscp]

This opens up the door to so many attacks... URLs for example are a no-go. Changes the entire Flux security model where source-controller/source-watcher are the doors for external sources. For local file system, I can see attacks with ../ paths. If we implement this, several restrictions must be applied.

[lictw]

@matheuscscp I understand the security concerns, but since kustomize build is used under the hood, it already supports remote bases/URLs by design. How does this change impact the security model more than what's already possible via kustomization.yaml?

[matheuscscp]

It changes because who controls the Flux Kustomization CR and who controls the source can be different teams. On clusters where cross-namespace references are allowed, a global source controlled by the platform team can be referenced by all tenants (e.g. dev team). If this is the case and the platform team is enforcing no URLs in the source, allowing tenants to pull URLs is a grave security breach.

[lictw]

Thanks for explaining the multi-tenancy aspect. I’m coming from a multi-cluster setup, where the priority is efficient composition rather than tenant isolation, so I didn't initially consider that perspective.

My main issue is the boilerplate required for layering. Often, I need a Flux Kustomization to compose several resources together. Currently, I’m forced to create a dedicated directory with a dummy kustomization.yaml for almost every such layer (e.g., system/, longhorn/, etc.), even if they just list other bases.

I prefer keeping actual patches close to the resources. In my structure, the /cluster's role is just to define what and in which order to deploy. Having to manage a deep hierarchy of folders just to "point" at things makes the setup hard to navigate and verify.

If URLs are a security deal-breaker, would you consider allowing multiple local paths directly in the Spec? This would solve the folder sprawl for composition without bypassing the source-controller security model.

[matheuscscp]

I'd be ok with paths that resolve to subpaths of .spec.path.

[matheuscscp]

Have you considered using source-watcher? It's quite flexible, maybe it solves your use cases:

https://fluxcd.io/flux/components/source/artifactgenerators/

[stefanprodan]

You can dynamically generate resources (if else conditions) with Flux Operator's ResourceSet API https://fluxoperator.dev/docs/crd/resourceset/

Adding in-line resource paths to Flux Kustomizations is not something that I would consider.