Kustomize: [question] --enable_alpha_plugins

[lelandsindttouchnet]

Is there a roadmap/plan to promote plugin support from alpha to beta -or- supported?

[lelandsindttouchnet]

previously asked: https://github.com/kubernetes-sigs/kustomize/issues/1609

[lelandsindttouchnet]

also relevant: https://github.com/kubernetes-sigs/kustomize/issues/1504

[lelandsindttouchnet]

Trying to add some commentary to this query...

I am getting some internal pushback as I advocate for the use of Kustomize in production, specifically when used in combination with plugins requiring the --enable_alpha_plugins option.

I could reference @monopole in #1504 The purpose of this flag was to warn the user against accidentally running 3rd party plugins. but that is at least partly contradicted by the documentation. The use of this flag is an opt-in acknowledging the unstable (alpha) plugin API, the absence of plugin provenance, and the fact that a plugin is not part of kustomize.

Should I expect to see continued support for 3rd party plugins from Kustomize, understanding the responsibility for reviewing and trusting said 3rd party plugins?

[lelandsindttouchnet]

Searched for kustomize plugin, limit to Repositories, order by stars...

Forgive me if you dislike being @-ed. I was hoping that as the maintainers/main contributors of the most popular (by stars) kustomize plugins you might have some input here.

@devstein @jcassee @donbowman @amarrella

[lelandsindttouchnet]

Another interesting data point...
https://github.com/search?l=Markdown&q=--enable_alpha_plugins&type=Code

82 markdown documents with references to --enable_alpha_plugins across github.

[amarrella]

I wouldn't call my plugin popular, but as a user i'd love to see this supported in stable (and possibly in kubectl with apply-k)

[donbowman]

my conclusion was:
a) we need plugins otherwise workflow is very complex and duplicative
b) the compiled in go so are not stable
c) the exec plugins work well, have been using for >1 yr

so my vote is, remove the flag, let them fly. You can't accidentally run a random plugin, they have to be in a well defined location that is not likely to be on unix path.

[devstein]

Agree with @donbowman plugins allow the last-mile flexibility that is very useful for helping simplifying user/company-specific workflows.

Go plugins are finicky but do the job. I think there is work to be done to unify the functionality and interface between the Go and Exec plugins. For example, one issue I've made is around the inconsistency and lack of support for behavior annotations for Go plugin.

I can't claim security expertise, but because the plugin has to be installed to a specific path it definitely reduces the possibility of pure accidental execution of third party plugins. I also love the idea of code and security reviewed "kustomize certified/approved" plugins.

Another point of reference is Google's kpt functions offer very similar functionality to Kustomzie plugins.

Overall, I'm in favor of promoting it.

[lelandsindttouchnet]

Thank you all for the additional conversation and insights.

For what it's worth I would be happy with/fully understand the need for a flag that makes clear some risk. It's the alpha that makes it hard to promote kustomize plugins into production deployments.

It implies that the feature could radically change or be suddenly removed.